A to Z of Custom Change Pointer
In this document, I have made an effort to provide the consistently expected details needed to implement custom change pointers for the custom fields in the custom tables for the custom change object and custom message type.
Configurations and Steps to implement custom change pointer:
Step 1. Make the data type of custom fields ready to record changes. (A to Z of Custom Change Pointer)
For demo, I have utilized the beneath custom table with custom fields.
The information components of the multitude of three custom fields have the Change report checked.
Step 2. Create custom message type (T-code WE81). A to Z of Custom Change Pointer
For instance I have made message type Z1P_MATMAS.
Step 3. Activate this message type to catch change pointers (T-code BD50).
Step 4. Create custom Change Document Object to link changes (T-code SCDO).
Put the custom table name (ZTEST_RS for this demo). You can add more than one tables
Step 5. Generate the custom Function Module to update changed documents (T-code SCDO).
Click Produce update pgm button.
Save it.
A new data dictionary structure called YZTEST_RS is also generated, along with an FM Z_MATMAS_WRITE_DOCUMENT to update change pointer. To trace the change pointers, the custom code would call FM Z_MATMAS_WRITE_DOCUMENT.
Step 6. Check the generated FM Z_MATMAS_WRITE_DOCUMENT.
Check the Tables area. Two tables are characterized. One is for information before change and the other is for information after change.
Kindly note: naturally the Tables in the FM are required. Assuming that you added more than one table in the exchange SCDO while creating the FM, you can make these tables as discretionary physically in SE37, so you can involve similar FM for change pointers for various tables.
Step 7. Link the change document Object, Table and Fields for the given Message Type (BD52).
Please take note that although though the field name “KEY” isn’t a field of any table, it should be provided for every table.
Except for the KEY field, the message type is directly referenced to the material expert’s fields and tables. Although it is not necessary for the specific table, this field anticipates a crucial, additional control task. A change pointer is created while creating the corresponding object in Exchange BD52 if the KEY field is identified.
Step 8. Evaluating Change Pointers (T-code BD60).
The change pointers are then assessed. It simply relies upon the article concerned what capability module is utilized here.
The capability module, MASTERIDOC_CREATE_SMD_MATMAS, which utilizations change pointers to produce IDocs is called.
Step 9. Write the custom code in the TMG event to capture changed/created data. (This is not the only way. You can write your code in other suitable areas)
Details to add event is also there in other post: http://help-sap.blogspot.com/search?q=event
In the Generate Table Maintenance screen go to Menu Environment->Modification->Events.
You will see the following screen.
Click the New Entries button and select the event you want to use and the Routine name.
Click the Manager and make your daily practice in the Incorporate program and compose the code in the daily practice to meet your prerequisite.
Sample Code to catch change pointers
FORM z_before_save.
CONSTANTS:
c_insert TYPE cdchngind VALUE ‘I’,
c_update TYPE cdchngind VALUE ‘U’,
c_check TYPE boolean VALUE ‘X’.
DATA: li_ztest_rs_old TYPE STANDARD TABLE OF ztest_rs INITIAL SIZE 0,
li_xztest_rs TYPE STANDARD TABLE OF yztest_rs INITIAL SIZE 0,
li_yztest_rs TYPE STANDARD TABLE OF yztest_rs INITIAL SIZE 0,
li_cdtext TYPE STANDARD TABLE OF cdtxt INITIAL SIZE 0,
lk_ztest_rs_x TYPE ztest_rs,
lk_ztest_rs_old TYPE ztest_rs,
lk_xztest_rs TYPE yztest_rs,
lk_yztest_rs TYPE yztest_rs,
lv_object TYPE cdobjectv.
* Sort
SORT i_ztest_rs_x[] BY zmatnr zplant.
* This will have the most recent data
DELETE ADJACENT DUPLICATES FROM i_ztest_rs_x[] COMPARING zmatnr zplant.
* Initial check
IF i_ztest_rs_x[] IS NOT INITIAL.
* Get old data
SELECT * FROM ztest_rs
INTO TABLE li_ztest_rs_old ” Old Data
FOR ALL ENTRIES IN i_ztest_rs_x
WHERE zmatnr = i_ztest_rs_x-zmatnr
AND zplant = i_ztest_rs_x-zplant.
* Looping through the current data set
LOOP AT i_ztest_rs_x INTO lk_ztest_rs_x.
* Read the old data if available
READ TABLE li_ztest_rs_old INTO lk_ztest_rs_old
WITH KEY zmatnr = lk_ztest_rs_x-zmatnr
zplant = lk_ztest_rs_x-zplant.
IF sy-subrc EQ 0.
* If found then check whether anything is changed or not
IF lk_ztest_rs_x-zmatnr NE lk_ztest_rs_old-zmatnr
OR lk_ztest_rs_x-zplant NE lk_ztest_rs_old-zplant
OR lk_ztest_rs_x-zmaktx NE lk_ztest_rs_old-zmaktx .
MOVE-CORRESPONDING lk_ztest_rs_x TO lk_xztest_rs.
* This is important
lk_xztest_rs-kz = c_update.
* Keep the new data
APPEND lk_xztest_rs TO li_xztest_rs[].
MOVE-CORRESPONDING lk_ztest_rs_old TO lk_yztest_rs.
* This is important
lk_yztest_rs-kz = c_update.
* Keep the old data
APPEND lk_yztest_rs TO li_yztest_rs[].
lv_object = lk_ztest_rs_x-zmatnr.
* Write the change pointer for changed record
CALL FUNCTION ‘Z_MATMAS_WRITE_DOCUMENT’
EXPORTING
objectid = lv_object
tcode = sy-tcode
utime = sy-uzeit
udate = sy-datum
username = sy-uname
upd_ztest_rs = c_update
TABLES
icdtxt_z_matmas = li_cdtext[]
xztest_rs = li_xztest_rs[]
yztest_rs = li_yztest_rs[].
REFRESH: li_cdtext[], li_xztest_rs[], li_yztest_rs[].
CLEAR: lv_object.
ENDIF.
* If not found, that means it is a new entry
ELSE.
MOVE-CORRESPONDING lk_ztest_rs_x TO lk_xztest_rs.
* This is important
lk_xztest_rs-kz = c_insert.
* Keep the new data
APPEND lk_xztest_rs TO li_xztest_rs[].
lv_object = lk_ztest_rs_x-zmatnr.
* Write the change pointer for new record/insert record
CALL FUNCTION ‘Z_MATMAS_WRITE_DOCUMENT’
EXPORTING
objectid = lv_object
tcode = sy-tcode
utime = sy-uzeit
udate = sy-datum
username = sy-uname
upd_ztest_rs = c_insert
TABLES
icdtxt_z_matmas = li_cdtext[]
xztest_rs = li_xztest_rs[]
yztest_rs = li_yztest_rs[].
REFRESH: li_cdtext[], li_xztest_rs[], li_yztest_rs[].
CLEAR: lv_object.
ENDIF.
ENDLOOP.
ENDIF.
ENDFORM. “z_before_save
In order to feed data in the event above, we nee to populate data (I_ZTEST_RS_X[ ]) in the custom database table screen. Write code to keep the run-time table data needed for the above logic.
The changes are logged in the standard table BDCP2. Let us check for any entry in the table for my userid and today’s date
MODULE get_new_or_changed_values INPUT.
* Keep the screen number
CONSTANTS: c_screen_0001 TYPE sydynnr VALUE ‘0001’.
* Get the data and keep in internal table to be used later
IF sy-dynnr = c_screen_0001.
APPEND ztest_rs TO i_ztest_rs_x.
ENDIF.
ENDMODULE.
You might have to pronounce a few worldwide information.
This finishes the design and custom code to get the change recognition.
Sample Output to register change pointers for Create and Change:
The progressions are signed in the standard table BDCP2. Allow us to check for any section in the table for my userid and the present date
No section is found.
Presently I will Make/Add a section in the custom table by t-code SM30 and save it.
Go to table BDCP2 and search for records. Check one passage is effectively logged.
Change a section and really look at the table for the change pointer.
Check another passage has been added.
Transactions to remember
1. SE11 to check the data type is active to record changes and to create events.
2. SE81 to create message type.
3. BD50 to activate the message type to catch change pointers.
4. SCDO to create Change Objects and generate program/function module to write change pointers.
5. BD52 to link Message Type, Change Objects, Tables and Fields.
6. BD60 to link Message Type to Standard Function Module.
Highlight recollect
In exchange BD52, field name ‘KEY’ ought to be given for each table despite the fact that it’s anything but a field of any table.
YOU MAY LIKE THIS
