Skip to Content

Introduction
The use of SAP B2B Adapters to support B2B scenarios on the SAP PI/PO/PRO platform continues to provide good return on investment (ROI) on this middleware solution. Previously, organizations using SAP PI/PO as a middleware solution, needed to depend on third party offerings to run B2B scenarios. Running A2A and B2B scenarios on SAP PI/PO/PRO gives a good boost to the adoption SAP PI/PO/PRO as middleware of choice. These blog series help understand the power and usefulness of the B2B in your organization. In the first part of these two blog series: https://blogs.sap.com/2016/09/14/part-1-split-ups-are-hard-using-the-sap-b2b-edi-separator-adapter-for-a-xml-message-split/, we provided insights into the use of SAP B2B EDI separator adapter, and how this can be used to achieve a message split of a sorted message. In the second part of these blog series, technical details needed to set up an EDI Separator receiver and sender channels are to be discussed.

Scenario Description
As discussed in the first of this blog, there is a very specific split message scenario which need to be integrated by means of two Integrated Configurations. For the full details, please check blog #1.


Figure: Scenario overview with the two required ICOs

A sorted message is the prerequisite for executing a message split, which in this case was achieved by using a XSLT mapping. In this blog, the output from the XSLT mapping is called the Intermediate XSD. This output contains the node “Country_*” which is defined in the EDI Separator Sender channel as the level on which the split should be performed. This intermediate XSD is showed in below figure, at the right hand side.


Figure: Unsorted Input Message and Sorted Output Message

Directory Setup
As discussed in the first part of this series of blogs, System A sends out one large file with employee data from multiple workers from multiple countries. The employees are randomly put into the file and also arrive like this within the SAP PRO middleware. The requirements prescribe that System B likes to receive files with data from one or more workers that belong to the same country. In order to get this implemented in SAP PRO 7.5 it was decided to:

First: by means of a XSLT mapping, sort the employee data from System A by using Country Code as a key. This results in the same file, but then sorted by country code. As also described in the first part of this blog series, an intermediate XSD has been created to include these two additions to the message structure:

  • Add an additional element in the target structure that is called ‘EDI_Separator_Identifier’. This can be done in the XSLT mapping. Based on this field, which is filled with a constant value, it is much easier to create a filter in the EDI Separator sender Communication Channel.
  • Add an extra node called ‘Country’ during the XSLT mapping. The data records from the employees that belong to this country will be put as child under this Country node. By selecting this node in the configuration of the EDI Separator, the SAP PRO system knows where to split the message into multiple ones. The new messages will all start with Country as first node.

Second: make use of the B2B EDI Separator component in SAP PRO in order to split the file per Country.

The remaining part of this blog will mainly focus on the configuration that needs to be done in the PRO Directory in order to perform a message split. The two Integrated Configurations (ICOs) that are required, will now be reviewed step by step.

Integrated Configuration #1
As depicted below, the first Integrated Configuration is just a regular setup which receives messages by means of SOAP. Without any further conditions all of these messages, sent by System A, will be forwarded to the EDI Separator component – in this case named EDI_SEPARATOR.


Figure: ICO #1 for the first part of message processing

In the Receiver Interfaces tab it is possible to add a mapping before it gets routed towards the EDI Separator. Here the XSLT mapping, as described in blog 1, can be incorporated in order to sort the data structure and prepare the message to be split by the EDI Separator component. Remember that the intermediate XSD has been used as target message structure.

Figure: Configuration for XSLT map in ICO #1

Next, in the Outbound Processing tab it is required to select the Communication Channel that is able to receive the intermediate message. Here, the channel has been selected which is able to handle XML messages.

Figure: Selecting EDI Separator receiver channel in ICO #1

Below it has been depicted how the receiver Communication Channel has been configured. The tabs called ANSIX12, EDIFACT, EANCOM and Advanced can be left as is.


Figure: EDI Separator receiver channel basic configuration in ICO #1

So far, it has been a pretty straightforward setup. The output that is generated out of ICO 1 still contains one message, with all employee data records in its body. However, these are not randomly put into the file anymore, but are sorted by Country Code. Also, the element ‘EDI_Separator_Identifier’ has been added at top level, and is filled with constant value: System_A_EmployeeData. This element and its value are taken into further consideration in Integrated Configuration #2.

Integrated Configuration #2
Now the sorting part of the required scenario has been setup, and the XSLT mapping has been assigned, it is time to setup a second Integrated Configuration. The most interesting part of below screenshot is the Communication Component. This component is named EDI_SEPARATOR_XML, and is not the same component as was used as receiving component of ICO #1. Hence, it does not matter which of the EDI Separator components should be taken as Sender Communication Component as long as it’s a component of Adapter type EDI Separator. The explanation for this can be found in the sender communication channel, as described below.

Figure: ICO #2 for the second part of message processing

When a message gets posted to a receiver EDI Separator channel, SAP PRO 7.5 automatically looks into all sender EDI Separator channels and seeks for a channel where the parameters match the content of the message. These parameters are to be set in the Filter part of the sender communication channel, as visible below. This XPath expression seeks for the element called EDI_Separator_Identifier that has been added in the intermediate structure and has been filled by the XSLT mapping with value: System_A_EmployeeData. When the message content matches these parameters, this particular sender Communication Channel will be chosen.

Also of great importance is the parameter that needs to be filled under XML Handling options/XML Split Path. Here it should be defined via XPath expression where SAP PRO 7.5 should make the actual message split. With below settings, the message will be split at each occurrence of node Country.

Figure: EDI Separator sender channel configuration in ICO #2 for xml split

Since the rest of ICO #2 is just a normal setup, this will not be taken into further consideration by using screenshots. In the next steps of this ICO it is possible to determine a receiver (in this case System B), add another mapping and to define the receiver communication channel (of System B). There still is a special point of attention within Integrated Configuration #2, which will be explained now.

Mapping and output of Integrated Configuration #2
Once a message has been split into multiple ones, the XSD of the output message is not equal to the input message – in this blog called the ‘Intermediate structure’. More specifically, the node which is defined as the XML Split Path parameter will be used as top node of the output structure. In this example the node ‘Country’ will be the top node of all split messages, and not the node ‘Message’ or element ‘EDI_Separator_Identifier’. This also applies for the very first output message, meaning that all data elements that are placed before the node ‘Country’ will be ignored and not be visible in the output of the XML Split.

This is also of great importance when defining another mapping in ICO #2, because the source structure should be starting with the node as defined as the XML Split Path parameter. In this example, the source XSD should not be starting with element ‘Message’, but with element ‘Country’.

To wrap up, there are two points of attention:

  • Sender EDI Separator channel will be picked based on the parameters given in this channel
  • The output data structure after message split, incorporating possible data transformation through mapping, elements contained in the output data structure.

Conclusion
SAP B2B Adapters are gaining more popularity amongst organizations who have deployed the SAP PI/PO/PRO as a middleware solution. Organizations who have deployed third party B2B adapters are migrating scenarios running on such adapters to the SAP B2B adapter offerings. With these possibilities, organizations are able to standardize their landscape with a middleware solution that can handle both A2A and B2B scenarios as explored in these blog series.To conclude these two blog series, we have touched on the business requirements as well the technical details required to set up this scenario successfully. The scenario description in line with the business requirements explains the suitability of using the EDI separator adapter to achieve the demands of the business requirements.Additionally, explicit technical details were provided on how to achieve the following:

  • Sort a complex message using XSLT to a structured message as a prerequisite for split up by the adapter
  • Set up the EDI Separator Sender channel with necessary technical details required by the EDI Separator receiver channel in the first ICO to locate this channel

So, are split ups still hard? Hopefully this blog series makes life easier and provided new insights in how to achieve a message split without using ccBPM or BPM. Instead, it was explained how to leverage the B2B add-on in SAP PRO in order to accomplish the split.

You have got questions? Get in touch!

Written by:

Ronan Mol
Abidemi Olatunbosun

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Maximilian Hartig

    Hello,

     

    Sounds good for one scenario. But, if we have a second scenario where we use the EDISeparator and only one EDI Separator Sender Communication Channel has an issue, all your EDISeparator scenarios are stopped, because of this one channel. Also, it is no longer clear in the monitoring from which system the source message came from, as in the second step (EDISeparator Sender to receiving end system) you will see EDISeparator as sending component only.

    Therefore, please be very careful when using the EDI Separator for XML files.

    (0) 

Leave a Reply