Virtual Change Pointer Technique
Change Pointers are log entries to remember all modified records relevant for ALE. They are log entries to table BDCP & BDCP2, which are written every time a transaction modifies certain fields.
Virtual Change pointers works based on the principle reference of change pointer entries that are maintained in BD52 without actually creating entries in BDCP / BDCP2.
Use of Virtual change pointer to trigger IDoc would be preferred when standard change pointer object is not available. This can also be preferred for business critical data where scheduled job duration is requested for less than 15 min.
This document briefly explains the step by step procedure needs to be followed to create Virtual change pointers.
1. There has to be an Enhancement spot/ Business Transaction Event / User Exit for the standard Tcode for which virtual change pointer technique is applied.
2. Above spot should have access to all the field change history for comparison, i.e. Access to both old and new data in current go.
Procedure to create virtual change pointer entry
The developer is well versed with IDoc Process and Configurations required. IDoc configuration and Partner Profile management is not the scope of this document. The developer has to perform the configuration apart from the steps mentioned below to generate IDoc.
For concept of Generated IDoc, please refer the white paper for Generated IDocs.
Create field entries in BD52 like we maintain in case of change pointers.
Fields that are maintained above will only be considered for Virtual change pointer creation and are stored in database table TBD62 under respective message type.
Key Point being Change pointer status that has to be kept inactive in BD50. So that BDCP entries will not get created even if there are any changes made in Standard transaction.
Apply the logic to check for changes. Here task is to get all the list of fields that are maintained under BD52, by querying TBD62 table for corresponding Message type. Use field symbols to get the values corresponding to the field entries for which are accessible (As per the Prerequisites 2 mentioned earlier).Compare the fields in both OLD and NEW structures available in the section for above maintained fields. If there are any changes found proceed further to Setp4 else exit without any changes.
From the above captured values either “MASTER_IDOC_DISTRIBUTE” is called to trigger Idoc directly or in case of Generated Idoc call “SWO_CREATE” and “SWO_INVOKE” to trigger outbound Idoc. Bypassing required primary entries.
Configuration required in ABAP
Case: Virtual Change Pointer to be activated for Equipment Master with custom message type ZOTC_EQUI. The IDoc type in this case id generated IDoc.
1. Maintain fields in BD52 as below.
Below screen shot is a reference with Message type: ZOTC_EQUI, with required fields.
2. Do not add message type in BD50. Evenif It is added, keep change pointers for respective message type deactivated.
Sample ABAP code
Following is the Example code needs to be written in ABAP.
For reference you can find below sample code for Equipment Master BTE ‘000020’.
Below we can find the access to both NEW as well as OLD structures in a BTE (ref) as it is mentioned in SEC 3.0 – Step3.
*” REFERENCE(HEQKT_OLD) LIKE EQKT STRUCTURE EQKT
*” REFERENCE(HEQUI_OLD) LIKE EQUI STRUCTURE EQUI
*” REFERENCE(HEQUZ_OLD) LIKE EQUZ STRUCTURE EQUZ
*” REFERENCE(HILOA_OLD) LIKE ILOA STRUCTURE ILOA
*” REFERENCE(HEQBS_OLD) LIKE EQBS STRUCTURE EQBS
*” REFERENCE(HEQKT_NEW) LIKE EQKT STRUCTURE EQKT
*” REFERENCE(HEQUI_NEW) LIKE EQUI STRUCTURE EQUI
*” REFERENCE(HEQUZ_NEW) LIKE EQUZ STRUCTURE EQUZ
*” REFERENCE(HILOA_NEW) LIKE ILOA STRUCTURE ILOA
*” REFERENCE(HEQBS_NEW) LIKE EQBS STRUCTURE EQBS
*” IHPA_OLD STRUCTURE IHPAVB OPTIONAL
*” IHPA_NEW STRUCTURE IHPAVB OPTIONAL
*Get values from tbd62 under respective Message type.
INTO TABLE lit_bd52
WHERE mestyp EQ ‘ZOTC_EQUI’.
*Compare fields which are changed during current process using field symbols as shown below.
LOOP AT lit_bd52 INTO lwa_bd52.
l_old_struc = ‘HEQKT_OLD’.
l_new_struc = ‘HEQKT_NEW’.
l_old_struc = ‘HEQUI_OLD’.
l_new_struc = ‘HEQUI_NEW’.
l_old_struc = ‘HEQUZ_OLD’.
l_new_struc = ‘HEQUZ_NEW’.
l_old_struc = ‘HILOA_OLD’.
l_new_struc = ‘HILOA_NEW’.
CONCATENATE l_old_struc lwa_bd52–fname INTO l_field_old SEPARATED BY ‘-‘.
ASSIGN (l_field_old) TO <fs_value_old>.
CONCATENATE l_new_struc lwa_bd52–fname INTO l_field_new SEPARATED BY ‘-‘.
ASSIGN (l_field_new) TO <fs_value_new>.
* Compare values obtained in the above variables if there any changes found proceed further to create idoc else just EXIT.
*In the above example Generated Idocs has been implemented so below FMs are to trigger outbound Idoc.
DATA: g_objhnd TYPE swo_objhnd,
it_return TYPE swotreturn,
it_cont TYPE swconttab.
* Instantiate the business object i.e., give it a name and create it
CALL FUNCTION ‘SWO_CREATE’
objtype = ‘ZEQUI’
objname = ‘EQUIPMENTCUSTOM’
object = g_objhnd
no_remote_objects = 1
OTHERS = 2.
* Invoke BO method that will trigger the Outbound Function Module
CALL FUNCTION ‘SWO_INVOKE’
object = g_objhnd
verb = ‘ZCUSTSEGMENT’
return = it_return
container = it_cont.
Advantages of Virtual Change pointer
1. Mainly used when standard change pointer object is not available in SAP.
2. Above technique will trigger Idoc without any schedule job (RBDMIDOC) or BD21 transaction.
3. Improves the performance, as actual change pointer technique is not been implemented.
Very good document on Virtual change pointer 🙂
Does this work for transactional data , or only for changes in master data ?