IDoc-to-File: Status=processed succesfully but file is not always delivered

[Former Member]

Hi Experts,

I have a problem with a IDoc-to-File scenario. I generate an IDoc and send it to the XI-System. Afterwards a XML-file is created which should be transmitted to a filesystem or to a ftp server (I tested with both). In the SXMB_MONI the Message has the Status "Processed Succesfully" and the Acknowledgement-Status "Still awaiting acknowledgement". The problem is that not all files arrive the destination succesfully. sometimes they arrive and sometimes not. and always the same status in the sxmb_moni.

if a message not arrived the destination, in the message monitoring in the runtime workbench there is the status "To Be Delivered". If one Message has the status "To Be Delivered" the following messages get this status too.

the communication-channel-monitoring says that "the communication channel is correctly configured and started"

Can you help me? I don't know where the problem is. could it be that the adapter-engine has some problems?

Thanks and best regards

Christopher

[abhijitbolakhe]

just give this a try...

For the Acknowledgement-Status "Still awaiting acknowledgement..

...For IDocs, acknowledgments are requested by default.

To prevent requests for acknowledgments or to handle acknowledgments.. run report IDX_NOALE

This allows a sender system to request or deny acknowledgements for all message types centrally. You can set exceptions to this central setting by message type.

Hope this may help

--- Abhijit

[Former Member]

in the message monitoring in the runtime workbench there is the status "To Be Delivered

-->

Select your message from message monitoring and click Details, a pop up will come with actual error. Message might be stuck in adapter engine.

In receiver adapter select construction mode to be Add Time stamp so as to ensure that no of times you execute the interface, file is getting produced

[Former Member]

hi,

I clicked on details in the message monitoring but the fields "error category" and "error code" are empty. Then I checked the audit log in the message monitoring. there are the following three entries

2008-01-28 14:08:56 Success Message successfully received by messaging system.

2008-01-28 14:08:56 Success Using connection File_http://sap.com/xi/XI/System. Trying to put the message into the receive queue.

2008-01-28 14:08:57 Success Message successfully put into the queue.

and here the audit log of a message which could be transmitted correctly:

2008-01-28 10:33:10 Success Message successfully received by messaging system.

2008-01-28 10:33:10 Success Using connection File_http://sap.com/xi/XI/System. Trying to put the message into the receive queue.

2008-01-28 10:33:10 Success Message successfully put into the queue.

2008-01-28 10:33:10 Success The message was successfully retrieved from the receive queue.

2008-01-28 10:33:10 Success The message status set to DLNG.

2008-01-28 10:33:10 Success Delivering to channel: FILEPORT_TO_PICC

2008-01-28 10:33:10 Success MP: entering

2008-01-28 10:33:10 Success MP: processing local module localejbs/CallSapAdapter

2008-01-28 10:33:10 Success File adapter receiver: processing started; QoS required: ExactlyOnce

2008-01-28 10:33:10 Success File adapter receiver channel FILEPORT_TO_PICC: start processing: party " ", service "X22_PICC"

2008-01-28 10:33:10 Success Write to file "/tmp/xi/PICC/INV_5075_4000102108_20070109_103310.XML" as binary, size 410 bytes

2008-01-28 10:33:10 Success File processing complete

2008-01-28 10:33:10 Success MP: leaving

2008-01-28 10:33:10 Success The message was successfully delivered to the application using connection File_http://sap.com/xi/XI/System.

2008-01-28 10:33:10 Success The message status set to DLVD.

2008-01-28 10:33:10 Success Acknowledgement creation triggered for type: AckNotSupported

2008-01-28 10:33:10 Success Acknowledgement sent successfully for type: AckNotSupported

can you say me where the problem is?

thanks and regards

chris

[Former Member]

Hi Christopher Kühn,

This Acknowledgement status still waiting, comes when the adapter engine overloaded.

Either

You need to refresh the queue and again have to process the same IDOC either manually via WE19.

OR

Just edit the IDOC receiver communication channel and save and activate it again.

This solution will also work for a while and after that the idocs will again get stuck up.

There is some problem that the queue get it on hold. In SMQR you need to register the queue and observe the details for it.

The usage of server is also one of the important factor for this.

This kind of problem will not be raised in Quality or Production. Even if you have observe this is not the permanent issue as if today its creating the problem may be tomorrow it will work properly. It depends on the memory utilization and paging. Restarting the java stack will be good solution for this.

Thanks

Swarup

[Former Member]

2008-01-28 10:33:10 Success Write to file "/tmp/xi/PICC/INV_5075_4000102108_20070109_103310.XML" as binary, size 410 bytes

-->

Please confirm if messages are in To Be Delivered state even if you use FTP instead of NFS

[Former Member]

hi Swarup,

how can i refresh the queue?

to edit and save the file receiver comm channel is not helpful. I still tried it

thanks and regards

Christopher

[Former Member]

Hi Mugdha Kulkarni,

yes if I try to send the files via ftp it is the same problem.

thanks and regards

Christopher

[Former Member]

Hi,

Goto > RWB>communication channel --> Open communication channel for file receiver and then you will get Refresh, Start & Stop button.

stop the communication channel and the start and refresh it.

Thanks

Swarup

[Former Member]

Ok I have restartet and refreshed the file receiver comm channel. but it is the same problem like before. the status of the channel is green with no errors, but the files don't arrive at the destination folder.

this morning I have restarted the XI-System. Then the scenario works again. but only for two or three file-transferes. I configured the scenario a half year ago and up to know it was working always. and I didn't change the senario. this situation is unexplainable for me ...

After restarting the XI-System the scenario works for stroring the XML-Files on a local filesystem. If I switch the comm channel to a FTP server the scenario works for the first file -> only the first file arrives at the FTP server. the status is "processed succesfully" and the ack-status is "still awaiting acknowledgement". in the runtime workbench there is a system error under adapter engine in the message monitoring. if I try to send the file a second and a third time it doesn't work. the files don't arrive at the FTP Server. in the RWB they have the status "To Be Delivered" ...

Can somebody help me??? Couldit be that the adapter engine in overloaded? and if, how can I check this?

thanks

chris

Edited by: Christopher Kühn on Jan 29, 2008 10:12 AM

[Former Member]

Hi Chris,

How did you solved this issue.

Regards,

JAM

[Former Member]

Hi Christopher,

a) it could be that all the IDOCs are in one queue. The queue is process sequetially. So If one IDOC can't be delivered the other IDOC habve to wait.

b) It could be also that you send the IDOC in EOIO; means: excatly once in order. So the XI guarantees that the IDOCs will be send to the receiver in the same order as they arrived in XI

Regards Mario

Edited by: Mario Müller on Jan 28, 2008 8:19 AM

[Former Member]

hi mario,

I looked it up in the sxmb_moni. there are three queues (XBTOI___0000, XBTOI___0001, XBTOI___0002).

and the QOS is EO (exactly once)

best regards

chris

[former_member225472]

Hmm i work with the File Adapter in both ways (inbound and Outbound) and i dont have that behavior.

Did you try a Java Pool Refresh?

Did you try to Stop and Re-Start the comm channel?

It can also be a network Traffic issue, or an overload to the XI system...

Thats wat comes to mi mind with the given details.

Hope it helps.

EDIT:

If in the Workbench you see the status "To Be Delivered", means to me that is something wrong with the Destination folder... you shall get in touch with the local OS guys and network team as previously stated...

What i can suggest to you is to make a local test in your own Computer... (is what i do).

Download the FileZila FTP server (or any other FTP Sever) and install it in you computer...

Setup a user and a path, and change the details in your Receiver Com Channel..

Then, try to make a Stress Test and see if the error persists...

If it persists, that means that you have a issue with the XI box...

Other wise, you have to look outside the XI bounds...

Now i really hope it helps.

Edited by: kerubon on Jan 28, 2008 8:06 AM

[Former Member]

hi kerubon,

yes I restarted the comm channel. but it didn't helped. also the xi system is not overloadad.

to the destination folder: i have always the same destination folder. sometimes the files arrive and sometimes not. thats crazy, but so the destination folder cannot be the problem i think.

thanks and regards

Chris