Outbound IDoc interface - Status control

[RafaelVieira]

Hi,

I'm analyzing a requirement where I have to interface ECC with an external partner which reads information from an FTP.

Scenario would be ECC(IDoc)->PI 7.31 AEX->FTP.

As soon as the IDoc is triggered and successfully delivered to PI, I believe ECC manages its status and puts it into 03 (Data passed to port OK). In our scenario, it means that the file was posted into the FTP.

Once the partner picks up the XML file from FTP, the IDoc must be updated to status 06 (Translation OK) and, once it deliveries to final destination (another application), IDoc status must be updated in ECC to 12 (Dispatch OK).

So, my question is how to deal with this status management with PI, acknowledging to ECC the status 06 and 12 (or, eventually a 05 or 17 for error statuses) which are provided by the external partner?

Thanks!

[nabendu_sen]

Hi Rafael,

If I understand your requirement correctly, as soon as PI File Adapter hands over the file to the FTP location, it won't have any control to take back any acknowledgment / response to its Sender. The interface flow completes at that point.

Also File adapter does not support Application Acknowledgement, only support Transport Acknowledgments.

Once the partner picks up the XML file from FTP, the IDoc must be updated to status 06 (Translation OK) and, once it deliveries to final destination (another application), IDoc status must be updated in ECC to 12 (Dispatch OK).

The above is Not possible as per my knowledge.

Regards,

Nabendu.

[RafaelVieira]

Thanks for the input!

Actually, I was almost sure about the impossibility of having this being done by File Receiver adapter.

Mainly because the status itself is defined by the partner application so that particular status code has to be sent back to ECC.

My intention here is to ask to the experts, opinions on how to deal with such question.

Any inputs would be very appreciated.

[Harish]

Hi Rafael,

The only way to update IDOC after processing in receiver system is receiver system place one file after first process. The file needs to process via another interface and update the IDOC status (STATUS IDOC for example).

regards,

Harish

[RafaelVieira]

Yeh Harish, I agree... that's what I was considering as a possible solution.

Or maybe, if the partner application is open for an enhancement, insert a routine that calls an RFC to update ECC after having processed the file.

This would be the IDoc final status (error or a application ack) and the File Receiver adapter could send back the system ack.

[former_member202355]

Hello Rafael,

Status 12: this means IDoc Dispatched OK (TID aka IDoc is no more present in tRFC Queue).

SAP has report RBDMONID which performs Status 03 --> 12 irrespective of File/IDoc reaches to end destination or not.

One - workaround is ALEAUD Message Type which is almost similar to STATUS.

Other - for this one workaround (i know difficult to convince/get this) if partner can configure something or some sort of acknowledgement for us/PI that file is picked, may be a message/response or anything

We can create one more scenario/interface in PI for sending up the STATUS Message type to ECC and get the status change to 06 for success or 05 for failure.

Hope this helps.

Thanks,

[Harish]

Hi Rafael,

Please check the below blog by Maciej Jarecki

Acknowledgment request generated by adapters of Adapter Engine not possible – not any more!

Please check the Shabarish Vijayakumar replyn in the below discussion

Acknowledgement from receiver file Adapter with out BPM

So you can update the

regards,

Harish