SOAP conversation - implementation approaches?

[Former Member]

Hi fellows,

I am rather investigating the possible approaches for the following scenario, described on a step-by-step basis:

a. PI logs to a remote system sending a login message via SOAP call

b. remote system returns a login response (OK | FAIL) message via SOAP (in case of OK-response, the

message contains a conversation GUID, which should be used in the subsequent steps)

c. PI sends some specific command (+ the above mentioned GUID) via SOAP

d. external system returns command response

e. etc.

What do you think - is there a best practice to achieve this? The one that I am currently thinking is the good old integration process (+ correlation)...

Best Regards

[former_member184681]

Hi,

Actually it is the "etc." part that makes me wonder about the whole scenario design . If your scenario is almost a normal PI scenario, with sender system sending/requesting some data to/from receiver system, and the only difference is the requirement to call the login web service before the "main" one, then you might consider using the Lookup API to call the login web service during mapping and obtain the GUID there to put it into the target message,  then call the "main" web service and return results to the sender as usually. But if your scenario is more complex than the one I just described, then it looks to me like a typical BPM use case.

Hope this helps,

Greg

[Former Member]

Hi Greg,

Unfortunately, after the requirements where clarified a little bit, the topic seems to be harder for implementation 😉 Session ID (xml tag) is got after a login is executed, however this ID should be used constantly afterwards for all subsequent calls. The tricky point is that this session id is invalidated in case of some timeout due to inactivity from PI as a webservice caller..

I can see another possibility - in UDF to store the last access timestamp of the webservice endpoint and the last used valid Session ID (in case of a timeout not yet reached) ..

And everything else is as you said - calling the login via UDF, etc.

What do you think?

[former_member184681]

Dear Lalo,

>>> Session ID (xml tag) is got after a login is executed, however this ID should be used constantly afterwards for all subsequent calls.

Do you mean that PI should get the ID for more than one receiver WS call? This doesn't really match the definition of a "session ID", if you ask me. Anyway, if this is how it should work - how would you pass the ID from one message to the other? UDF won't do that for you. IMHO, getting a session ID for each message, as I described earlier, is a much better idea (from design perspective) and is easier for implementation. Can you confirm with someone if this is also acceptable?

Regards,

Greg

[Former Member]

Greg,

>Do you mean that PI should get the ID for more than one receiver WS call? This doesn't >really match the definition

Yep, it is just called Session ID - from semantical (?) point of view .. it is not the session ID as we know it..

>UDF won't do that for you

Yep, I've played alot with the UDFs several years ago - they do not provide any terms of persistance (static fields as well ;-)) , but there are other ways as Z-DB tables (RFC lookups..), accessing directly the java AS secure storage can be an option too...

>getting a session ID for each message,

And final yep - I know getting a session id for each message is really better idea compared with the reality I should cope with ..

Thanks & regards

[iaki_vila]

Hi Lalo,

If you deal with the endpoints and not with the PI itself you could consider an Distributed Two-Phase-Commit Scenario: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00ffdb4d-e869-2a10-7688-891d7eea1...

because you can establish a communication between the two endpoints and you can do a commit or rollback in your backend depending of the source endpoint message.

Regards

[baskar_gopalakrishnan2]

Yes this is possible.  I would recommend this way...

YOu can combine step a and b using soap lookup. That is feasible. Since you just get login response with GUID.

Sender system - Decide as per your requirement.

During mapping soap lookup using UDF (Steps a and b)

Reciever system - SOAP receiver  (step c is request message) and Step d is response message.

Final step: Map the response message to the sender system

You might want to search SDN for soap receiver scnenario.

For SOAP LOOKUP using UDF refer this link

http://scn.sap.com/community/pi-and-soa-middleware/blog/2006/11/20/webservice-calls-from-a-user-defi...

For SOAP receiver and general idea, glance this link

http://www.riyaz.net/sap/xipi-a-guide-to-using-sap-xi-soap-adapter/113/

Plus there are plenty of threads to view for SOAP reciever scenarios.

Scenario example:

Sender side Proxy  -->  Lookup UDF soap --> SOAP(receiver)  -> Proxy(sender)