OK…Here was my challenge. We have 4 XI interfaces that will receive master data from SAP Business System individually. So no matter however we choose to schedule the Job in SAP SCM, these files will be created one-by-one via XI in a share as Text files. XI does not have any control over the creation of these Jobs in the Share without the use of BPM solution in this scenario. Also there is no correlation between these interfaces. At the end of the day, XI needs to combine all of these 4 files into one Master File before sending this to a vendor. The requirement reads that “either all or nothing” should go to the vendor. This means that if one of these programs that create the data fails in the SAP SCM, then these files should not be sent to the Vendor. Challenge is that XI should check if all the 4 files have been generated before combining them into one file and sending it out to the vendor. This is a weekly run and so on top of the requirement, it is good to check the timestamp of all of the files that have been generated individually from the SAP XI before combinig these files and sending it out to the vendor.
Approach 1: I know, this could be easily done via UNIX Script to check the files and combine them into one file. But the downside here is that, if the UNIX script fails for some reason, then the middleware does not have any control over the failure which undermines the usage of a middleware in an organization. Also this will add to one more step in the middle and cannot be monitored easily.
Approach 2: A BPM solution could be used (BPMCollectPattern) to combine all of these data from the interfaces which could wait until the message is received from all of the interfaces and then combine via Mapping all of these interfaces into One interface and send it to the client. The BPM could be set up in a way to timeout after n minutes so that if one file had failed, then nothing will be sent as a result and the waiting thread would be automatically killed from the memory after n minutes. The downside of BPM is that the sender adapter for BPM is also a file adapter and on unsuccessful processing, the file adapter is NOT going to change the MODE of the file (delete, archive etc). The file is still going to sit in the same folder to be pulled in the next time. Also there is NO CORRELATION between these interfaces though I can build the artificial correlation, it is a round about way.
Approach 3: I can have the Sender adapter use the NFS rather than FTP. By this way, I can utilize the advantage of checking on the files and to generate the files at the receiver only when all of the files mentioned in the “Additional Files” section is present. The downside of this approach is that again the sender adapter cannot change the MODE of the file if the file is not picked up and sent (when one file is not present). Also the biggest trouble is that when the files are picked up and sent, the additional files are passed as an attachment to the payload. Presently (SAP PI 7.0) there is no way for the receiver file adapter to receive this payload. Also I was looking for the API to manipulate these payload attachment and there is none. Remember, attachments are always treated as “sent without any manipulation or file content conversions” in XI and may be that is why I do not see a method presently in any of the API’s that is available in the mapping. So I cannot write a java mapping to combine these payloads. It seems that PI 7.1 has the following API’s and I could use the getAttachment() method to get these payloads and combine them in my Mapping program.
Approach 4: We could write a simple Java Mapping class to check and see if the 4 files are present in the folder. Then the timestamp of the files individually or at the folder level could be checked to make sure that these files have been generated during the acceptable window period (As this is scheduled weekly, I am going to check for the past 3 days). This way, my process will be intact and fail proof meaning, I would not be sending the previously generated files by mistake. The Pseudo code for this Java Mapping goes like this.
Conclusion :
The above Problem scenario was explained to argue that it is Inevitable at times, to avoid JAVA MAPPING and accomplish using the standard MESSAGE MAPPING and CONFIGURATION Parameters.
