Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

File sender / receiver - writing competitors

We are using a File Sender and File receiver adapters to exchange files between systems and I'd like to know if some of you know what would occur in case a large file is taking some seconds or minutes to be created by PI (File Receiver) in a target folder and another application tries to get this file to process it (before PI has finished the file creation in the folder).

Also, the opposite way, what would happen in case the legacy application is generating a file in a FTP folder at same same that PI start reading such directory (before the legacy has finished the file creation).

Is that something that PI is already prepared for? How to manage such situations?



Check SAP Note 821267.

From SAP Note for Sender Adapter


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


For receive adapter you can use option Use Temporary File and avoid this situation.


1 View this answer in context
Not what you were looking for? View more on this topic or Ask a question