Virtual Change Pointer Technique

[former_member229765]

Introduction

     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.

Prerequisites

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

Assumption:

     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.

Step1:

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.

Step2:

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.

Step3:

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.

Step4:

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.

*"*"Local Interface:
*"  IMPORTING
*"     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
*"  TABLES
*"      IHPA_OLD STRUCTURE  IHPAVB OPTIONAL
*"      IHPA_NEW STRUCTURE  IHPAVB OPTIONAL

*””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””  

*Get values from tbd62 under respective Message type.

     SELECT tabname
            fldname
       FROM tbd62
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.

    CLEAR: l_old_struc,l_new_struc,l_field_old,l_field_new.
    CASE lwa_bd52-tname.
    WHEN 'EQKT'.
     l_old_struc = 'HEQKT_OLD'.
     l_new_struc = 'HEQKT_NEW'.
    WHEN 'EQUI'.
     l_old_struc = 'HEQUI_OLD'.
     l_new_struc = 'HEQUI_NEW'.
    WHEN 'EQUZ'.
     l_old_struc = 'HEQUZ_OLD'.
     l_new_struc = 'HEQUZ_NEW'.
    WHEN 'ILOA'.
     l_old_struc = 'HILOA_OLD'.
     l_new_struc = 'HILOA_NEW'.
    ENDCASE.

    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.

  ENDLOOP.

*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'
       EXPORTING
        objtype           = 'ZEQUI'
        objname           = 'EQUIPMENTCUSTOM'
       IMPORTING
        object            = g_objhnd
       EXCEPTIONS
        no_remote_objects = 1
        OTHERS            = 2.

* Invoke BO method that will trigger the Outbound Function Module
       CALL FUNCTION 'SWO_INVOKE'
        EXPORTING
         object    = g_objhnd
         verb      = 'ZCUSTSEGMENT'
        IMPORTING
         return    = it_return
        TABLES
         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.