Interface file tracking – PO to S4H
I am writing this blog to explain very simple, efficient and yet very effective way to track third party source files in all the involved SAP systems for end to end tracking of files/messages.
In most of the Integration projects, we get the requirement to post multiple IDOCs in SAP system from single source file. This looks very simple requirement and we implement it in many ways however the challenge stars when we design end to end file monitoring systems in order to track third interface files.
Why do we need to track third party file details? Imagine a scenario where where we are receiving more than 200 files in a day from third party systems and each file is posting multiple Idocs (most of the of same type) in SAP system via SAP PI/PO also imagine you have to enhance interface functionality in SAP for certain interfaces before posting it ..
Wouldn’t be it good to have tracking mechanism in SAP back end system to track all idoc posted by system A or for any particular interface file or for any interface so that in case of any source file error we can provide file details to third party as well, also you would be be able to differentiate each interface in SAP before implementing any enhancement via exits/badi/enhancement points.
In my recent project, we were integrating with more than 50 third party systems and we have more than 150+ interfaces in landscape, being finance dominated project we were using ACC_DOCUMENT03 idoc for posting most of the finance data in SAP S4H 1511 using SAP PO 7.5 and we implemented tracking mechanism via IDOC control record ARCKEY field.
Idea was very simple to map third party file name in IDOC-Control Record- ARCKEY field in SAP PO for all inbound interfaces so that when idoc get posted in SAP S4H you can track third party file names in WE02 by putting file names.
WE02 allows us to search IDOCS based on ARCKEY hence it is much easier for any technical user to go and look for IDOC for any particular interface, also IDOC control record field value is available in most of the exit to differentiate which interface is getting processed and we implemented many interface specific code using Interface id.
Search for all IDOC posted for particular Interface
Run t-code WE02 and go to tab “EDI”. Enter the interface ID number or complete file name as shown below and press F8.
Note: To view the IDOCs of specific filename enter the complete filename in EDI Archive Key.
All the IDOCs for the interface file will be displayed as below.
We can see all Idocs posted for Interface I704 above also in same way we can put exact file name or third party name to track all IDocs posted.
Please note we can achive this functionality in other ways as well example by creating multiple partner types for each third party systems, etc however we chosen above option by considering less configuration effort and keeping standard solution.
Hi Kunaal, Great Info here !!
I believe this the best way to track the IDocs/files in ECC ,especially above scenario which you explained.
Thanks for sharing !
This blog is very interesting: We have tried the same approach last year (PO 7.31), but failed to preserve the file name because we found that ARCKEY is overwritten by the IDoc receiver adapter with the message Id. This behaviour corresponds to SAP documentation.
After upgrading to 7.5 we were a bit surprised to find that now the IDoc receiver adapter uses the message Id concatenated with the Interchange Control Number to overwrite ARCKEY. At least in some cases, in others it still uses only the message Id. Did not dive deep enough to find out some rule here but will have to do so in the next days.
sorry for late reply, Yes Idoc receiver adapter does overwrites ARCKEY value. We have implemented small exit in S4H(global exit for all idocs) which is interchanging value of SNDLAD with ARCKEY, Please also note we have passed source file name in both SNDLAD and ARCKEY fields. Value of SNDLAD/RCVLAD will not be overwritten by IDOC receiver adapter.
thank you, very good idea.
I was just going to write the same but the exit explains it of course. Also, losing the GUID in a searchable IDoc header field seems like a hefty trade-off to me but I guess it all depends on your individual traceability requirements.
We have kept GUID in SNDLAD field in exit, so in exit we have swap values of ARCKEY and SNDLAD.
Yes, I understand and I was not criticizing 🙂
My point was that losing GUID search in WE02/WE05 would be a concern for customers I have worked with before. Of course there will be many scenarios where having direct access to the file name is more beneficial. Also you can of course still search the GUID directly on table EDIDC if you have access or retrieve it from the file names in the archive directory if you have configured your file channel to archive and write the GUID to the archive file name.
Thanks for taking the time to document this and sharing it with us.