Skip to Content

In my earlier blog IDoc Packaging – SAP PI 7.1 EHP1 (and above), we saw how using the new feature in the Sender IDoc adapter we can avoid BPM and send packaged IDocs to PI. In this blog, we will try to address reprocessing of these messages when errors creep up in PI.

 

What is the potential Error?

The potential error that might lead to reprocessing is data mapping / issues during transformation. Ex. In a package of say 1000 IDocs, if the field of an IDoc has wrong value which leads to  mapping error in PI.

Note: Issues with queues, target adapter etc are not considered here

 

How to reprocess an IDoc package?

In most of the scenarios the need would be to reprocess the whole batch (package). Below are some approaches towards this;

 

1. Reprocessing in SAP PI

It is always possible to rectify the payload and reprocess the message from PI. In PI 7.1, you have the option of editing the message and reprocessing them from the runtime workbench (RWB-> Message Monitoring).

Screenshot:

image

 

 

2. Resending the package from SAP R3/ECC

Many a times organizations do not advice the middleware handling correction of messages in terms of the data. The standard might be to rectify the data at the source and re-trigger the interface (I personally believe that this is the best way since it helps the data to be modified at the source and hence maintain a clean(er) version of the same)

When sending an IDoc package (assume N IDocs) if it goes into a data mapping error, we can fix the data at the source and resend the whole package again as follows;

a. In PI, with a bit of troubleshooting you will be able to figure out which data caused the error and hence the IDoc that contains the erroneous data

b.From SXMB_MONI, you can extract all IDoc numbers including the IDoc number with the error(s) – This can be manual or you can write a simple report in ABAP or JAVA that will parse the XML and extract all IDoc numbers in the payload

c. You can edit the erroneous IDoc(s) in WE02 (of R3/ECC)

d. In R3/ECC, use the report RC1_IDOC_SET_STATUS to change the status of the IDocs (to Ready for Dispatch)

Note: IDoc Status

Screenshot:

image

 

e. Use RSEOUT00 and send the N IDocs again to PI

 

The above is one of the methods that you can employee for the IDoc packaging scenario. 

 

Do you have a better idea? If so please post it as a comment or be part of the conversation on this Reprocessing best practice and I will keep adding them as alternatives to the blog.

Hope this would help in the maintenance of interfaces designed using the feature of IDoc packaging.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Niki Scaglione
    Hello,

    Thank you for sharing, just I’m considering the case of big block of Idocs in the same package and to reset Idoc status. If a new error is raised again then you have to loop n times “changing Idoc status” till the end. I would prefer to delete entire packaged message and resend new Idocs again after checking application that created these.
    What Do you think about this?

    Kind Regards,
    Niki Scaglione

    (0) 
    1. Shabarish Vijayakumar Post author
      yes I agree. But there can be situations when the IDocs are being created around the day (by multiple teams or individuals) and they are being dispatched to PI only during the end of the day as a single package.

      In such a case how would you have to recreate all of them?

      (0) 
      1. Niki Scaglione
        That’s true but it’s a new constraint, also finding who generated wrong Idocs to be correct is not easy. Application team is aware about every Idoc number created? In any case, you might address to them for fixing Idoc content, so that means probably also modify Idoc and then resend or change its status.
        I will surely follow one solution since I’m currently working on this.
        Kind Regards,
        Niki Scaglione 
        (0) 

Leave a Reply