Missing ALEAUD idocs

[Former Member]

Dear Experts,

For one of our existing interfaces for Delivery Idocs from R3>PI>third party; we have an issue with the ALEAUD messages. This configuration is in place since a long time. Some of the Delivery Idocs are in status 12 in R3 system and they do not have the corresponding ALEAUD Idocs- hence the staus remains 12 and does not get changed to 39. The third party application has been receiving these delivery Idocs; hence I am not sure why we do not have ALEAUD messages getting created for these. I have checked the below:

In R3 WE09 I have searched ALEAUD messages for the Idocs in status 12 with filter: Segment:E1STATE and Field DOCNUM and heValue <Original Delivery Idoc Number>. For the 39 status idocs I do find ALEAUD Idocs corresponding to th original delivery Idoc. But for the Idocs in status 12; as suspected; I do not find ALEAUD messages.

In PI SXI_Monitor; I do not know how to corelate/find the ALEAUD message for a specific Delivery Idoc message. But I checked with approximate timestamp randomly and could not find the ALEAUD message for my delivery. Is there any other way to find if an ALEAUD message is created for an Original message?Checked in Trace and reliable messaging in SOAP header, response header; but no luck. For 1 hr I could find 2000 messages and going through each of them individually is not an option. I do not have time/aprovals to implement content based search on my production box within a short duration to apply any filter to find these messages.

Can you please help and tell me

1. How can I find/correlate ALEAUD messages for an original message in PI?

2. What could be the reason that ALEAUD messages are not getting generated; only for some messages; eventhough the same has been received at the Destination?

[former_member194011]

Hi SMXI,

We are also facing the same issue....and we are clueless can you please suggest us the solution for the same....if you have any....!!!

Dear Sdners, can you please suggest me the possible solutions for this kinda issue.....!!!

[Former Member]

My issue was solved.

After further analysis it was found that the ALEAUD messages are created from the response messages sent by the receiving 3rd part system. Eventhough the 3rd party system was receiving all our outgoing messages; they failed to process the acknowledgement or confirmation for some of the messages. Inturn we received no confirmation responses from the third party and hence the ALEAUD messages were not created for the same. After finding this, the same was informed to the thrid party system and they are fixing the message confirmation/acknowldgement processing from their side. So the issue was closed.

I had also raised an OSS message for this where the analyst had asked me to check the below.. Please go through the same for your issue. Maybe it will help you...

"I looked at the example IDoc messages and i found no request message
created by the external system. Please give us the message id that
for the request message id that should create and ALEAUD-IDoc
for IDoc xxxxxx. If this is missing in the system please contact
the administrator of the external system why this request messages
was not created.
I found 126890 messages in the system with system error, possible
one of these messages contain the information for your idocs.
transaction SM58 i found many errors with function module
IDOC_INBOUND_ASYNCHRONOUS, this function module transports IDocs
and these IDocs are possible missing in the receiving system ?
Please check the errors and try to correct them."

Thank you

[former_member194011]

Hi All,

Our case there is no confirmation back from 3rd party. Let me explain our interface. IDOC to file. Based on input idoc from CRM the messages getting split-ted and it's delivered to 3rd party.

We are maintained the partner profile(0079XI44) for inbound ALEAUD Maintained. And also we have archive messages relate to Communication channel also. For this Archive we maintain inbound ALEAUD with separate partner(0079XI44A).

With same partner other message types are there and working without any issue.(But there is no message split)

Why this only message type having issue to update ALEAUD? Any one help on this.

Regards

Kiran

[Former Member]

Hi SMXI,

If I understand correctly the R3 sends an Idoc to to PI. In PI the Idoc gets transferred to 3rd party. At same time PI sends back the ALEAUD idoc to R3. (so the ALEAUD is not triggered in the 3rd party?) If the ALEAUD is triggered from third party ask them to investigate also. If ALEAUD isnt triggerd form 3 rd party there is some reason why PI produces ALEAUD in some cases and it does not produce the ALEAUD in other cases.

I dont think the correlation you ar looking for exists. And it looks as if you are searching for something that isnt there anyway.

One thing you could do is take one Idoc that fails to produce an ALEAUD and reproduce it on DEVELOPMENT system and then see what happens if you send it from R3 to PI. It really should produce the same results and maybe it is easier to trace it there.

You can set trace level for SXMB_MONI real high and see if you can find any error.

Also take a close look at the PI objects that are involved? Is there maybe some mapping involved that gets the wrong input from the delivery idoc? maybe a new plant was introduced in R3 and it isnt included in a mapping lookup or something like this?

Hope these are soem pointers to get you on the way

Happy hunting.

kr

Robert

[Former Member]

Thanks Robert.

From what I understand, ALEAUD are acknowledgments created in PI itself, once PI succesfully delivers a message to the third party system. So it is not the 3rd party system creating an acknowledgment. Please correct me if I am wrong, experts.

My issue is that, eventhough the original message is succesfully delivered to the 3rd party system; ALEAUD messages are either not created or not posted back in the R/3 system. There is no pattern in which this issue happens- it happens to randomDelivery idocs for a specific third party. Experts, please let me know ways to troubleshoot this.

Thank you

Regards.

SMXI

[Former Member]

Dear Experts,

Request your help in this regard...

Regards,

SMXI

[Former Member]

hi,

i think ALEAUD acknowldegement for only applicable for IDOC to IDOC scenarios.....because in receiver R3 system you have specify in partner profile ALEAUD as message type and basic idoc type is ALEAUD01 and u need to create port using T-code WE21 its pointing to PI system, then we have create Distribution model Using T-code BD64 there u will specify SENDER R3 and RECEIVER R3 and message type . then we Scedule JOB using SM36 AND we release job using T-code SM37....then we got we got ack in PI sxmb_moni ack message there u find two parameters ACK and OK. then coming Sender R3 system in partner profile in bound parameters u have to specify process code AUD01... while u trigger IDOC from Sender System IT will successfuly postted to R3 receiver we got ack in Sender R3 system.. IDOC status code is 44(ACK).

regards,

ganesh.