Distributing Master Data Using the SMD Tool

Creating and Evaluating Change Pointers

Change pointers are used to determine changes and distribute them to master data objects.

Change pointers are created in the following way:

The application program calls the change document interface for a change document object. To do this the generated function module xyz_DOCUMENT_WRITE is called. Its interface contains two parameters - the old records and the new records - for each table and structure for which change document deltas are to be determined. The change document interface creates a list of changes (table name, table key, field name, change type, old value, new value).

There are three types of changes:

• Insert

  With the insert change type, precisely one record is written (table name, table key, field name = "KEY", change type = insert, old value = empty, new value = empty). The field values are not documented, as they can be found in the database. With this change type it is important that the special field name KEY is used.

• Update

  With the update change type, one record is written for each changed field (table name, table key, field name = <field name>, change type = update, old value = ABC, new value = DEF).

  This change type has one variant:

  In the definition of the change document object you can also specify that a delete record and an insert record are written rather than an update record. This is why the change type is also a key field in the CDPOS table. Two records for delete and insert can therefore be written for one table name, table key and field name.

• Delete

  With the delete change type precisely one record is written (same as with insert). You can also specify in the definition of the change document object that all values are saved. Then there will be one record for each field.

When change documents are written, the interface for writing change pointers is called. Records which have message types to be sent are determined from table TBD62 for the table name, table key and field name. TBD62 consists of the table name, table key, field name and message type. A change pointer is written for each active message type in table TBDA2. A record with the change information is saved in table BDCP and a status record for each message type is saved in table BDCPS.

For this reason you have to add to table TBD62 all the changed fields that will cause a message (IDoc) to be sent.

A New Storage to Improve Performance

A new storage BDCP2 for change pointers has been implemented for certain message types to improve system performance. To use the new storage the following prerequisites must be fulfilled:

Change pointers are accessed exclusively from the following interfaces and deletion program RBDCPCLR:

• CHANGE_POINTERS_CREATE

• CHANGE_POINTERS_CREATE_DIRECT

• CHANGE_POINTERS_READ

• CHANGE_POINTERS_STATUS_WRITE

If these prerequisites are fulfilled for a message type, you can flag this message type as BDCP2-enabled by choosing  ALE Development  IDoc  Engineering Change Management  Define Function Module for Evaluation  (BD60).

For more information about performing the migration see the Implementation Guide.

Activating Change Pointers for Each Message Type

In table TBDA2 you can activate or deactivate the writing of change pointers for a specific master data object.

To maintain table TDBA2, in Customizing choose:

 SAP Web Application Server  IDoc Interface/ALE  Modeling and Implementing Business Processes  Master Data Distribution  Replication of Modified Data  Activate Change Pointers for Message Types 

(transaction BD50).

Enter data in table TBDA2 with the message type for your master data object. For the delivery to the customer, the "Active" flag for the entry should not be set. If, for test purposes, you want to activate the writing of change pointers for the master data object, you must set the 'Active' flag for the TBDA2 entry for your message type.

Maintaining Change-Relevant Fields for Message Types

Change document fields from the change document object are entered in table TBD62. Change pointers are written when change document fields are logged via the change document interface.

In table TBD62, define for your message type all the change document fields, for which change pointers are to be written, so that changes to your master data object can be distributed to other systems.

When you add an entry in a table for your master data object, a change document field with the imaginary field name KEY is used to log this kind of change (examples: MATERIAL MARA KEY for the creation of a material, MATERIAL MARC KEY for the addition of a plant data to a plant). You must also include these entries in table TBD62, and you must do so for all tables from the change document object for your master data object.

Additions or changes to a long text are logged with an entry in the change document item. This entry has the text object for the table name, and a value comprising the text ID and the language key for the field name. If changes to long texts for a master data object are to be distributed, these entries must also be included in table TBD62. You are not required to do this for every possible language key. It is sufficient to include an entry in table TBD62 for the text ID concerned, which has a value for the field name comprising the text ID and the character * (such as MATERIAL MATERIAL BEST* for the purchase order text in the material master).

Activating Change Pointers Generally

To activate master data distribution using change pointers, in Customizing choose:

 SAP Web Application Server  IDoc Interface/ALE  Modeling and Implementing Business Processes  Master Data Distribution  Replication of Modified Data  Activate Change Pointers - Generally  (transaction BD61)

Implementing the Function Module for Evaluating Change Pointers

When change pointers are processed, IDocs for the master data objects are generated and dispatched. Change pointers are processed and IDocs subsequently generated and dispatched for each message type (for example, MATMAS for the material master). A function module carries out this process (for example, MASTERIDOC_CREATE_SMD_MATMAS for the material master).

You need to implement the function module for each message type. The naming convention for the function module is MASTERIDOC_CREATE_SMD_xxxxxx, where xxxxxx is the name of the message type.

Below is a description of how to implement the function module that processes change pointers and generates and sends the IDoc. Refer to the function module MASTERIDOC_CREATE_SMD_MATMAS for the material master as an example. You can also use function module MASTERIDOC_CREATE_SMD_MATCOR for the core material master as a model for your function module. The IDoc type MATCOR01 for the core material master consists of merely the two segments: E1MARAC and E1MAKTC and contains only the core data from the material master. Function module MASTERIDOC_CREATE_SMD_MATCOR for the core material master has a more simple structure than the function module MASTERIDOC_CREATE_SMD_MATMAS for the complete material master.

Now create a function module for your message type. The interface of the function module is preset and consists of the parameter for the message type.

Before you can start the transaction for your message type, you must maintain the message type assignment to the function module in control table TBDME. Define an entry for your message type in table TBDME, the reference message type being the same as your message type, and assign the function module. For examples, take a look at the entries for message type MATMAS (Material Master) and MATCOR (Core Material Master).

Implement the following steps in your function module to process change pointers and to generate and send IDocs:

1. Read all the change pointers that have not yet been processed for your message type using the function module CHANGE_POINTERS_READ.

2. Create an IDoc for every modified master data object. In the IDoc, only fill the segments that, according to the change pointers, were changed. In every segment, fill the first field MSGFN as follows:

   009, if the segment was added

   004, if segment fields were changed

   003, if the segment was deleted

   018, if segment fields were not changed, but the segment must be included in the IDoc because hierarchically subordinate segments in the IDoc have to be sent.

3. Pass the IDoc to the ALE layer by calling function module MASTER_IDOC_DISTRIBUTE.

4. For the master data object that has just been processed, set the change pointers to 'Finished'. This is done by calling function module CHANGE_POINTERS_STATUS_WRITE.

5. Execute the COMMIT WORK command and call the DEQUEUE_ALL function module. For performance reasons, do not perform this step after every IDoc. Wait until you have created, for example, 50 IDocs.

Defining the ALE Object Type MSGFN as a Filter Object Type

In the receiver determination for message types that have not been generated by the BAPI-ALE interface, IDoc segments containing modified data may be filtered off. Sometimes there may still be IDoc segments that do not contain any modified data at the end of segment chains. These segments have only been included due to the segment hierarchy in the IDoc.

For ALE outbound processing to be carried out, these attached segments must be suppressed by assigning the value 018 to them in the field MSGFN when the IDoc is generated.

You must also make the following settings:

• MSGFN must be defined as an ALE object type. Under ALE Development, choose  IDoc  Data Filtering  Define Filter Object Type  (transaction BD95). Generally the ALE object type MSGFN has already been defined and the field MSGFN assigned to the table BDIPARAM.

• MSGFN must be specified as the filter object type for the new message type and for the new segment types in table TBD21. The entry in table TBD21 consists of the message type name under MESTYP, the segment type SEGTYP, and the field name MSGFN under FLDNAM. Under ALE Development, choose  IDoc  Data Filtering  Assign Filter Object Type to IDoc Field  (transaction BD59).

• Note

  When distributing changes with asynchronous BAPIs, for compatibility reasons, you should use the FUNCTION field with the data element BAPIFN and the fixed values INS, DEL, UPD, REF and IGN. This identifies the type of change to be distributed with the BAPI.

  Copy the FUNCTION field to each structured parameter. Then you can, for example, distribute the deletion of a data record.