Introduction

In this blog we will look at some typical iFlow scenarios provided in the HCI pre-delivered content. Typically all iFlow scenarios delivered for CRM and ERP integration can be grouped based as follows.

Asynchronous Scenarios

1. Plain SOAP (SAP-RM) to IDOC
2. IDOC to Plain SOAP
3. Plain SOAP to Plain SOAP

Synchronous Scenarios:

1. SOAP to SOAP

Reliable Messaging:

HCI does not support WS-RM (except for FSN scenarios), so for asynchronous reliable messaging SAP-RM (Plain SOAP) is used. With Plain SOAP the message ID is transfered in the SOAP header to guarantee exactly once delivery and a good choice to communicate with systems which do not support WS-RM.

To enable communication over Plain SOAP, the consumer should be configured correctly. A typical SOAMANAGER consumer configuration is shown below

Additionally the WSDL being used with the SAP-RM adapter, should not have any WSRM policy entries.One way of downloading WSDL without Policy from SAP back-end systems is shown below. In SOAMANGER generate WSDL without SAP Assertions and WSP Version set to No Policy

You can find more about the Plain SOAP at the Plain SOAP – ABAP Connectivity – SCN Wiki link.

IDOC Bulking Support:

With release 1405 IDOC bulk processing support has been enabled for ERP/CRM to C4C direction. Earlier we only supported IDOC SOAP with content type Application/x-sap.idoc which allows only a single IDOC record per request. But now to improve performance specially during initial load we also support multiple IDOC records per request but the content type should be set to Text/XML.

Additionally with Sender IDOC adapter we no longer need a WSDL validation and it saves us from manually editing the IDOC WSDL before it could be used within iFlow. Another advantage, with no WSDL iFlow can accept message both over Text/XML and Application/x-sap.idoc

Note: As of now we don’t support IDOC bulk processing for inbound processing, but will be made available in a future release.

Multicast Pattern

As of now since the eclipse tooling does not support the inclusive gateway, to send same message to multiple interfaces a work around has been implemented. The work around involves wrapping the message twice (as I need to send it via two interfaces)using content modifier and then perform split and gateway to route them though different interfaces as shown below.

1. In the Content modifier we simply copy the incoming payload twice
   

                    <parent>

                              <child id=”1″>${in.body}</child>

                              <child id=”2″>${in.body}</child>

                    </parent>

1. In the Splitter we split the content from previous step based on token <child>
2. In the Gateway we route the message based on the @id attribute. i.e. //child[@id=”1″] or //child[@id=”2″]
3. Then in the Filter we simply extract the original content from the modifed content //child/n0:SocialMediaUserProfileReplicateRequest where xmlns:n0=http://sap.com/xi/SAPGlobal20/Global

In the next blog we will look at the WEB UI tooling and how to use it. Watch out for this series and Happy Learning.