Home Tips and Tricks IDocs / BDocs

IDOCS / BDOCS
Change pointers for a custom message type
User Rating:  / 1
Written by Henrik Frank   
Tuesday, 24 February 2009
 Scenario: We want to crerate a custom message type for idoc type MATMAS03, activate change pointers
for the message type and use a distribution model to filter and distribute the idoc.

1. WE81 Create new message type  ZMATMAS_SIMATIC

2. WE82 make connection between IDOC type MATMAS03 and message type  ZMATMAS_SIMATIC

3. BD59 Create the field that we will use to filter the idoc in the distribution model    

We will use plant (WERKS) and material type (MTKLAS)  to filter the idocs:

Note: You can take a look at the standard message type MATMAS to find ALE object type and Segm. type

4. BD64 Create distribution model.

Press button Create model view to create a new distrbution model 

Press select the new model and press button Add message type to add the new message type and the
sender and receiver systems

Your distribution model should now look like this

Under the message type ZMATMAS_SIMATIC choose the filter and add the fields from step 3 and the filter
cirterias.
We only want to distribute IDOC where plant = 1002 and material type is HALB or ROH.

You are now finished with the distribution model

5. BD60 To be able to use change pointers for the new message type, it must have a reference to the
original message type MATMAS. You make this reference in BD60.

6. BD52 In this transaction you set up the fields that triggers a change. Note that it is not possible to copy
the fields from and existing message type (For example from MATMAS). However, you can use an existing
message type in BD52 to find out Object and table name for the fields.

In the example below we only wants to trigger a change pointer when the material text changes.
7. You should now be ready to test that the change pointer works for the new transaction.

Make a change to the material text for a material in plant 1002 of material type HALB or
ROH
Run transaction BD21 or ABAP program RBDMIDOC for message type
ZMATMAS_SIMATIC
Check that an outbound IDOC has been  created (Transaction WE02)
 

During integration projects, one might face requirement to trigger delta information
like creation/change of master data out of SAP ERP. There might be additional
requirements to trigger this at scheduled interval or as a nightly job.

To fulfill the above requirement, “Change pointers” can be activated for the required
IDOC’s. A background job can trigger the generated IDOC’s to PI.

Following are the applicable situations:1. Trigger delta data2. Batch processing3.
Timed/Nightly processing

The solution is to activate change pointers from Customizing and use report
program RBDMIDOC. Separate jobs can be scheduled for separate IDOC’s.

Steps to be followed

1. Goto the following path in TCODE: SPRO.SPRO > SAP NetWeaver > Application
Server > Idoc interface/ALE > Modeling and Implementing Business Process >
Master data distribution > Replication of modified data > activate change pointers
for message types.
2. Select the IDOCs where change pointers are to be activated and save your
settings.
3. Run transaction BD22 to delete existing Change pointers. This is required to clear
the existing change pointers. If this is not done, enormous amount of IDOC might be
generated during the first run.
4. Run Schedule report RBDMIDOC ( TCode: BD21)
Tip: You can check for processed IDOC’s using WE05.

Change documents and change pointers

Tables
CDHDR Change document header
CDPOS Change document items
JCDS Change documents for System/User statuses (Changes to table JEST)
Function modules
Tables CDHDR and CDPOS can be read with function modules
• CHANGEDOCUMENT_READ_POSITIONS
• CHANGEDOCUMENT_READ_HEADERS
Transaction codes related to Change Pointers
• BD21 Create IDOCs from change documents
• BD50 Activate Change Ptrs for Mess. Type
• BD54 Maintaining Logical Systems
• BD61 Activate Change Pointers - Generally
Programs
RSDMIDOC: Generates IDOCS from change pointers
var fe = FindFrame("toc", top); if ((fe != null) && (chmtop.c2wtopf.jstree != null)) { if
(chmtop.c2wtopf.FITEMS[chmtop.c2wtopf.pagenum] != chmtop.c2wtopf.pageid)
chmtop.c2wtopf.jstree.OpenTreeNode("" + chmtop.c2wtopf.pageid); }
Last Updated (Tuesday, 30 November 1999 00:00)

BD21 – Creating IDoc Types from Change Pointers

Sometimes lot of Change Pointer gets created, but fails to get processed
due to system issues. This report is quite helpful to generate IDocs from
unprocessed change pointers.

The status of change pointer can easily be checked with SE16 on

BDCPV.

BD22 -Delete Change Pointers

Sometimes we can have scenarios where a lot of change pointers gets

created due to some erroneous configuration or settings. BD22 can be
used to delete the change pointers.

Change Pointers in SAP

Change pointers are R/3 objects that mark changes to SAP master data. Change pointers are managed by
mechanisms in a Shared Master Data (SMD) tool and are based on Change Document (CD) objects. CD objects record
the changes occurring to master data at a field level. These changes are stored in tables CDHDR (header table) and
CDPOS (detail table).
ALE configuration provides a link between CD objects and change pointers. Internal mechanisms update tables
BDCP and BDCPS, which host the change pointers. While CD objects are application-data-specific, the processing
status of change pointers is message-type-specific. Also, the ALE change pointers are activated first at a general
level and then at the message-type level.
ALE provides powerful capabilities to capture changes occurring to master data and to distribute them via the IDOC
interface. This feature can be used to keep two or more systems synchronized with respect to master data.

Steps to configure change Pointers:

1. BD61 - Activate the change pointers globally
2. BD50 - Activate the change pointers for individual message types(BD50)
3. RBDMIDOC - Schedule the program RBDMIDOC to run periodically on the sending system.
For Delete Change pointers Tcode BD22 and the standard program is RBDCPCLR
Reduction tool(reduced message types) using Tcode BD53

See the check box in Further characteristics tab of the data element for change document.SE11-->enter data
element-->Further characteristics tabThe check box is to be checked to trigger change pointers.
The change pointer tables (BDCP & BDCPS) should be as small as possible. Use as few change pointers as possible
and delete change pointers which you no longer need.

Activities - Keep it limited

1. Do you really need change pointers?You need change pointers to distribute changes with the ALE SMD tool. If you
do not use this tool, you do not need to write change pointers.You can deactivate change pointers and activate
them again with the transaction BD61.

2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can deactivate change pointers for
this messages type.You can deactivate change pointers for the message type and reactivate them again.For
reduced message types, deactivate the change pointer with the Reduction tool (Tcode BD53).

3. Are there still too many change pointers to be processed?

The change pointers are analyzed with the transaction BD21 or the report RBDMIDOC in ALE and flagged as
processed. If the change pointers are created periodically, this report should also run periodically.

4. Are no longer required change pointers reorganized in time?

The report RBDCPCLR (transaction BD22) to reorganize the change pointer should run periodically. Depending on
how many change pointers are created or processed, you can schedule the background job hourly, daily or weekly.
You should delete all obsolete and processed change pointers. You can also use this report for specified message
types
Change Pointers
Table of Contents
Change Pointers
Activation / Deactivation of Change Pointers
Change Pointer tables

The Distribution Model

Change Pointer processing

Change pointers are R/3 objexts that mark changes to SAP Master Data. They are the
mechanism through which data can be sent to another SAP systems or external systems if
there is a change to specific fields in the master data. ALE provides powerful capabilities
to capture changes occurring to master data and to distribute them via the IDOC interface.

Activation / Deactivation of Change Pointers

The use of Change Pointers can be activated or deactivated on general level with
transaction BD61
Change Pointers can be activated for a specific message type (for example MATMAS,
DESADV, CREMAS, etc) with transaction BD50

Not all fields are relevant for other systems. This means that only if specific fields are
changed a message to other system(s) must be created. This setting on field level is done
with transaction BD52. Here fields of a specific message type can be added and/or
deleted.
If for example the field BISMT (Old material Number) is changed by the user then a
change pointer is created.
Later this change pointer can be used to create messages to 1 or more external systems.

Change Pointer tables

Changes are stored as change documents in the CDHDR (header) and CDPOS tables
(details).

The contents of the change document are passed from the change document system to
the SMD Tool. For each document the system checks that the modified field and the table
are assigned to a message type. If this is the case then a change pointer is created.
Change pointers are basically the key fields of the table that contains the changed field

Change pointers are stored in tables BDCP and BDCPS

For performance reasons these tables should be as small as possible (not a lot of
records).

The Distribution Model

When a relevant change is found then a Master Idoc is created. With the use of the
Distribution Model it is determined to which system(s) the message is to be sent. If the
message is to be sent to an other system then a communication Idoc is created.

In the distribution model it is determined which messages are sent to which systems. For
example Material Master messages for Plant 1000 are sent to system A and Material
Master messages for Plant 2000 are sent to 2000. If now a change is made to a material
of plant 1000 then a Master Idoc is created. Based on this master idoc and the distribution
model a communication idoc is created for system A. If a change is made to a material of
Plant 3000 then also a Master Idoc is created but as Plant 3000 is not specified in the
distribution model no communication idoc is created and so no message is sent to an
other system.

The distribution model is maintained with transaction BD64.

For each partner (other system) message types and filter criteria can be specified.
For example here the material master messages are sent for specific plant codes and
sales organizations.

Change Pointer processing

To distribute changed master data change pointers have to be processed. Depending on
the message type, the program RBDMIDOC creates the master IDocs and passes them to
the ALE layer for dispatch.

RBDMIDOC is usually automatically executed in the background. A background job should

be scheduled for each message type
Depending on the settings in the partner profiles, it may be necessary to send IDocs
directly by executing the program RSEOUT00

It is also possible to create the idocs on line with transaction BD21

With this transaction idocs can be created for a specific message type (like MATMAS,
CREMAS, etc.). The transaction will report how many Master Idoc have been created and
how many communication idocs.

Note that the Master Idocs are not stored in any table. The communication idocs can be
viewed with transaction WE02 or WE05.
Conversion of IDOCs to XML format at SAP Level
This article details about the step by step in conversion of IDOCs to XML format for further use in
XI or any other application. It is assumed that the reader of this article has some knowledge in
ALE, IDOCs and Change Pointers.
Scenario: Conversion of the Material IDOC (Message type: MATMAS) to XML format and store the
same in the application server of SAP.
Approach Change pointers are used for sending IDOCs for master data like Material Master. To
work with Change pointers, following two steps have to be performed:
• Turn on change pointer update generally • Providing the message types to be included
for change pointer updation.
To do the above configurations: TCode: SALE␣IDOC Interface / Application Link Enabling
(SALE)␣Modeling and implementing Business Processes ␣Master Data Distribution
␣Replication of Master Data
ALE Configuration Steps: 1. Creation of logical system for the sender system. 2.
Assignment of logical system to the client. 3. Create a logical system for the recipient 4.
Creation of RFC destination (Connection type:TCP/IP)
5. Creation of Model View (TCode: BD64).

6. Save the Model View and Generate Partner Profiles. 7. There might be a problem with the
automatic Port creation. Creation of the
port has to be done manually. 8. Create an XML Port from the transaction WE21 (Port type:
XML File).

Here directory is the path on the application server. The Function Module is used for file naming
conventions. Any of the SAP provided function modules could be used for this (Use F4 help to
check on this) or create any custom function module for any other naming conventions.
In the outbound trigger tab, mention the RFC destination created earlier.
9. Make an entry in the partner profile generated earlier for message type MATMAS.

10.A background job need to be scheduled, for a periodic run (interval as required) for the program
RBDMIDOC with the message type MATMAS.
11.Depending on the settings in the partner profiles, it may be necessary to send IDocs directly by
executing the program RSEOUT00 (if the setting is to “Collect IDocs”)
Test the above scenario by creating a material using MM01. An XML file would have been created
in the directory specified in the XML port. The file could be downloaded onto the front-end system
using the transaction CG3Y.

IDOC type and IDOC. An Intermediate Document (IDOC) type represents

the structure of the data associated with a message type (DEBMAS02 for
message type DEBMAS — Customer Master, and WMMBID02 for message
type WMMBXY— Goods Movements), while an IDOC is an object
containing the data of a particular message type. IDOCs are data
containers with intelligence built in. Each IDOC contains one and only
one business object. For example, an IDOC of type SHPMNT01, message
type SHPMNT, will contain data only of one Shipment Document.
Generally, the architecture of an IDOC is independent of the message
type by virtue of ALE’s ability to redefine it for any message type.
Figure 1 Structure of an IDOC.

• The control record, or EDI_DC, is a control structure that contains

several fields with information about the IDOC, such as what IDOC type
it is, the message type, sender and receiver information, and direction (1
for outbound, 2 for inbound). This information provides control data on
the outbound, and processing options on an inbound IDOC. It also has as
its key the Client (MANDT) and the IDOC number (DOCNUM). The EDI_DC
record of an IDOC is stored in table EDIDC. Every IDOC has one control
record.

• The data record, which conforms to the structure EDI_DD, contains the
application data. Every EDI_DD record has a key portion that is 55 bytes
in length (or 63, depending on the SAP release), which consists of
several fields describing the content of the record. The key of 55/63
bytes is followed by a field SDATA, which is 1000 bytes in length and of
data type Long Character. The SDATA field holds the application data,
and its structure is determined by the key field SEGNAM (Segment
Name). An IDOC consists of one or more data records, and its sequence
and structure are dictated by the sequence and structure of segments in
a given IDOC type. The SDATA portion of the data record is redefined for
every occurrence based on the structure of the segment, with the first
55/63 bytes of the data record identifying the segment name, sequence,
and hierarchy. In an outbound interface, ALE/EDI function modules
populate these segments with application data. In an inbound interface,
the application modules process the data contained in the segments.
Data records are stored on table EDID2 that belongs to the cluster
EDI30C.

In SAP, from a Data Dictionary perspective, IDOC segments adhere to a

naming convention. Each segment has three components, each marked
by a different prefix —E1 for segment type, E2 for segment definition,
and E3 for segment documentation. For example, the first segment of
IDOC type DEBMAS02 is E1KNA1M. Its definition is contained in
structure E2KNA1M, and its documentation is in E3KNA1M. When the
IDOC is externalized, we see the segment name addressed by its E2
prefix. For all practical purposes, we will use only the E2 prefix when
referring to IDOC segments. Also, most segment names represent Data
Dictionary tables.

• The status record conforms to the dictionary structure EDI_DS. It

contains information on the state of the IDOC as it passes through the
various stages of processing. The STATUS field has a length of two
bytes (data type CHAR), with a range of values: 01–41 for outbound and
50–73 for inbound IDOCs. The status record also includes date and
timestamps for when that particular state was reached. The status
records maintain a history of the IDOC states. An IDOC may have one or
more status records, which are stored in table EDIDS (see Figure 2, page
82). These records can be accessed or created only by SAP function
modules (APIs), and are not externalized.

Figure 2 the IDOC database.

IDOC objects consist of a Basic IDOC type, an Extension type, and an

IDOC type.

In an R/3 system, IDOCs are identified by a unique IDOC number (field

DOCNUM), and all three record types are tied together with this number.
The IDOC number is internally assigned by SAP. It is possible to maintain
the number range of IDOCs.

You can display information about IDOC record types by executing

transaction WE61 or using the following menu path from the main R/3
menu: Tools -> Administration -> Administration -> Process Technology -> IDOC ->
IDOC Basis (*) -> Documentation -> IDOC Record Types. You can reach IDOC
Basis (*) by executing transaction WEDI, which is frequently used in ALE
and EDI. You can display information about IDOC types, such as
DEBMAS02 and INVOIC01 by executing transaction WE60 or using the
following menu path from WEDI: Documentation -> IDOC types.

1) Difference between BADI and USER-EXIT.i) BADI's can be used any number of times, where as
USER-EXITS can be used only one time. Ex:- if your assigning a USER-EXIT to a project in (CMOD), then
you can not assign the same to other project.

ii) BADI's are oops based.