Is Correlation required?

[Former Member]

All,

Im having a scenario of SOAP->ccBPM.

Since the SOAP is synchronous and the ccBPM is too (we have a sync-async bridge inside), if there are multiple requests from the SOAP side - wont each of them create new instance and return the value from ccBPM to the calling SOAP request.?

Or do we need correlation here? If so, can you please explain what im missing in my above assumption.

Thanks.

[Former Member · Accepted solution]

No, it is not required.

reading: http://help.sap.com/saphelp_nw70/helpdata/en/44/3a6c6d55e402bfe10000000a11466f/content.htm may help clarify and also may help to fine-tune your scenario. With the volume of synchronous calls and volume of BPM instances you'll start.

sincerely,

--NM

[Former Member]

Not sure if I understand your initial question - are you not wanting the multiple instances of the BPM?

Given your explanation above, there SHOULD be multiple instances i.e. one for each call initiated by the desktop client.

suggestions:

1. receive from SOAP request - starts the process and opens the S/A bridge.

2. Asycn send to legacy.

3. Async receive from legacy.

4. Sync send to RFC.

5. transformation to merge the 2 response.

6. send (closes the S/A bridge)

OR

1. receive from SOAP request - starts the process and opens the S/A bridge.

2. Asycn send to legacy.

3. Async receive from legacy.

4. transformation to merge the 2 response (call RFC and merge response in mapping)

5. send (closes the S/A bridge)

OR

1. receive from SOAP request - starts the process and opens the S/A bridge.

2. Asycn send to legacy.

3. Async receive from legacy.

4. Send and close S/A bridge

5. in Interface determination for above send step, perform mapping that calls RFC and merges data accordingly

sincerely,

--NM

[Former Member]

<i>"Given your explanation above, there SHOULD be multiple instances i.e. one for each call initiated by the desktop client."</i>

That is exactly what i wanted to confirm. If there are multiple desktop clients that are requesting at the same time with different input values, there will be multiple instances of the BPM (1 / request) and they will accordingly return the output to their corresponding calling desktop client without any issues.

so - correlation is not needed in the above scenario right?

Thanks.

[VijayKonam]

Yes. XI takes care of the repsonse matching for each of the call made to XI's BPM. You would need co-relation only when you are collecting multiple requests in BPM and sending to other systems for response.

So, In your case, co-relation is not needed.

VJ

[Former Member]

Can you elaborate? What are the steps in your BPM?

What starts the process? what creates the bridge? what does the BPM call etc... then you can get some feedback on how to create the bridge and if you need a correlation.

sincerely,

--NM

[henrique_pinto]

Well,

Soap -> ccBPM isn't a scenario itself.

It is your implementation of a major scenario.

So, again, what is really your end-to-end scenario?

Also, if you do need a loop of sync calls, unfortunately you won't be able to do that in XI.

As of now, ccBPM collection pattern only accepts async receiver steps as starter of the process.

Regards,

Henrique.

[Former Member]

Ok, Here you go.

There are few microsoft desktop clients, who connect to XI through SOAP. They generally send a single record and need the details on that record.

In the ccBPM, there is a call to a sync call to RFC, and a async call to a legacy system. The ccBPM merges back the responses from these 2 systems and "HAS" to send it back as the response to the SOAP request.

1. receive from SOAP request - starts the process and opens the S/A bridge.

2. Sync send to RFC.

3. Asycn send to legacy.

4. Async receive from legacy.

5. transformation to merge the 2 response.

6. send (closes the S/A bridge)

so, there is no collect pattern inside, it is just a sequence of calls to different systems and merge back the responses and send back a single response.

Let me know, if you need additional details.