cancel
Showing results for 
Search instead for 
Did you mean: 

Communication Channel Archiving

Former Member
0 Kudos

Hi Gurus,

I need help in determining a problem in the archiving process of communication channels. The messages does not return any errors and I am uncertain where to investigate further to find the cause of the problem. Here is my issue:

Everyday there is a batch job in SM37 (report RFKKCOL2) that executes in ISU system and this will produce 3 image files which is thrown to PI for message processing (so that we will have a confirmation that is is processed, more like of a copy) and FTP it to a box. This is currently happening but the Image file is NOT being created completely. I am not exactly sure if the image files are experiencing the errors on the message processing since that messages in PI is not throwing errors, or the problem is in the archiving process. After the communication channel picks up the file, it is set to archive it to the same box.

Since last week, in the image target folder in OS, there are 6,082 individually images equalling to 269 MB or 282,959,479 B; and in the directory of the image archive there is a file called Image<date>.001 which compresses all the 269MB worth of pictures for that day into 1 file and it is expected that it should be the same size but it is actually only 567 KB or 581,129 B, there is a big short fall here. Where is the problem coming from? This just has happened suddenly without any system changes or any programs changes. This issue has been happening for several days consecutively now.

Please advise.

Thank you in advance

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Madelynne,

Seems like the PI adapter is picking the file while its been written. Please try:

1) Increase the polling interval

2) In Advanced options -> Msecs to Wait Before Modification Check - 500

With this option enabled the adapter will read the file and wait for 500 msec and check if the file size has changed. If yes, it will drop the read content and read the latest content. This cycle will continue until the file size doesn't change.

Cheers!

Anish

Answers (2)

Answers (2)

Former Member
0 Kudos

Hello Madelynne,

As suggested by Anish "Msecs to Wait Before Modification Check "will work for the FTP adapter ........

Or

You can request your FTP team to write a temporary file and after finishing of writing file, they need to rename the temp file to exact file what you are looking to poll..........

Regards

Harsha Paruchuri

former_member278111
Participant
0 Kudos

Hi,

I am also facing the same issue with file adapter of type FTP at the sender side. ex if source file is of size 10 kb after archive the file size increase to 70 kb! can any one have faced this error earlier? Please share some suggestions.

Regards

Kumar

Former Member
0 Kudos

Hi Madelynne,

Seems like the PI adapter is picking the file while its been written. Please try:

1) Increase the polling interval

2) In Advanced options -> Msecs to Wait Before Modification Check - 500

With this option enabled the adapter will read the file and wait for 500 msec and check if the file size has changed. If yes, it will drop the read content and read the latest content. This cycle will continue until the file size doesn't change.

Cheers!

Anish

Former Member
0 Kudos

Thank you Anish, will try this and let you know the soonest if it is successful.

However, this had happened suddenly, and we need to know what triggered PI to react this way so that we can avoid it in the future, any ideas?

Former Member
0 Kudos

Hi Madelynne,

If the issue is because PI picks file when it is being written, then it is just about the timing. PI polling time and file creation time got in sync.

For example, if the file is being written at 12:05 and the adapter also polls at the same time, this issue happens.

The changes I suggested should take care of this issue.

Cheers!

Anish

Former Member
0 Kudos

I apologize, but I got confused. The idea is that when a file was picked up, it will be archived afterwards. Do you mean that this happens if during the archiving process, a file was being picked up again which causes the image ftp process to break?

I am quite confused with the processing parameters Polling interval (secs)* and Polling interval (msecs). What is the difference between the two? And why is it that the Polling interval (secs)* is required while Polling interval (msecs) is not? As from SAP Help, these two parameters have the same definition: "Number of seconds that the adapter is to wait if no files are found for processing.". The other one just replaced the seconds to milliseconds - Number of milliseconds that the adapter is to wait if no files are found for processing.

Thank you again in advance!

Former Member
0 Kudos

Hi Marie,

There is a slight difference between Polling interval (secs) and Polling interval (msecs). Polling Interval is the time your adapter keeps looking for the file.

Polling interval (msecs) is time to wait before the file picks up. As an example if the file is getting picked up by file adapter and you have 100 records in the file send to you by legacy system in the source folder, and right now it has only 30 records and the source application is still writing this file then if you dont give this parameter, the file adapter picks up 30 records. So your integraion is not completely done. So if you specify this parameter for 100ms then before the file adapter picks it will see the size of the file and after 100ms it will once again see the size. If there is difference then it will once again see after 100ms. So till it has the same size it will not pick up. This is very important setting for file adapter.

Regards,

---Satish