Change Pointer Table in SAP (ALE)

With the evolution of SAP from its early days to the new SAP S4 HANA version, Change Pointers mechanism has been modified drastically. Consequently, the Change Pointers table in SAP has also evolved. In older versions, the ALE/iDoc master data distribution model used tables BDCP and BDCPS for storing Change Pointers. But with new versions of the system such as SAP S4 HANA, SAP has aggregated BDCP and BDCPS tables to create BDCP2, a single Change Pointers table. There are other obsolete Change Pointers in SAP like BDCPV.

Structure of Change Pointers Table BDCP2

FieldData TypeLengthDescription
MESTYPECHAR30Message Type
CPIDENTNUMC10Change Pointer ID
PROCESSCHAR1ALE processing indicator
TABNAMECHAR30Table Name
TABKEYCHAR254Table Key for CDPOS in Character 254
FLDNAMECHAR30Field Name
CRETIMECHAR14Creation time of a Change Pointer
ACTTIMECHAR14Activation time of a Change Pointer
USRNAMECHAR12User name of the person responsible in change document
CDOBJCLCHAR15Object class
CDOBJIDCHAR90Object Value
CDCHGNOCHAR10Change Number of Document
CDCHGIDCHAR1Type of Change

MESTYPE – Message Type

ALE Message Type relates to the master data object. For example, CREMAS for customer master, ARTMAS for article master, COND_A for price conditions, etc.

CPIDENT – Change Pointer ID

CRIDENT is a unique Change Pointer ID.

PROCESS – ALE processing indicator

PROCESS field represents the processing indicator (flag) of the Change Pointer. The change indicator is null until the Change Pointer is processed. ALE processing indicator of processed Change Pointers is flagged as ‘X’.

TABNAME – Table Name

TABNAME holds SAP table name of the updated master data. For example, if the unit of measure (UOM) (MARA-MAXDIM_UOM) is updated, TABNAME will contain the value ‘MARA’. This value corresponds to the table name value in CDPOS-TABNAME.

TABKEY – Table Key for CDPOS in Character 254

TABKEY value is derived from a combination of the table key values of the updated/changed master data table. This is an important field to find the connection between Change Pointers (BDCP2), changed object item (CDPOS) and master data table.

This field in BDCP2 equates with CDPOS-TABKEY. I have provided more info on how we can use this field to find the corresponding entries in the change document table (CDPOS) and related master data table below.

FLDNAME – Field Name

FLDNAME is the name of the updated or changed master data table field. If a new master data is created (ie CDCHGID = I), value ‘KEY’ is assigned to FLDNAME.

CRETIME and ACTTIME

CRETIME is the timestamp of the Change Pointer that was generated or updated at the moment of master data creation/change. ACTTIME holds the timestamp when the Change Pointer is processed.

USRNAME – User Name

CDOBJCL – Change Doc. Object

CDOBJCL is the change document object or ALE message type.

CDOBJID – Object Value

CDOBJID is the key-value of the master data record. It corresponds to the object value field of CDPOS.

CDCHGNO – Document Number

CDCHGNO is the change document number (CDPOS-CHANGENR)

CDCHGID – Change Ind.

CDCHGID is flagged as ‘U’ when master data is updated and as ‘I’ when master data is created (new table entries are created).


How Change Pointers Table Is Updated

Master data distribution framework updates the Change Pointers table when master data records are created or changed in SAP. If you have activated the Change Pointer for specific master data objects (Message Type) such as Article Master, Customer Master, Price Condition, etc., the system updates entries in BDCP2. It happens when these master data records are created or changed.

Let’s look at how you can configure Change Pointers to update automatically or write an ABAP program to update Change Pointers table manually.

Automatically Flag Master Data Changes for Distribution

To activate the Change Pointers and update BDCP2 table automatically,

  1. Go to transaction BD61 and activate Change Pointers generally.
  2. Activate specific Change Pointers of a master data object (MessageType) via transaction BD50.

Manually Update Change Pointers Table

If you have a necessity to write Change Pointers directly (programmatically) to the table BDCP2, use Function Module (FM) CHANGE_POINTERS_CREATE.


Filter Change Pointers using BADI BDCP_BEFORE_WRITE

Before table BDCP2 is updated with change records, the system calls BADI BDCP_BEFORE_WRITE‘. This BADI allows you to implement an ABAP logic to filter Change Pointers before they are updated in the table.

Let’s assume you have activated Change Pointers generally via transaction BD61 and customer master (CRMAS) Change Pointers are activated via transaction BD50. But, for certain customer master data changes, you do not want to update the BDCP2. You can do this by implementing a custom ABAP logic in BADI BDCP_BEFORE_WRITE. At BADI processing time, you need to delete the Change Pointers you do not want to update from BADI’s table parameter ‘CHANGE_POINTERS’.

BADI definition BDCP_BEFORE_WRITE in transaction se18. Filtering of change pointers before writing to database
Change Pointers filtering BADI definition – BDCP_BEFORE_WRITE
Parameters of  method FILTER_BDCPV_BEFORE_WRITE of Change Pointer filter BADI in transaction se18.
Parameters of method FILTER_BDCPV_BEFORE_WRITE of Change Pointer filter BADI

Process Change Pointers Table Entries

Use ABAP program RBDMIDOC (transaction BD21) to process Change Pointers in table BDCP2. You should not let the table records of BDCP2 table grow out of control. Hence, Change Pointers should be processed in an appropriate frequency as per your organization’s use of Change Pointers. Usually, program RBDMIDOC should be set up as a periodic batch job to process Change Pointers.

Create iDocs from Change Pointers using program  RBDMIDOC . Selection parameter Message Type of program assigned with COND_A idoc type.
Create iDocs from Change Pointers using program RBDMIDOC 

Program RBDMIDOC accepts only one Message Type at a time. Hence, if you have Change Pointers of more than one message type activated, the program should be scheduled multiple times with each message type.

Standard ABAP program RBDMIDOC processes Change Pointers with a process indicator (BDCP2-PROCESS) in status ‘Not Processed’. When processing is completed process indicator is updated as ‘X’ in table BDCP2.


Migrate Change Pointers to Table BDCP2 After System Upgrade

After the release of SAP_BASIS 701/711 and higher, Change Pointers tables BDCPV, BDCP, BDCPS became obsolete. The table BDCP2 is the single source of truth for Change Pointers generated in the SAP System and their status.

To transfer the Change Pointers from obsolete BDCP, BDCP2 and BDCPV table to BDCP2 table, you need to execute the report RBDCPMIG_ALL_WITHOUT_MIG_FLAG after the system upgrade.

SAP has recommended running the Change Pointers migration report in batches to avoid performance issues. For example, you can run it for selected batches of message types in background mode. Run the program RBDCPMIG_ALL_WITHOUT_MIG_FLAG in test mode before running it in the productive mode.

Selection screen of Change Pointers migrating program -  RBDCPMIG_ALL_WITHOUT_MIG_FLAG in transaction se38 assigned with selection screen parameter Message Type.
Selection screen of Change Pointers migrating program – RBDCPMIG_ALL_WITHOUT_MIG_FLAG

If you have used obsolete Change Pointers tables directly in your custom programs, you must adjust them to read/write from BDCP2 after the system upgrade. You can read more about how to migrate Change Pointers in SAP note 1165059.


How to Clean Change Pointers Table

To delete obsolete and processed Change Pointers from BDCP2 table, use ABAP program RBDCPCLR.

With time, the Change Pointers tables grow in size due to the accumulation of data, especially if Change Pointers are configured for multiple message types. Hence, it is important to periodically flush the Change Pointers table from obsolete and processed Change Pointers.

Selection screen of Change Pointers clearing program RBDCPCLR with options, obsolete change pointers, message type, data, time, processed change pointers, message type, created on, created at and test run.
Selection screen of Change Pointers clearing program RBDCPCLR

Flag ‘X’ in BDCP2-PROCESS field indicates the Change Pointer is already processed. Option ‘Processed Change Pointers’ deletes the Change Pointers with processed indicator ‘X’.


Relationship Between BDCP2, CDPOS and Master Data Tables

When it comes to troubleshooting master data distribution, iDoc generation and processing of Change Pointers, it is important to understand the relationship between Change Document Object (CD) and Change Pointers in BDCP2 table.

Find the Corresponding Entries in CDPOS

To find the corresponding CDPOS entry from the BDCP2 table, select matching fields from the two columns below,

CDPOS FieldCorresponding BDCP2 Field
OBJECTCLASMESTYPE
OBJECTIDCDOBJID
CHANGENRCDCHGNO
TABNAMETABNAME
TABKEYTABKEY
FNAMEFLDNAME
CHNGINDCDCHGID

CDPOS

Sample CDPOS table entry with fields Change Document, object value, table name, table key, field name, change indicator.
Sample CDPOS table entry

BDCP2

The corresponding BDCP2 table entry for CDPOS table entry.
The corresponding BDCP2 table entry

Find Corresponding Master Data Record

To find the corresponding master data information from BDCP2 table and CDPOS table information, split the ‘Table Long Key’ (BDCP2/CDPOS-TABKEY).

In this example, the table long key (TABKEY) is 100000982466201. This value does not tell us much as it is a collection of values from several table fields. To identify the combination of data columns used to derive ‘table long key’, go to DDIC structure or table (TABNAME) in transaction se11.

Price conditions items master data structure KONPAE with key fields client, condition record number and sequential number of the condition highlighted.
Price conditions items master data structure KONPAE

Then, split the value of ‘table long key’ 100000982466201 using the field length of the KONPAE structure.

The first three characters represent the Client (MANDT), the next ten characters – Condition Record Number (KNUMH), and the last two numbers – the Sequential Number of the Condition (KOPOS).

  • MANDT – 100
  • KNUMH – 0009824662
  • KOPOS – 01

We discovered the Condition Record Number (KNUMH) by breaking the table key.

From the Condition header table (KONH) we can find the condition record master data.

Master data entry updated by Change Pointers - Conditions Header (KONH) in transaction se16n
Master data entry updated by Change Pointers – Conditions Header (KONH)

I hope now the functionalities of the Change Pointers table are clear. If you have any questions, please leave a comment below!

Share with your colleagues!

Get the latest tips and tricks on SAP!

Add a Comment

Your email address will not be published. Required fields are marked *

Get the latest tips and tricks on SAP!