Preventing IDoc duplication

[Former Member]

Hi,

Not sure if this question applies to this forum or if it applies to application server issue but we have 1 receiver SAP ECC and 2 SAP ECC senders of same IDocs because we have connected 2 different systems having same data for test purposes. When both the sender systems send the same data and post as IDoc in receiver system, it causes duplication of IDocs with double records. We are using XI as the middle component between the sending and receiving systems.

My question is, is there any way to prevent this from duplicating the IDocs in receiving system? or What is the best way or how to prevent this duplication of IDocs? Is there a standard function module or BAPI to do this check? Or is there any way to prevent this in XI or sending systems? Does anyone have any other ideas that has worked in this situation?

Thanks,

Sangita

[Former Member]

Hi,

Not sure if this question applies to this forum or if it applies to application server issue but we have 1 receiver SAP ECC and 2 SAP ECC senders of same IDocs because we have connected 2 different systems having same data for test purposes. When both the sender systems send the same data and post as IDoc in receiver system, it causes duplication of IDocs with double records. We are using XI as the middle component between the sending and receiving systems.

My question is, is there any way to prevent this from duplicating the IDocs in receiving system? or What is the best way or how to prevent this duplication of IDocs? Is there a standard function module or BAPI to do this check? Or is there any way to prevent this in XI or sending systems? Does anyone have any other ideas that has worked in this situation?

Thanks,

Sangita

[vinod_vemuru2]

Hi,

Probably XI can collect the IDOCs, validate and remove the duplicates before sending to SAP system.

Thanks,

Vinod.

[Former Member]

Hi,

Thanks for your reply. Can you please provide steps or elaborate on how you think XI can validate and remove duplicate IDocs before sending to the receiving system?

[vinod_vemuru2]

Hi,

Having second thought, why does two systems sending same data? Don't you think there is a flaw in the design/business flow? Please discuss with functional and business to have a better design.

I am not sure if XI has full control over the data. Just asked to check with them if it is possible at their end.

Thanks,

Vinod.

[Former Member]

Hi,

Thanks for your reply. This is just for training and testing, we will remove it after the initial testing is done but we want to prevent the duplication if possible.

[Jelena_Perfiljeva]

I think this is definitly not an ABAP question. Due to the way the data is stored, it would be very difficult to find a "duplicate" IDoc. Not sure though what sense this setup makes, even for testing purposes... So I'd also ask why the data has to be sent twice.

Unfortunately, I don't know much about XI, but am kind of skeptical that it would manage this too (how would it know that an IDoc is "duplicate"?). But you could ask this in the XI forum.

[Former Member]

Hi,

The data is not sent twice but in case the data gets sent twice due to dual connectivity, is there any way to prevent it or stop it? One way I think could be by using communication channels. I'd appreciate any feedback or thoughts.

Thanks.

[prabhu_s2]

it is not possible to do it in XI (not even using comm channel as it is more concentrated on connectivites). But one thing you can control is in the recv system....having the data checked by key fields in primary tables to see if posted and change the idoc status....in this case the duplicate idoc will go for an error

[Former Member]

>

> Hi,
> 
> Not sure if this question applies to this forum or if it applies to application server issue but we have 1 receiver SAP ECC and 2 SAP ECC senders of same IDocs because we have connected 2 different systems having same data for test purposes. When both the sender systems send the same data and post as IDoc in receiver system, it causes duplication of IDocs with double records. We are using XI as the middle component between the sending and receiving systems.
> 
> My question is, is there any way to prevent this from duplicating the IDocs in receiving system? or What is the best way or how to prevent this duplication of IDocs? Is there a standard function module or BAPI to do this check? Or is there any way to prevent this in XI or sending systems? Does anyone have any other ideas that has worked in this situation?
> 
> Thanks,
> Sangita

OK , let me sum up your case ,

You have 2 sender systems , which sends the IDOCS

you have 1 receiver system , which receives the IDOC via XI.

Now due to some reason both sender system creates exactly the same IDOC ( which may be correct from technology point of view ) but I do not see valid business reason for that, anyway it seems just an odd scenario , but the issue is you want to filter out of those 2 similar IDOCS only 1 should go to Target system.

If my understanding is correct of above scenario, XI will not be able to distinguish between these 2 IDOCS as duplicate,unless

You use BPM to collect the IDOCs and remove duplicates before pushing it to Receiver system. This solution may seem too much of a work which is just bcos of testing systems.

So easiest way would be to remove the business reason as why both system are triggering the IDOCs or they may be completely valid.

Thanks,

[rainer_hbenthal]

Thats not possible in Xi. How long should XI keep the idocs to check them against those which will come in the future?

On the other hand, how you wanna determine in the receiver id a duplicate one?

A is sending an idoc which is stored.

A is sending again an idoc later on, so what do you wanna do? You cant determine if the values stored in the table are coming fromn a or b last time.

This is a complete weird scenario. Change this und do not mix up cause and effect. Correct the cause, not the effect.

[Former Member]

I doubt the functionality using Collect step of BPM if you are not sure of the exact time interval between the same data from 2 different senders.

Identify the field which is going to be same in case of same IDOC data... May be Order # or some field of the IDOC.

Based on this field value, you can either filter it out in PI (may be using a file look up or jdbc look up) without using BPM or in the receiver itself....

Thanks,

[Jelena_Perfiljeva]

Sangita, I completely agree with the previous post - there should not be a valid business reason to have two systems sending the same exact IDoc. If you're using this for testing (I've already mentioned that this doesn't make sense), you'll have to address the duplicate entries by removing the data they created.

In the production system you just must not have such setup, period. If you do, then I guess your Basis team need to rethink their landscape.

It is also still unclear what kinds of IDocs we're talking about - master data (e.g. Material Master) or transaction data (e.g. Sales Order). In any case, it's just hard to imagine any valid scenario in the real-life production business setting when the same data would be received from different recipients. E.g. different customers will never submit the same order and two external systems should never try to create the same material. (If they do then there is a business process issue in the organization.)

The bottom line is that we cannot wrap a piece of code around every possible potential problem, which may not ever happen. The IDocs are just not meant to be used in the way your organization is trying to use them. Not sure how many more posts are needed to convince you...

[Former Member]

Hi All,

Thank you all for your kind responses. I understand that this scenario does not make sense but it is for test purposes only and will not be used in productive environment. Please note that the same sender system will not repeatedly send the same IDoc again but second sender system having same data might send the IDoc to the receiving system which may cause duplication. In this case, the concern is to prevent or avoid duplication in the receiver system.

Thanks.

[Former Member]

This scenario was for prototype and testing and not used for quality or production. Thanks to all who responded.