Business Trends
Sync-Async Connectivity (SOAP 2 MAIL) with SAP PRO (w/out BPM)
Sync-Async Patterns with BPM on SAP NetWeaver Process Orchestration (PRO) are quite easy to implement.
However, when you want to design the integration flow as lean as possible, this document might be useful for you as the usage of the sync/async adapter modules is a bit tricky.
Scenario:
- SOAP Sender (in our example WebShop) is calling SAP PRO synchronously
- The request is forwarded asynchronously via E-Mail to the receiver (typically it would be e.g. IDoc to SAP ERP of course)
This is an example scenario of course. HTTP/SOAP on the (sync) sender side can be combined with any channel on receiver side (IDOC/SOAP/FILE/SFTP/MAIL/JMS/JDBC/…)
Adapter Modules used:
We are using the following (standard) adapter modules:
- AF_Modules/RequestOnewayBean (to convert the synchronous message to an asynchronous one)
- AF_Modules/DynamicConfigurationBean (to store the original message id in the ASMA of the sender channel and read it in the receiver channel to set the correlation)
- AF_Modules/WaitResponseBean (to wait for the reply of the receiver channel)
- AF_Modules/NotifyResponseBean (to send back the message to the waiting sender channel using the message id correlation)
ESR Content (sender side):
- Service Interface Sync Out
- Service Interface Sync In (Dummy)
- Operation Mapping (Service Interface Sync Out -> Sync In)
- Message Mapping (Input Message Type -> Output Message Type)
DIR Configuration:
- Sender System
- SOAP Sender Channel
- SOAP Receiver Channel
- Receiver System
- MAIL Receiver Channel
Screenshots:
It is of course not necessary to do this in NWDS but I really started to like it…
Test & Monitoring:
- Call WebService from WS Navigator
- ASMA (DynamicConfiguration) with MessageId
- E-Mail received from SAP PRO
Hi Adam
A few thoughts:
Don't you actually mean without BPM?
You mentioned that usage of the modules are a bit tricky. Why do you say it is tricky? There are already few blogs/documents on SCN that clearly show how it is used. Even if it is tricky, your blog does not clarify how it actually works as it just contains screenshots as compared to existing blogs/documents that actually provide further description and explanation.
Lastly, I can't see any practical use case for the bridge that you have designed here. Technically there is no bridge required as there is no actual response from the asynchronous receiver (email), you are just looping back the request to the response. If there is no response from the asynchronous receiver, this would have been just designed as a fully asynchronous interface, i.e. sender SOAP channel with QOS EO. After all from the WebShop point of view, PI is the web service provider and as the web service provider, you have to onus to decide whether the service is asynchronous or synchronous.
Rgds
Eng Swee
Dear Eng Swee,
usually you establish a Sync-Async pattern with the SAP NetWeaver BPM component of SAP PRO (BPMN based process model). This document describes how it can be done without BPM usage. Establishing a Sync-Async pattern with BPM is quite easy and you will find a lot documentation for it. But it also comes with some overhead, so without BPM is the leaner approach.
The usage of AdapterModules is not difficult of course, but although I work with XI/PI since the beginning (XI 1.0 in 2003), it took me a while to understand the combined usage of the modules to achieve the sync-async bridge. The way it works is described in the section "Adapter Modules used".
Regarding the use case:
You will see in your future projects, that sometimes you can not influence existing systems and partners. I had this specific requirement for a LSP that could only make synchronous WebService calls, but the SAP ERP system expected IDocs.
With this scenario, the sender (LSP) receives a technical OK that the message was received by the middleware (SAP PRO) and that is totally fine.
Best regards, Adam
Hi Adam
Thanks for the clarifications.
IMHO, you might want to consider mentioning the use case at the introduction of the blog. It would help others reading this to understand why you did what you did. To be honest, for me, without your further clarifications, your approach seemed redundant (just my two cents).
Also, having just one screenshot after another without further explanation or description in between isn't really helpful. Someone new would not know why the values in each screenshot are populated the way they are. Again, that's just my two cents as suggestions for improments - this is your blog after all and you are free to maintain it the way you choose.
Rgds
Eng Swee