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
|CPIDENT||NUMC||10||Change Pointer ID|
|PROCESS||CHAR||1||ALE processing indicator|
|TABKEY||CHAR||254||Table Key for CDPOS in Character 254|
|CRETIME||CHAR||14||Creation time of a Change Pointer|
|ACTTIME||CHAR||14||Activation time of a Change Pointer|
|USRNAME||CHAR||12||User name of the person responsible in change document|
|CDCHGNO||CHAR||10||Change Number of Document|
|CDCHGID||CHAR||1||Type 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,
- Go to transaction BD61 and activate Change Pointers generally.
- 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’.
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.
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.
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.
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 Field||Corresponding BDCP2 Field|
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.
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.
I hope now the functionalities of the Change Pointers table are clear. If you have any questions, please leave a comment below!