Introduction
Hello dear B2B Community,
in this Blog post I would like to demonstrate the latest key features that are available in the B2B Integration Factory packages.
The new key features are:
Restart/Retry failed messages from B2B MonitoringIDocFlat Handling inbound & outboundMulticasting one sender interchange to multiple receiversImprovement for bulk messaging in B2B Monitoring
Please make sure to download the latest packages from SAP Business Accelerator Hub or to update the packages to the latest versions and deploy all relevant flows.
Restart/Resend failed messages from B2B Monitoring
It is now possible to restart or retry failed messages directly from the B2B Monitoring. This is also possible in the standard version. The difference between restart and retry is that restart re-initiates the message processing from the beginning whereas retry tries to send the message directly to the target, for example due to temporary connectivity issues. In order to use this feature, we have to create a Destination on SAP BTP Cockpit in the respective subaccount. The configuration should look as follows:
URL: https://<host>/http/tpm/internal/repost_endpoint
That is it. We can use this feature now for failed messages. In the B2B Monitoring:
Note: In this case the message failed, because the connection details are not set on the target side. Hence, I do not need to restart the message from the beginning, but retry.
Stating the reason for the action:
Afterwards, you should see that the message could be restarted or retried:
Refresh the page and check the status again. You will also see the note inside the relevant B2B Monitoring entry:
Note: It is also possible to select multiple failed messages and to restart or retry in bulk.
IDocFlat Handling inbound
Another big milestone, which is only available in the B2B Integration Factory is the IDocFlat handling in both directions. For inbound transactions, we would need to convert the target IDoc-XML to IDocFlat. The conversion will happen with the IDoc Meta-Information, which will be fetched based on the IDocType and its extension via a RFC call.
The RFC destination should be maintained in this flow:
Once this is done, we only have to maintain two parameters in the relevant TPA as an activity parameter:
It is very important to understand that this is a generic approach and applicable for all given message types. In runtime it will be generically determined which message type to transform the message to.
Finally, in B2B Monitoring the target payload format is also seen in IDocFlat:
IDocFlat Handling outbound
For outbound transactions, we would need to convert the target IDocFlat to IDoc-XML. The conversion will happen similar to the inbound case with the IDoc Meta-Information.
The RFC destination should be maintained in this flow:
No additional parameters in the relevant TPA have to be maintained. You only need to create for example a Step1a – SFTP.Sender Flow where you pick the IDocFlat messages, do not set the Content-Type and pass it to Step1b in the generic flows.
Finally, in B2B Monitoring the source payload format is also seen in IDocFlat:
Multicasting one sender interchange to multiple receivers
There could be the use case where you need to send the source payload to multiple receivers. Especially in migrations this makes sense to send the ORDERS UN-EDIFACT message as an IDoc to the ECC system, but at the same time prepare for the new technology and send the same message from the Trading Partner to the SAP S/4HANA Cloud system as a SOAP message. The problem in this use case is within inbound transactions, because the Trading Partner details are in both scenarios the same. This leads to a unique PID violation. Following shows the overview of a Trading Partner Agreement:
The Type System and the type system version of Company and Trading Partner is an essential part of the PID. For outbound the type system is IDoc OnPremise and SOAP Cloud. Therefore we do not run into PID violations. For inbound, we will go via manipulation. In the relevant BTA, we can change the type system version manually and that is what we will do.
In the first agreement (here: POC_ECC) we will maintain two parameters, one saying that a multicast is required and one passing the manipulated type system version which is needed only for the PID computation:
Now in the second agreement (here POC_S4) we have the same Trading Partner Details, but different Company Details. Now in the BTA, we manually change the type system version and activate the agreement:
Finally, in B2B Monitoring, we receive one message and create two interchanges:
Improvement for bulk messaging in B2B Monitoring
If you refer to my previous Blog post The importance of B2B Monitoring in customer’s day-to-day B2B operations you will see how the B2B Monitoring helps the business to monitor the processing status of the interchanges and therefore we need to continuously improve wherever we can. If you look at use case 4 where the partner sends a bulk UN-EDIFACT SLSRPT (42 UNH+ segments) we could see 43 entries in B2B Monitoring. One is the bulk Interchange Received and 42 are the splitted messages. In these 42 entries we could only see each splitted target payload. Now, it is also possible to see the splitted source payload and to correlate each splitted target message with the source message.
Now, let’s jump into the one of the splitted entries and you can see the Interchange Split event:
Outlook
Ultimately, the B2B Integration Factory ensures that you can implement your additional B2B integration requirements in time. Which requirements are crucial for your B2B business that you would like to see in the product?
IntroductionHello dear B2B Community,in this Blog post I would like to demonstrate the latest key features that are available in the B2B Integration Factory packages.The new key features are:Restart/Retry failed messages from B2B MonitoringIDocFlat Handling inbound & outboundMulticasting one sender interchange to multiple receiversImprovement for bulk messaging in B2B MonitoringPlease make sure to download the latest packages from SAP Business Accelerator Hub or to update the packages to the latest versions and deploy all relevant flows.Restart/Resend failed messages from B2B MonitoringIt is now possible to restart or retry failed messages directly from the B2B Monitoring. This is also possible in the standard version. The difference between restart and retry is that restart re-initiates the message processing from the beginning whereas retry tries to send the message directly to the target, for example due to temporary connectivity issues. In order to use this feature, we have to create a Destination on SAP BTP Cockpit in the respective subaccount. The configuration should look as follows:URL: https://<host>/http/tpm/internal/repost_endpointThat is it. We can use this feature now for failed messages. In the B2B Monitoring:Note: In this case the message failed, because the connection details are not set on the target side. Hence, I do not need to restart the message from the beginning, but retry. Stating the reason for the action:Afterwards, you should see that the message could be restarted or retried:Refresh the page and check the status again. You will also see the note inside the relevant B2B Monitoring entry:Note: It is also possible to select multiple failed messages and to restart or retry in bulk.IDocFlat Handling inbound Another big milestone, which is only available in the B2B Integration Factory is the IDocFlat handling in both directions. For inbound transactions, we would need to convert the target IDoc-XML to IDocFlat. The conversion will happen with the IDoc Meta-Information, which will be fetched based on the IDocType and its extension via a RFC call. The RFC destination should be maintained in this flow:Once this is done, we only have to maintain two parameters in the relevant TPA as an activity parameter: It is very important to understand that this is a generic approach and applicable for all given message types. In runtime it will be generically determined which message type to transform the message to. Finally, in B2B Monitoring the target payload format is also seen in IDocFlat:IDocFlat Handling outbound For outbound transactions, we would need to convert the target IDocFlat to IDoc-XML. The conversion will happen similar to the inbound case with the IDoc Meta-Information. The RFC destination should be maintained in this flow:No additional parameters in the relevant TPA have to be maintained. You only need to create for example a Step1a – SFTP.Sender Flow where you pick the IDocFlat messages, do not set the Content-Type and pass it to Step1b in the generic flows. Finally, in B2B Monitoring the source payload format is also seen in IDocFlat:Multicasting one sender interchange to multiple receivers There could be the use case where you need to send the source payload to multiple receivers. Especially in migrations this makes sense to send the ORDERS UN-EDIFACT message as an IDoc to the ECC system, but at the same time prepare for the new technology and send the same message from the Trading Partner to the SAP S/4HANA Cloud system as a SOAP message. The problem in this use case is within inbound transactions, because the Trading Partner details are in both scenarios the same. This leads to a unique PID violation. Following shows the overview of a Trading Partner Agreement: The Type System and the type system version of Company and Trading Partner is an essential part of the PID. For outbound the type system is IDoc OnPremise and SOAP Cloud. Therefore we do not run into PID violations. For inbound, we will go via manipulation. In the relevant BTA, we can change the type system version manually and that is what we will do. In the first agreement (here: POC_ECC) we will maintain two parameters, one saying that a multicast is required and one passing the manipulated type system version which is needed only for the PID computation:Now in the second agreement (here POC_S4) we have the same Trading Partner Details, but different Company Details. Now in the BTA, we manually change the type system version and activate the agreement:Finally, in B2B Monitoring, we receive one message and create two interchanges:Improvement for bulk messaging in B2B MonitoringIf you refer to my previous Blog post The importance of B2B Monitoring in customer’s day-to-day B2B operations you will see how the B2B Monitoring helps the business to monitor the processing status of the interchanges and therefore we need to continuously improve wherever we can. If you look at use case 4 where the partner sends a bulk UN-EDIFACT SLSRPT (42 UNH+ segments) we could see 43 entries in B2B Monitoring. One is the bulk Interchange Received and 42 are the splitted messages. In these 42 entries we could only see each splitted target payload. Now, it is also possible to see the splitted source payload and to correlate each splitted target message with the source message.Now, let’s jump into the one of the splitted entries and you can see the Interchange Split event:OutlookUltimately, the B2B Integration Factory ensures that you can implement your additional B2B integration requirements in time. Which requirements are crucial for your B2B business that you would like to see in the product? Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
