Outbound IDocs (SAP to NLINK) for Master Data

Owned by Darcy Curtin
Last updated: Jul 24, 2014
2 min read

 

In order for NLINK to receive IDocs from your SAP system, you must do some customization in your SAP system. While you (or your SAP consultants) are responsible for that setup, we do have some tips.

   

Customized/Reduced Message Types          

If you are going to be using change pointers to trigger the outbound IDocs, it is good practice to set up specific Message Types for each interface. This lets you keep the change pointer processing separated from any other interface(s) that might be using the same IDoc Type.

Reducing the Message Type means eliminating the segments and/or fields that are not of interest.

You can do both these steps in transaction BD53.

  

Triggering Mechanism (Master Data)          

You have a few options for triggering outbound IDocs of master data, depending on how much you want to automate in the SAP system.

From most control in SAP to least, these options are:

  1. Change Pointers with Scheduled Job(s) in SAP
  2. Change Pointers with Scheduled Job(s) in NLINK
  3. Change Documents with Scheduled Job(s) in NLINK

If you want to automate everything in SAP, then schedule a recurring job to run RBDMIDOC with an appropriate variant to generate the outbound master data IDocs based on your desired message type.

If you want NLINK to control the schedule, then it can submit the job(s) instead.

If you don’t want to use change pointers, but rather would receive full IDocs every time, then (for master data types that have such supporting programs) NLINK can read the change document table and submit job(s) requesting IDocs for the appropriate master data. (For example, Material Master can be set up this way.)

If you are using change pointers at all, you should have RBDCPCLR scheduled in your SAP system with reasonable frequency.

  

Master Data IDocs—Changes vs. Full IDocs          

IDocs generated by change pointers will only include segments that have changed data. For example, if you have a material master message type that includes MARA and MARC segments, and you change a field at the MARA level, the resultant IDoc will not include any MARC segments.

Each included segment will have an appropriate MSGFN indicating whether the data is being sent because of a create, delete or change.

IDocs generated as “full IDocs” from the various dedicated transactions (e.g., BD10 for material master) will include all instances of all segments included in the selected message type.

However, the MSGFN for each segment will always be 005 (replace).

For each interface, you must determine whether you need the full data and have some other method to determine what changed, or whether changes only are sufficient.

  

Troubleshooting—I changed field X but I didn’t get an IDoc!          

Selecting the segments and fields you want in your customized Message Type is not the same as selecting which database fields trigger the creation of an IDoc change pointer.

Take a look at your message type in transaction BD52 and make sure that all the triggering fields you care about are listed there.