Comm Channel picks up a file before it is complete causing an alert to be sent

[Former Member]

We are using PI 7.4 and Sol Man 7.1 SP14

We have a number of scenario where PI is polling for a file the problem is it picks it up before it is complete.

We have looked at renaming the fiIe when it is complete and have PI poll for the renamed name. This works in some of our scenarios but not all.  One such scenario is a standard FSCD payment mass activity job.  To rename the file I would have to modify the standard program.  I'm wondering if there is another way to resolve my issue.

We have tried the 'Msecs to Wait before Modification Check' parm

1. Polling interval hits,
2. PI sees the file,
3. PI gets the size,
4. PI waits for the time set in the 'Msecs to Wait before Modification Check' (500),
5. PI see that the size has changed, raises and error and schedules a retry based on the 'Retry Interval' parm,
6. retry time is met and PI starts at (3)
7. if the file size has not changed the file is processed

     Normally the file is complete when the first retry attempt has completed.  This fixes the incomplete file issue for the most part.

The problem is the error raised in PI sends an alert to Sol Man which sends a 'page' notification to a phone that is monitored 24/7.  By the time the person oncall receives the page and gets online the scenario has long since completed successfully.

Is there a way in PI to check to see if the file has been closed prior to picking up the file?

Normal program:

file is opened

loop

     some processing is done

     record written to file

end loop

close file

Is there a way to stop these nuisance page notifications?

[former_member223322]

Jerry,

The steps that your PI is doing based on the 'Msecs to Wait before Modification Check' parmeter is perfectly fine and that is what it is suppose to do.

Here you can think about other options to avoid that alert messages.

- Scheduling the PI channel such a way that it starts the trigger only after the file is created. For example, if you know that the file will be created around 1PM everyday, then you can schedule the channel at 2PM as a safe bet.

- Otherwise you can make the channel to be controlled EXTERNAL and can be triggered thru an ABAP program. This program can be scheduled as a 2nd step after the job (program) that creates the file in the folder.

~Srini

[former_member182412]

Hi Jerry,

It is a limitation in operating system for file locking, check below sap note

821267 - FAQ: XI 3.0 / PI 7.0 / PI 7.1 / PI 7.3 File Adapter

3. File Locking / Incomplete Processing

Q: I sometimes observe that files are processed only partially, i.e., only a fragment from the file's start is converted into an XI message. Nevertheless, the file is usually archived completely. Does the File Sender Adapter honor if another process has locked a file for exclusive use?
A: Unfortunately, the J2EE 1.3 technology the File Adapter is built upon does not support file locking. This limitation affects the File Adapter's operation. Depending on whether the JRE implementation for the operating system under which the adapter runs uses mandatory file locking or advisory file locking, opening a file that is currently being written to by another process will fail or not.

If opening the file fails, no problem exists and the adapter will try to open the file each poll interval until it succeeds.

However, if opening the file is not prevented by the operating system, the adapter starts to process the file although it is still being modified. Since XI 3.0 SP11 / PI 7.0 there is a parameter named "Msecs to Wait Before Modification Check" in the advanced settings of the File Sender channel configuration to work around this issue. This setting causes the File Adapter to wait a certain time after reading, but before sending a file to the Adapter Engine. If the file has been modified (which is basically determined by comparing the size of the read data with the current file size of the input file) after the configured interval has elapsed, the adapter aborts the processing of the file and tries to process the file again after the retry interval has elapsed.

If this option is not available for the settings you would like to use, the following algorithm (to be implemented in your application) may be used to ensure that the File Adapter only processes completely written files:

Create the file using an extension, which does not get processed by the File Adapter, e.g., ".tmp"
Write the file content
Rename the file to its final name, so the File Adapter will notice its existence and pick it up

You need to use work around mentioned above.

• Create the file using an extension, which does not get processed by the File Adapter, e.g., ".tmp"
• Write the file content
• Rename the file to its final name, so the File Adapter will notice its existence and pick it up

Regards,

Praveen.