Change Pointer Tables in SAP (ALE) and BDCP2

In this article, we will talk about table BDCP2 and other Change Pointer tables of SAP. First, we will discuss the structure of SAP table BDCP2 and how the Change Pointer table is updated. Secondly, we will talk about how to process Change Pointers from the BDCP2 table. Thirdly, how to migrate Change Pointers when the system is being upgraded. Fourthly, how we can clean obsolete Change Pointers from table BDCP2. Finally, we will see the relationship between BDCP2, CDHDR, and CDPOS.

With the evolution of SAP from its early days to the new SAP S4 HANA version, the 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

Field	Data Type	Length	Description
MESTYPE	CHAR	30	Message Type
CPIDENT	NUMC	10	Change Pointer ID
PROCESS	CHAR	1	ALE processing indicator
TABNAME	CHAR	30	Table Name
TABKEY	CHAR	254	Table Key for CDPOS in Character 254
FLDNAME	CHAR	30	Field Name
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
CDOBJCL	CHAR	15	Object class
CDOBJID	CHAR	90	Object Value
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 BDCP2 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 the Change Pointers table manually.

Automatically Flag Master Data Changes for Distribution

To activate the Change Pointers and update the 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’.

---

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.

Change pointers that process successfully will create iDocs in the corresponding iDoc message type. You can monitor the statuses of iDocs created in we02 or /aif/err transactions.

---

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 from BDCP2 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
OBJECTCLAS	MESTYPE
OBJECTID	CDOBJID
CHANGENR	CDCHGNO
TABNAME	TABNAME
TABKEY	TABKEY
FNAME	FLDNAME
CHNGIND	CDCHGID

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!