Introduction
Hello dear B2B Community,
As a follow up on the B2B Integration Factory packages, I also want to illustrate how the packages interact with the B2B Monitoring API and show you what it looks like based on the use cases and highlight the crucial role that B2B Monitoring plays for customer’s daily business. I will also talk about Custom Search Attributes, which can be tailored to the specific company needs and used to enhance the search experience.
B2B Monitoring
Let’s have a look how the B2B Monitoring helps the business to monitor the processing status of the interchanges.
Use case 1:
The company sends an INVOIC.INVOIC02 IDoc and the partner expects a ASC-X12 810. Moreover, the company expects a functional acknowledgement ASC-X12 997 back.
Note: In the TPM, you can define the waiting time for technical and functional acknowledgements:
Once the company sends the message, an interchange can be seen in the B2B Monitoring. The entry can be expanded. The Status is set to ‘Waiting for Acknowledgement’:
The Processing Status is in Completed state, which means the ASC-X12 810 is successfully send to the Trading Partner. However, a 997 functional acknowledgment has not been send back from the Trading Partner yet. If this is not being received in the time frame defined in the TPM, the status will change from ‘Waiting for Acknowledgement’ to ‘Acknowledgement Overdue’
If an Accepted 997 is received, the status will change to ‘Completed’
If a Rejected 997 is received, the status will change to ‘Failed’:
Further, you also have the opportunity to view the payloads (Sender Interchange Received, Receiver Interchange Assembled (Sent message) and the Functional Acknowledgement Received message:
Note: it is also possible to process a 997 further and map it for example to a STATUS.SYSTAT01 IDoc.
Use case 2:
The company sends a bulk INVOIC.INVOIC02 IDoc, which need to be splitted into several UN-EDIFACT INVOIC (Bulk is not supported by the Standard solution yet, therefore go via B2B Integration Factory packages).
Note: In the specific Trading Partner Agreement, you need to define two parameters.
The first is to define whether it is a bulk message and the second is to define the XML Split Path, i.e.:
A message with 4 IDOC instances will be sent:
In B2B Monitoring:
Here we can see that the company has sent an interchange (bulk INVOIC.INVOIC02 IDoc). Out of this interchange, 4 UN-EDIFACT INVOIC messages have been created and send to the Trading Partner.
Additionally, for operations, you have the opportunity to set Custom Search Attributes. You have to set it in the TPA, like for instance:
In B2B Monitoring:
Note: It is also possible to filter for messages based on the custom search attributes.
Use case 3:
The company sends a bulk INVOIC.INVOIC02 IDoc, which need to be gathered into one UN-EDIFACT INVOIC.
Note: In the specific Trading Partner Agreement, you need to define the two parameters from Use case 2 and two additional parameters.
The additional first is to define whether it is required to gather the splitted messages and the additional second is to define a XML root tag:
Similar message from Use Case 2 will be sent.
In B2B Monitoring:
Compared to Use case 2, here we only see one message as we did not want to create several documents, but instead gather the message and send one UN-EDIFACT INVOIC.
From all 4 IDOC Instances the unique Invoice Numbers are written into the B2B Monitoring and each Invoice Number could be searched by using wildcards:
Use case 4:
The partner sends a bulk UN-EDIFACT SLSRPT (42 UNH+ segments) and on the target side a csv file should be placed into a SFTP Server (not supported by the Standard). Here for each message we additionally want to log a dynamic Filename. So in B2B Monitoring, we will see 43 entries. One is the Interchange Received and 42 csv messages are created and send to the SFTP Server. Prior certain Activity parameters must be maintained. One parameter to state that the target format is csv. The other to call the extension point which does the XML to CSV conversion. The other to define a dynamic filename, which will be resolved during runtime and one to choose whether parallel processing of EDI Splitter is desired (optional).
In B2B Monitoring:
Use case 5:
Let’s say a message is in Failed state, business analyzed and did some corrections and triggered a message manually which created a new Completed entry. Now, the user has the chance to set the Failed message to Cancel to mark it as a permanent failure (By the way, this feature was driven internally by our services 💪)
Use case 6:
Let’s say for certain messages you only want to have a simple pass-through without any transformation.
Note: In the specific Trading Partner Agreement, you need to define one parameter.
Expanding the entry and you will see that both Payloads are the same (Sender Interchange Received and Receiver Interchange Assembled)
Conclusion
In Business-To-Business especially monitoring plays an essential role. B2B Monitoring@SAP Integration Suite allows the consumer to analyze its daily activities effectively, which helps the business to operate successfully.
IntroductionHello dear B2B Community,As a follow up on the B2B Integration Factory packages, I also want to illustrate how the packages interact with the B2B Monitoring API and show you what it looks like based on the use cases and highlight the crucial role that B2B Monitoring plays for customer’s daily business. I will also talk about Custom Search Attributes, which can be tailored to the specific company needs and used to enhance the search experience. B2B MonitoringLet’s have a look how the B2B Monitoring helps the business to monitor the processing status of the interchanges. Use case 1: The company sends an INVOIC.INVOIC02 IDoc and the partner expects a ASC-X12 810. Moreover, the company expects a functional acknowledgement ASC-X12 997 back.Note: In the TPM, you can define the waiting time for technical and functional acknowledgements:Once the company sends the message, an interchange can be seen in the B2B Monitoring. The entry can be expanded. The Status is set to ‘Waiting for Acknowledgement’:The Processing Status is in Completed state, which means the ASC-X12 810 is successfully send to the Trading Partner. However, a 997 functional acknowledgment has not been send back from the Trading Partner yet. If this is not being received in the time frame defined in the TPM, the status will change from ‘Waiting for Acknowledgement’ to ‘Acknowledgement Overdue’If an Accepted 997 is received, the status will change to ‘Completed’If a Rejected 997 is received, the status will change to ‘Failed’:Further, you also have the opportunity to view the payloads (Sender Interchange Received, Receiver Interchange Assembled (Sent message) and the Functional Acknowledgement Received message:Note: it is also possible to process a 997 further and map it for example to a STATUS.SYSTAT01 IDoc.Use case 2: The company sends a bulk INVOIC.INVOIC02 IDoc, which need to be splitted into several UN-EDIFACT INVOIC (Bulk is not supported by the Standard solution yet, therefore go via B2B Integration Factory packages).Note: In the specific Trading Partner Agreement, you need to define two parameters. The first is to define whether it is a bulk message and the second is to define the XML Split Path, i.e.:A message with 4 IDOC instances will be sent:In B2B Monitoring:Here we can see that the company has sent an interchange (bulk INVOIC.INVOIC02 IDoc). Out of this interchange, 4 UN-EDIFACT INVOIC messages have been created and send to the Trading Partner.Additionally, for operations, you have the opportunity to set Custom Search Attributes. You have to set it in the TPA, like for instance:In B2B Monitoring:Note: It is also possible to filter for messages based on the custom search attributes. Use case 3: The company sends a bulk INVOIC.INVOIC02 IDoc, which need to be gathered into one UN-EDIFACT INVOIC.Note: In the specific Trading Partner Agreement, you need to define the two parameters from Use case 2 and two additional parameters.The additional first is to define whether it is required to gather the splitted messages and the additional second is to define a XML root tag:Similar message from Use Case 2 will be sent.In B2B Monitoring:Compared to Use case 2, here we only see one message as we did not want to create several documents, but instead gather the message and send one UN-EDIFACT INVOIC.From all 4 IDOC Instances the unique Invoice Numbers are written into the B2B Monitoring and each Invoice Number could be searched by using wildcards:Use case 4: The partner sends a bulk UN-EDIFACT SLSRPT (42 UNH+ segments) and on the target side a csv file should be placed into a SFTP Server (not supported by the Standard). Here for each message we additionally want to log a dynamic Filename. So in B2B Monitoring, we will see 43 entries. One is the Interchange Received and 42 csv messages are created and send to the SFTP Server. Prior certain Activity parameters must be maintained. One parameter to state that the target format is csv. The other to call the extension point which does the XML to CSV conversion. The other to define a dynamic filename, which will be resolved during runtime and one to choose whether parallel processing of EDI Splitter is desired (optional). In B2B Monitoring:Use case 5: Let’s say a message is in Failed state, business analyzed and did some corrections and triggered a message manually which created a new Completed entry. Now, the user has the chance to set the Failed message to Cancel to mark it as a permanent failure (By the way, this feature was driven internally by our services 💪) Use case 6: Let’s say for certain messages you only want to have a simple pass-through without any transformation. Note: In the specific Trading Partner Agreement, you need to define one parameter. Expanding the entry and you will see that both Payloads are the same (Sender Interchange Received and Receiver Interchange Assembled)ConclusionIn Business-To-Business especially monitoring plays an essential role. B2B Monitoring@SAP Integration Suite allows the consumer to analyze its daily activities effectively, which helps the business to operate successfully. Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
