Source for the IDOC

[Former Member]

Hi Experts,

Many IDOCS are being created and queuing up  in the production queue. The target system was de-commissioned recently. So we need to stop the IDOC generation.

The problem is we are not sure from where these IDOCS are getting triggered.

In tcode BD64, I could see BAPI method is used and the details are as shown below:

Object name           WorkBreakdownStruct

Method name          SaveReplica

Object type             BUS2054

Method                   SAVEREPLICA

Description              Replicate work breakdown structure (ALE)

Is there anyway to figure out the place from where these IDOCS are getting triggered from?

Thanks for your help in advance.

With Regards,

Fahmeetha M.

[Former Member]

Hi Experts,

Many IDOCS are being created and queuing up  in the production queue. The target system was de-commissioned recently. So we need to stop the IDOC generation.

The problem is we are not sure from where these IDOCS are getting triggered.

In tcode BD64, I could see BAPI method is used and the details are as shown below:

Object name           WorkBreakdownStruct

Method name          SaveReplica

Object type             BUS2054

Method                   SAVEREPLICA

Description              Replicate work breakdown structure (ALE)

Is there anyway to figure out the place from where these IDOCS are getting triggered from?

Thanks for your help in advance.

With Regards,

Fahmeetha M.

[Former Member]

Partner profile table EDP13 would be ideal to start. Find the list of IDOC types configured for the Target system.

[Juwin]

Seems like master data replication job. If you delete/delimit the entry from BD64, that should stop the generation of such IDocs.

Thanks,

Juwin

[Former Member]

Thanks Juwin.

Can you explain how to do the same in BD64.

If we are de-limiting the entry from BD64 will it prevent the IDOCS from getting created? Else it will create and end up in some error status.

Our major concern it is queuing up in WE02.

[Juwin]

You can edit details of the node, to change the validity date:

Or use the delete button, selecting the particular message type:

This should stop the master data distribution IDocs.

Thanks,

Juwin

[Jelena_Perfiljeva]

I looked up this particular message type briefly (before SCN went down) and did not find any special transaction/program to trigger the IDoc creation like it would be in the change pointer scenario, for example.

If this somehow works only based on the distribution setup then you should be OK with expiring or deleting the distribution model, as well as the corresponding profile and port, if applicable and not used elsewhere.

I would test this in a QA/Sandbox system to be on the safe side. First, create new WBS and make sure the IDoc gets generated. Then delete all the configuration and repeat the test. If the IDoc is not created and you don't get any errors then it should be OK.

[Jelena_Perfiljeva]

My guess would be there is a background job running that triggers the IDocs. Check the background jobs around the IDoc creation timestamp.

The IDoc interface decommissioning needs to be done very carefully and you need to make sure that you don't accidentally switch off something that is also used by another interface. Essentially, you need to do the same steps that were done to implement the interface but in reverse. Check if there is any documentation available from when this was initially implemented.

Also you can usually find some information in Google simply by looking up IDoc/message type (which for some reason you didn't mention).

[Former Member]

Thank you Jelena.

I have checked for background jobs around the created timestamp. I could not find any.

And also the generation of IDOCS are not around same time , they are created at random time intervals.

I forgot to mention the message type . Message type is PROJECT.