Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
...
Triggering Mechanism (Master Data)
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.
...
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:
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.)Note:
If you are using change pointers at all, you should have RBDCPCLR scheduled in your SAP system with reasonable frequency.