Quick Overview – B2B Scenario with Seeburger EDI-Adapter (using Integrated Configuration)
In January, I had created the following blog about setting up a B2B End2End-Scenario with the Seeburger EDI-Adapters.
It explains the basic concept of handling EDI-Data with the “Classifier/BIC/Splitter” approach.
In the meantime, I got a lot of direct feedback to this scenario and the question, to create something similar als for the new PI environments (especially for PI 7.31 Java Only, which is the system that I am using in this scenario together with the lastest release 2.2 of the seeburger EDI-Adapters).
So in this blog, I am describing another scenario where an ANSI X12 850 file is received via AS2, processed through the PI-System and forwarded to the SAP Backend. Additionally a 997-message (Acknowledgement) is also created and sent back to the original Sender of the 850 message.
The focus is hereby completely on the “Integrated Configuration” and not on the settings in the channel (Classifier/BIC/Splitter). If you have questions to this, please refer to the mentioned previous blog.
Introduction to the Demo-Scenario :
The following picture describes the case, where the customer “Mex_Electric” is sending an 850-message via his AS2-Provider “Mex_AS2Provider” to an SAP PI-Server PIJ and receives back the 997 message.
The Testfile looks like this:
Involved Parties :
The following 3 Parties are setup on the system PIJ.
The Parties starting with “EDI_SP” are used for the AS2 transmission, while the party “EDI_BP” refers to a Business Partner.
1. ) EDI_SP_Mex_AS2Provider
The Party “EDI_SP_Mex_AS2Provider” is the Sender of the message (using AS2).
It includes the AS2-ID of the partner…
…as well as the required channels (to receive the data and to receive the MDN)
2. ) EDI_SP_PI731_AS2HUB
The Party “EDI_SP_PI731_AS2HUB” is only used for the AS2-data-exchange (to hold the AS2-ID of the PI-Server.
(there are no channels assigned to this Party or the corresponding AS2-Component)
This party is used to process the real business data (ANSI X12 850 V4010 messages) after the “Classifier/BIC/Split” – Handling has extracted the real data for further processing:
The party includes a Communication Component “BC_9876543210987”, referring to the Sender-Code in the ISA-Segment, as well as the Interface and the Split-Channel.
Setup of the Integrated Configuration
The scenario consists of 2 different cases of the “Integrated Configuration”.
Part 1 – Receiving the data via AS2 and sending back the corresponding Functional Acknowledgement (997)
Part 2 – Processing the 850 data to an ORDERS05 IDoc and transmission to SAP Backend
…and an additional option, to use an Integrated Configuration to process the MDN is described at the end of this blog.
Integrated Configuration for Part 1 :
“Receiving the data via AS2 and sending back the corresponding Functional Acknowledgement (997)”
The initial screen of the Integrated Configuration includes the Sender/Receiver-Parties (which contain the AS2 IDs) as well as the inbound Channel and all required certificates/keys to receive the data via AS2 (using signing/encryption)
The inbound channel executes the “Classifier/BIC/Splitter” (please refer to the earlier blog for this concept). As a result, the Functional Acknowledgement is created as MainDocument and can be processed furtehr to send a 997 message back to the Sender of the data. (Mex_AS2Provider)
A Mapping is executed to transform the FunctionalAcknowledgement to a 997 message.
(other options would be the EDIFACT CONTROL or any custom-defined report/acknowledgement )
In the last step of the “Integrated Configuration” , the Channel is selected to send the 997 message back to the original sender of the ANSI X12 850 message.
A Header Mapping is needed, to use the correct AS2IDs for this transmission (as now the AS2HUB is the Sender and the Mex_AS2Provider is the Receiver)
Integrated Configuration for Part 2:
Processing the 850 data to an ORDERS05 IDoc and transmission to SAP Backend
To process the 850 data, the initial screen of the Integrated Configuration refers to the inbound Split-Channel which picks up the “split attachment” that was created during the “Classifier/BIC/Splitter” – Handling while the file had been received via AS2.
As receiver of the messages, I have in this case specified two different SAP Backend Systems (SER; SEO)
For each system, a mapping will be executed to convert the 850 to an ORDERS05-IDoc
For the Outbound Processing, an IDoc_AAE-Adapter Channel is used to transmit the ORDERS-IDoc to the SAP Backend(s)
Result in the Runtime Workbench:
In the Runtime Workbench you can see the following lines :
1.) File received via AS2 from Mex_AS2Provider and 997 sent back via AS2 to Mex_AS2Provider
2.) 850 attachment translated to an ORDERS-IDoc and forwarded to system SERCLNT800
3.) 850 attachment translated to an ORDERS-IDoc and forwarded to system SEOCLNT800
Additional Configuration possibilities:
(processing inbound MDN messages via Integrated Configuration)
If the partner “Mex_AS2Provider” is requested to send a MDN back (to confirm that he has received the 997 successfully via AS2) and if the MDN shall be processed also in PI (e.g. to update a status message in the SAP Backend) an additional “Integradted Configuration can be setup to pick-up and process the Delivery Notification:
As always, feel free to provide feedback, if you are missing something or would like to have additional clarification on any issue.
Looking forward to your comments…
Many thanks for sharing this interesting blog with the PI community!
Question; can you share with us if you noticed some performance improvement in comparison with the non-java-only scenario in PI?
Could you please confirm if you used Process Orchestration - PO for this test?
Greetings, Roberto Viana
thank you for your comments...
- regarding performance improvements I haven´t made any tests yet, but this is a good idea. Will have to check about the setup of the 2 systems (HW, OS...) to see if a comparison is feasable.
- regarding the confirmation...the system I used was installed as a Stand-Alone PI 7.31 System, but per my understanding the features should be the same as it it was installed as a part of PO 7.31.
Thanks for sharing, I could probably have saved some time on my AS2 problem if I had read this post before setting up the AS2 with ICO.
enjoyed reading this 🙂
excellent blog.............keep blogging.. 🙂
I am new to Seeburger and read this blog and configured conrrectly.
This was quite excellent and really helpful.
I have 2 question.
1) Suppose i receve 2 different transaction types from partner,say 1 to my ECC system and 1 to my CRM system do i have to create 2 different inegrated configuration to send back the EDI 997 acknowledgment with one virtual receiver for ECC and 1 virtual receiver for CRM?.
2) If i select NO MDN option do i have to configure anything extra?
1) No, you just have to create one entry to send back the 997 to your partner, since the 997 cionfirms that the incoming message has correct syntax and could be processed.
(the 997 is prepared independent from whatever is happening later on to the real data)
2) I don´t think so
Thank you Stefan for the reply.
I was able to successfully complete my Seeburger AS2 scenario with help of many inputs from you in different discussions.
The only question remaining in my mind is that in case of one of our partners we noticed an additional newline character at end of the EDI file after the IEA segment. We used the source option setIgnoreCRLF = true and it worked as a standalone in BIC mapper and produced the EDI XML file but did not work when we deployed it in PI server. Any idea why this option works in BIC mapper and not works when we deploy it in PI server?
Good reading. I have a question, hope you don´t mind to answer: does that configuration work for Direct Connect Protocol?