Integration Process with n:1 transformation and S/A bridge

[Former Member]

Hello everybody

I am new to PI and have problems understanding the Integration Process component in the Enterprise Service Builder. I want to create a process which receives a message (which an object I have to persist). This message is sent to a service which stores it in the DB and returns an ID. The ID has to be set in the original message. The resulting message is sent asynchronously to another application. The ID should be returned to the caller of the integration process.

The first problem I faced was, that I couldnu2019t define a message nor a synchronous interface as container object. It only allows me to specify asynchronous interfaces.

The second problem is, that Iu2019m not sure about how to define the process. My idea was to do it like this:

                       +---------+  
                   +-->| 3) send |--+
   +--------+   2) |   +---------+  |   +--------------+   +---------+
o->| 1) S/A |----->|                +-->| 4) transform |-->| 5) send |-->o
   +--------+      |                |   +--------------+   +---------+
                   +----------------+

1. Open S/A bridge to be able to call the synchronous function

2. Fork to be able to transform the initial message and the result of the synchronous call later on

3. Call the synchronous service and store the result in the container message

4. Perform a n:1 transformation combining the two messages

5. Send the combined message to the asynchronous service

6. Return the ID somehow (how do i specify the result of the process?)

Suggestions or documentation (also books) which would help to understand how to implement something like this is welcome. I already had a look at the help of PI (especially "Advanced Mapping Techniques" and "Defining an Integration Process".

Thanks & Regards,

Tarik Osman

[Former Member · Accepted solution]

Hi,

Check this if not already checked..

Bridging the Sync-Async bridge with Fork (XI)

Regards,

Sarvesh

[Former Member · Accepted solution]

Hi Sarvesh

I've also stumbled over this page on the search and until now I'm not yet sure whether it is part of the problem. Iu2019ll have to think about it over night. Rewards come tomorrow Thanks anyhow...

Regards,

Tarik

[Former Member]

Am I right, that I don't have to fork (since I anyhow don't do anything in the second thread) and i just would have to be able to keep both, the input and the response in the container? Then the only problem would be how to define synchronous interface as container object and how to use it in the transformation. As far as I could see, one can only transform using operation mappings, and not using message mappings. But with operations mappings i can not use the input and output together in the same mapping...

[Former Member]

Hi,

> Am I right, that I don't have to fork

Yes at least if the second branch is empty

> Then the only problem would be how to define synchronous interface as container object

It could be syncronous but important is to define it as abstract as you could use only abstract interfaces inside of Integration Processes.

Regards

Patrick

[Former Member]

Hi Patrick,

It could be syncronous but important is to define it as abstract as you could use
only abstract interfaces inside of Integration Processes.

The search criteria of the "Choose Operation" dialog box filters the results and shows only asynchronous interfaces and it doesn't allow to change the mode to synchronous... Should this be possible? Could this be a bug of PI 7.1?

Regards,

Tarik

[Former Member]

Hi Tarik,

first of all you could have a look at the BpmPatternSyncAsyncBridge in the Integration Repository for an example of sync/async communication:

http://help.sap.com/saphelp_nw04/helpdata/en/83/d2a84028c9e469e10000000a1550b0/frameset.htm

And also could you please list one more time the order of your messages in a list like in this example:

1) Rec. Sync

2) Send Async

...

Would be helpful to understand your scenario in a better way.

Thanks and regards

Patrick

[Former Member]

Thank you for the answer,

I think i got one step further over night although there are a few things which i found a bit confusing...

You want a synchronously calling business system BS-S and an asynchronously called business system BS-AS to communicate with each other. You can achieve this with a sync/async bridge within an integration process.

What I want to do is a) call a synchronous service to store an object, b) merge the response containing the ID to the request message type with a transformation c) call an asynchronous service with the transformed message d) return the response i received from the synchronous service and optionally e) handle the acknowlege which may take a few hours.

Different than in the pattern I don't have to wait for a response of the asynchronous service before returning a response. As far as I could see, I still need the S/A bridge to be able to call the asynchronous service and return the response of the sychronous service I called before.

My integration process now looks like this:

1) Rec. Open S/A bridge

2) Send Sync (call synchronous service and receive response in one step)

3) Transform 1 and 2 to message of type 1

4) Send Async (asynchronous service call)

5) Close S/A Bridge (and return the message I received in 2)

Is this correct until now? The next part would be to handle a timeout of the acknowledge message. Is it appropriate to do this in an EJB instead of implementing it in the process or are there major disadvantages?

Thanks and Regards,

Tarik

[Former Member]

Hi,

if you only send a async message between your sync messages and don't have to wait for a async receive then why don't you paste the async send step after the sync send step?

So you will have first the sync communication and then send an async message.

Regards

Patrick

[Former Member]

Do you mean to simply remove the S/A bridge from the process above (step 1 and 5)? Would the process still return the response of the sync send step if I would to this?

Regards,

Tarik

[Former Member]

Hi,

> Do you mean to simply remove the S/A bridge from the process above (step 1 and 5)?

Yes and change the order of step 4 and 5 or why should it be important to send the async message before the sync message.

So you will have:

1) Rec. Sync

2) Transform

3) Send Sync

4) Send Async

But it could be maybe even possible like this (if necessary):

1) Rec. Sync

2) Transform

4) Send Async

3) Send Sync

Even without S/A Bridge because you need it only if you wait for a async response inside of a sync communication.

Regards

Patrick

[Former Member]

Hi,

The transformation of step 3 takes the input and response of the synchronous service call and generates the input for the asynchronous call. That's why it has to be in this order.

Additionally I'll need the response of the sync call as response of the process (if this is possible). That is the reason why I wrapped all in a S/A bridge.

In the Close S/A it was possible to define the response of the sync interface which was defined in the Open S/A step. The process integration scenario actually looks quite strange...

Regards,

Tarik

[Former Member]

Hi Patrick

We decided, to move this logic to an EJB instead of doing it in PI. Thank you anyhow for the help. If you've got the time do describe a solution and know how one could implement it in PI it of course still would be interesting to know.

Thanks & Regards,

Tarik