Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member184681
Active Contributor

Very similar question was asked several times in the SDN Forum by different users over the past few weeks, and in my opinion it was never answered in a satisfying manner. The scenario was: I have an interface that should run once a day, and should collect a file and process it somehow (I will call it the "original" or "main" interface in this blog). And if there is no file, an administrator expects to receive an e-mail message notification. I have been thinking a little bit last days about how to meet this requirement satisfactorily, and now after some time I have a solution to share with you. I believe some of you will find it useful one day.

First of all, it would be difficult to create such scenario with PI standard functionality. PI’s sender adapter has an option to process empty files, but it cannot start the processing when there is no file at all. I was also thinking to use the Operating System Command Before Message Processing, but there is the same problem again: it is only executed before message processing, not before/after polling, so it is not executed when there is no message. And I would really hate the idea of writing my own adapter or adapter module to match such a simple requirement.

After all, I have found some alternative. The point is to create a separate "administrative" scenario to keep the main scenario under control. It will be a file to mail integration, with a separate source file, running each day right after midnight (just before the original interface), to check if a file for the main scenario exists. You should additionally make sure that this administrative scenario runs before the main interface, by means of scheduling the time window when the sender file communication channel is active. And make sure to run this administrative interface only once a day.

In the ESR, you will only need a trivial configuration. A simple structure with just one field is required in the sender interface, and an equally simple one for the mail receiver part. I don’t want to focus on that part, as it is really standard development. If you require further help, please refer to this SDN Article that describes a simple File to Mail scenario step by step: http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/a0a27c01-26b0-2c10-bd8a-94498efa7ff6

I would rather focus on the Integration Directory configuration, as this is really the interesting part of the whole thing. The first important place is the sender file communication channel. In my demo scenario, I used the NFS as Transport Protocol, a specified Source Directory and File Name. It is also important to use the "Test" Processing Mode, so that the same file was processed over and over, each day. But the point is to use the Operating System Command Before Message Processing:

The goal of the OS command before processing is to check, if the main interface’s file (namely: mainfile.txt) exists. If yes, then "OK" is written into the file (replacing its previous content), and if not, then "NO FILE" is written. And here is the thing: it is written before message processing, even before the file is read by the interface. So the interface will later read either "OK" or "NO FILE" in the message content.

Now, you only need two more things. The first one is the File Content Conversion that will read the "OK" or "NO FILE" value from the file, into the message payload. I used the following settings, but remember that your configuration has to stay in line with your sender Service Interface:

The final important part of the scenario is the receiver determination, that should contain a condition to check if the value read from the file is "NO FILE":

If the value is different, so the original interface file has been found, then the message should be ignored and no e-mail notification should be sent. Now it looks to me that we have all the requirements covered.

To sum up: someone might say that creating an additional scenario just for administration purposes is not a good idea, that it generates additional costs, and so on. But the truth is, with use of the SDN Article step-by-step guide that I linked above, and the description from this blog, you will be able to develop this scenario in just a few hours, just like I did. This isn’t much, I guess. Much less then writing your own adapter or adapter module, to meet the initial requirement with a single scenario.

4 Comments
Labels in this area