on 04-11-2012 9:21 AM
Hi Experts,
Scenario- File to File having a RFC lookup(This RFC for only adding the additional data from ECC)
Interface is running from last one year from last few months we are facing an issue with Out Put file is partially generating(we are trying to processing the around 50000 records some times we are not getting the half of the Records) .This is happening only monthly once or twice except this interface is working fine.
Monitoring- we are not finding any trace in File CC monitoring and RFC CC monitoring all are showing successful messages
Thanks
Praveen Kumar
Hi Praveen,
Please check the parameters defined in File Communication channel for example Poll Interval secs/Msecs to Wait Before Modification Check,
(if Data is more in file then Poll Interval should be maximum,also "Msecs to Wait Before Modification Check" should also be Maximum)
or else you can do one thing test same payload in Interface Determination or in mapping in Development enviornment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Regarding the partial file generation:-
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
Thanks,
Atul
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Praveen
As you mentioned you are processing around 50000 records at a time. How many RFC calls are made for this?
if they are 50000 then you should optimize it to a single call per file.
Secondly in your sender and receiver adapters Enable ASMA with option of "Temporary Name Scheme for Target File name"
The put file option in processing should be Use Temporary File
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Just to verify - are you sure that PI does not write the file completely? Or maybe your receiver system starts reading the file in the meantime, before it is written completely by PI? In the latter case, use Write Mode = Use Temporary Filename option of the receiver file communication channel (see more here: http://help.sap.com/saphelp_nwpi71/helpdata/en/44/682bcd7f2a6d12e10000000a1553f6/frameset.htm). Thanks to this, you will first create the file under some temporary name and your file will not be read by the receiver system, until it is completely created by PI and the file name is changed to the final one.
Hope this helps,
Greg
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
pls ask basis team to check for the specified times in ECC system to see if there is specific load on the ECC system during those time durations. also ask abap team to optimize the performance of the RFC in ECC system by taking data of large msgs containing 50,000 rec as input data.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gupta,
Thanks For your inputs
Our Basis Team is done with all possible Checks but no clue. Daily it is running successfully with the same load It is only failing once in a month.
@Grzegorz: We are sure PI does not write the file completely. Receiver system is working fine. It is only happening once in a month.
Thanks,
Praveen
And how about the sender channel? Does it read the file completely, too? When you check the sxi_monitor for the incomplete file, does it contain the complete or truncated file data? Maybe it is PI that reads the file before it is completely created by the sender system? In this case you can use "Msecs to Wait Before Modification Check" to make sure PI only reads the file when it is complete.
I believe you should check these kind of options several times, before you assume that PI randomly loses some data during processing.
Regards,
Greg
User | Count |
---|---|
88 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.