Introduction
We looked at handling EDI Functional Acknowledgments for incoming EDI Messages in Part 7 of this series. We will now look at how Integration Suite handles EDI Functional Acknowledgements for outgoing messages. The challenge in this case, you are at the mercy of your Trading Partner who can generate the Functional Acknowledgment at his “speed” and that means that it is upto Integration Suite to handle the “wait” for Acknowledgements.
We will use the same flow we built in Part 4 ,i.e., we will get an IDoc from ERP and push this as an EDI DESADV D96A to our Trading Partner. While doing that we will now request for a Functional Acknowledgement from our Trading Partner and handle the Functional Acknowledgment from the Trading Partner.
Pre-requisites
Ensure you have reached this post after you have done all the configurations needed in Part 3 and Part 4 of this series.
Change TPM Agreement for Receiver Functional Acknowledgement
Navigate to your Integration Suite, B2B Scenarios and the Agreement we created in Part 4 “Company_Self – ERPCLNT200 Sends IDoc To Customer2 over EDI AS2“.
Go to the Receiver Interchange section of your Agreement and select the option “Enable Receiver Functional Acknowledgement” in the section Receiver Functional Acknowledgement.
When you now select this tick box, you would need to fill in the Receiver Functional Acknowledgement Channel in the Receiver Communication. And, guess what this is where the fun starts. You will ideally expect your AS2 Sender Channel of your Partner created in Part 3 to be displayed here but it will not show up. You will not be allowed to Save your Agreement as this is mandatory to be filled in. Discard your changes and continue as you need a workaround.
Create a Dummy AS2 Sender Channel for “Self” Company Profile
As we have seen in this post of this series, we have in the Company Profile , created a Company called “COMPANY_SELF” to identify “ourselves” . Navigate to this COMPANY_SELF aka your own Company Profile and create a Dummy AS2 Sender Channel. This is “just” a dummy channel that is not used in the runtime but this allows us to activate our TPM for Receiver Functional Acknowledgements.
Why a AS2 Sender channel and why not a Sender SFTP ProcessDirect channel – well thats what it is – TPM in its current version ( Nov 2023) and only allows FAs with AS2 channels. So lets get our scenario working and create a Dummy Sender AS2 Channel for our Company Profile. This is a self explanatory and below screenshots will do the trick.
Navigate to Company Profile -> Systems –> ERP_ECC ( as our system was called) –> Communications and create a Dummy AS2 Sender Channel
Change TPM Agreement for Receiver Functional Acknowledgement
Now that we have created a AS2 Sender Channel with Dummy Parameters under our Company Profile, lets go back to our TPM Agreement and Enable Receiver Functional Acknowledgement” in the section Receiver Functional Acknowledgement.
Navigate to the Receiver Communication and now you will be able to see Receiver Functional Acknowledgement Channel drop down show the AS2_DUMMY_SENDER we created in the previous step.
Click on Save and Update ( Activate) your Agreement to deploy the Content to Partner Directory.
Test for Functional Acknowledgement
We are done with our configuration and ready to test our process. Before we push the data out, lets enable the trace on the Integration Flow Step 2 – Interchange Processing Flow V2. Once you trigger the IDoc ( DESADV.DELVRY03) for this flow, you will see the message reach your AS2 receiver – Mendelson AS2.
Check B2B Monitoring
If you now navigate to B2B Monitoring in Integration Suite, you will notice that your message is in Status “Waiting For Acknowledgement“. This makes sense as your Functional Acknowledgement is still pending to be sent from your Trading Partner.
Detailed Logs in B2B Monitoring Shows below
- Status and Processing Status : Waiting For Acknowledgement ( Functional)
- Receiver Technical Acknowledgment Status : Acknowledged ( As we have sent a Synchronous MDN back )
- Events section shows the below event(s)
- Sender Interchange Received – For IDoc Sender
- Sender Interchange Mapped – For Mapping
- Receiver Interchange Assembled – For EDI XML to EDI Conversion
- Receiver Interchange Sent – For Sending EDI over AS2
- Technical Acknowledgement Received ( for Sender Receiver Interchange) – For the Synchronous MDN Received.
Check Step 2 – Interchange Processing Flow V2
Check the Trace of this Flow and you will notice that because we have Enable Receiver Functional Acknowledgement selected, Integration Suite writes a message to the Datastore: SAP_BTA_CorrelationDataStore in the subprocess “Assemble Receiver Interchange” to co-relate the Incoming Functional Acknowledgement Message with the Outgoing Message. This IFlow persists the message in the Datastore that is then used when we receive the Incoming FA.
The format of this message is as below:
<BusinessTransactionActivity>
<AgreementID>${property.Agreement_ID}</AgreementID>
<BusinessTransactionID>${property.Transaction_ID}</BusinessTransactionID>
<BusinessDocumentID>${property.Document_ID}</BusinessDocumentID>
<InterchangeControlNumber>${property.SAP_EDI_REC_Interchange_Control_Number}</InterchangeControlNumber>
<SenderTradingPartnerID>${property.SAP_TPA_SND_Trading_Partner_ID}</SenderTradingPartnerID>
<ReceiverTradingPartnerID>${property.SAP_TPA_REC_Trading_Partner_ID}</ReceiverTradingPartnerID>
<InterchangeDateTime>${header.SAP_EDI_Interchange_DateTime}</InterchangeDateTime>
<FunctionalAckRequest>${property.SAP_EDI_REC_Acknowledgement_Request}</FunctionalAckRequest>
</BusinessTransactionActivity>
A real message when peeked into the Datastore looks like
<BusinessTransactionActivity>
<AgreementID>715dd31844a24bfaa73b1a9e73cbcb28</AgreementID>
<BusinessTransactionID>715dd31844a24bfaa73b1a9e73cbcb28</BusinessTransactionID>
<BusinessDocumentID>8802ff7419b6b71a9e5105d281cd6a79</BusinessDocumentID>
<InterchangeControlNumber>254</InterchangeControlNumber>
<SenderTradingPartnerID>myCompany</SenderTradingPartnerID>
<ReceiverTradingPartnerID>010eb2d9edfb40d092a732d7956ba6fe</ReceiverTradingPartnerID>
<InterchangeDateTime>2023-09-14T15:20:09</InterchangeDateTime>
<FunctionalAckRequest>true</FunctionalAckRequest>
</BusinessTransactionActivity>
EDI Message Generated by Integration Suite
Look at the UNB Segment ( as this is a an EDIFACT EDI message) and you will notice that we now have the Functional Acknowledgement required flag set as 1 in the UNB Segment. Integration Suite add the this flag automatically taking the setting as defined in our TPM Agreement.
UNB+UNOC:3+SELF_1234:30+CUSTOMER2:30+231109:1402+253++++1'
UNH+188617135+DESADV:D:96A:UN:A01051'
BGM+351+28841095'
DTM+137:202309150317:203'
RFF+AAS:28841095'
Generate a FA
So far so good, we have now transmitted a EDI Message to our Trading Partner over AS and requested for a FA in the EDIFACT control record. We have also seen that in B2B monitoring, our message has the status “Waiting For Acknowledgement“.
Now that we have reached this far, lets generate a FA for the EDIFACT message. If you notice the EDI Message, our ICN number was 253. We will generate the EDIFACT CONTROL Message for this Message. Below is how the equivalent FA would look like for this EDIFACT Message we have sent.
UNB+UNOC:3+CUSTOMER2:30+SELF_1234:30+231108:1112+000000005'
UNH+00004+CONTRL:2:2:UN'
UCI+253+SELF_1234:30+CUSTOMER2:30+8'
UCM+188617135+DESADV:D:96A:UN+8'
UNT+4+00004'
UNZ+1+000000005'
Send the FA Back over AS2
As we have seen in Part 3, we will trigger this FA back using Mendelson AS2. Essential to call out that even though we have created a “Dummy” AS2 Sender channel for our Company Profile that is not used in the runtime at all! Just send your EDIFACT FA back to Integration Suite over AS2. Ensure you have trace on in the Iflow Step 2 – Interchange Processing Flow V2
Mendelson will show the AS2 Message ( EDIFACT CONTROL FA) sent successfully and synchronous MDN received back.
Check B2B Monitoring
You will now notice that that your message has the status “Completed“. Additionally you will notice the below status changes in the detailed logs
- Status and Processing Status : Changed from Waiting For Acknowledgement ( FA) to Completed
- Receiver Technical Acknowledgment Status : Acknowledged ( No change)
- Events shows the below additional events
- Functional Acknowledgement Received – As we have now sent a FA back
- Technical Acknowledgement Sent (for Received Functional Acknowledgement) – Synchronous MDN Back for the FA.
Check Step 2 – Interchange Processing Flow V2
The message is identified as a EDIFACT Functional Acknowledgment and then the corresponding Correlating Message is taken from the Global Data Store SAP_BTA_CorrelationDataStore and the message is deleted from the SAP_BTA_CorrelationDataStore datastore and of course the events are flagged as completed.
Message is identified as a FunAck and sent to subprocess : Functional Acknowledge Interchange
Correlating Message is is read from the Datastore and the original message status / events updated.
Our Happy Flow is done, we have now generated the FA and closed the entire B2B Message. We have also deleted the corelating message from the Datastore.
What Happens if a Message is not Acknowledged At all?
Well as of now in Nov 2023, there is no automated Alerting for B2B Transactions. This is in the roadmap of SAP Integration Suite Q1 and Q2 2024 roadmap items. Until then you would ideally need to look at automating this with custom solutions .
You do not also have control on how long the message are persisted in the Datastore from SAP. Retention for Alerting is 1 day and Expiration 5 days . These are not configurable parameters in the Standard Flows ( disclaimer as of Nov 2023) which is a pity! Also be aware that current hardcoding of the Datastore means your Trading Partner needs to acknowledge the message in a max 5 days else the Datastore is cleaned and your message is always in Waiting for Acknowledgement status.
What if you want to send FAs back to your ERP
In most EDI implementations I have worked on, Functional Acknowledgements are actually treated as FAs. This means that the FAs are sent back to ERP ( SAP ECC and S/4) as SYSTAT IDocs, updating the status of the Original IDoc. This helps tracking all the way back in ERP if the message has been processed by the Trading Partner.
TPM in its current implementation as we can see in the processing of the FA’s in the IFlow Step 2 – Interchange Processing Flow V2 provides no option to map this to a SYSTAT or any other IDoc format. This is rather unfortunate as this leaves a gaping hole in the process. Hopefully the next release of TPM ( more the Step 2 – Interchange Processing Flow V2 ) allows for Customers to determine how they want to process FAs rather than just terminating them with the B2B Monitoring in Integration Suite.
This is amongst a few of the reasons there exist alternate solutions that have been documented and posted here SAP EDI/IDoc Communication in CPI Using Bundling and Fewer Mapping Artifacts by Ryan Crosby
Incoming FAs over SFTP and ProcessDirect
Unlike outgoing FAs as seen in Part 7, incoming FAs will work over SFTP and other custom adapters. The reasoning for that being we only create a DUMMY AS2 Sender channel in the Company Profile and that is not in use in the runtime.
Final Thoughts
SAP’s Solution to handle Functional Acknowledgements ticks a lot of boxes. There are certain nuances that could be handled better on the Standard Integration Flows ( eg: The B2B Message is deleted from the Datastore even if the status is not a allowed code list value, the need for a dummy AS2 sender channel and so on ) but apart from these minor aberrations which would be addressed if you raise a Customer Ticket ( and then run in circles?! you know if you know) most of the pieces are in place.
Of course as mentioned in the Introduction, you are at the mercy of your Trading Partner to generate the FAs and there is a lack of automated alerting for messages that have not been acknowledged ( within agreed times). This needs custom automations but an out of the box Alerting is on the roadmap Q2 2024 and unclear on what parts will of the automation will be addressed by SAP and what not. The lack of monitoring is something for which you can built automated solutions externally and get rid of them once SAP releases a standard Solution which to me is not a impediment.
The Lack of support to send FAs back to your ERP system(s). The Lack of Support to get the Original IDoc number back to be mapped into a SYSTAT IDoc ( well there are some options but nothing out of the box) makes this a huge stumbling block. If you are a SAP PI/ PO Customer or a Customer who is used to using ERP and SYSTATs to process FA’s this glaring omission can likely be an impediment to adopting the standard TPM approach from SAP. The challenge of building workarounds for this is that you would then be “stuck” with a non-standard Solution and SAP “reviews” will always point this out. We will explore other alternates to this in later posts! And if you are starting your TPM journey atleast you are warned!
While we have looked at EDIFACT FAs in these posts of mine, the process for ANSI X12 FAs would remain the same. Minor irritants aside, the fact that SAP’s common Integration Flows in the package Cloud Integration – Trading Partner Management V2 can handle so much processing is commendable.
Additional Blogs from this Series
- Trading Partner Management – Part 1 – IDoc to EDI Flow(s)
- Trading Partner Management – Part 2 – EDI to IDoc Flows(s)
- Trading Partner Management – Part 3 – EDI over AS2 to IDoc Flows(s)
- Trading Partner Management – Part 4 – IDoc to EDI over AS2 Flow(s)
- Trading Partner Management – Part 5 – Custom IDoc Flow
- Trading Partner Management – Part 6 – Custom Search Attributes
- Trading Partner Management – Part 7 – EDI Functional Acknowledgements for Inbound EDI Messages
- Trading Partner Management – Part 8 – EDI Functional Acknowledgements for Outbound EDI Messages
- Trading Partner Management – Part 9 – Outgoing IDoc Bundling
- Trading Partner Management – Part 10 – Outgoing IDoc Bundling With EDI Bundling
- Trading Partner Management – Part 11 – Handling Parameters
- B2B on SAP Integration Suite – Part 12 – Migrating SAP PI / PO B2B Mappings without TPM
- Trading Partner Management – Part 13 – Migrating SAP PI / PO B2B Mappings with TPM
- Trading Partner Management – Part 14 – Handling Bundled Incoming EDIs
- Trading Partner Management – Part 15 – Handling Message Retries
- Trading Partner Management – Part 16 – B2B Failed Message Alerting
- Trading Partner Management – Part 17 – TPM Naming Convention Guideline