Change docu in ABAP (SCDO)

 

 

CHANGE DOCUMENT

 

Change document helps in keeping track the changes made in a commercial object.

 

A change document object definition contains the tables which represent a commercial object in the system.

 

The name under which a change document object is created is an object class.

 

E.g.: We have a Z application where, on save, a user creates a material and stores it in MARA table and creates n entries in MAKT table for that material in different languages. We need to track the database level changes, every time the user clicks on SAVE button in the Z application.

 

Procedure:

 

Go to SCD0 transaction to create or view your change document objects.

 

To create a new object, click on create and give a name to your object.

The name under which a change document object is created is an object class.

 

 

 

 

Click on Yes to continue to create the change document.

 

 

Once you have stored your change object in your request, you will get the following screen where you need to maintain the tables for which you want your database changes to be recorded.

 

For each table, you need to mention if it needs to be copied as an internal table or not. Usually, if you want to record a header table update, you keep it as a single case update. Here MARA is taken as header table (single case- change data are passed in a work area), and MAKT is taken as detail table (multiple case- data are to be passed in an internal table)

 

If you want separate log entries for each field when data are deleted, mark this field. If it is not marked, the deletion of all relevant fields is entered in one document item.

 

If the currency and unit fields are defined in a reference table, rather than in the table passed, you must pass the name of the reference table, and the field referred to, to the function module. In the individual case, the reference information is passed in the form of two extra work areas (old, new). In the collective case, the internal tables are extended to include the reference structure.

 

Only possible for single case, Name of the old field string is mentioned when passing change data in a work area: If you do not want to use the * work area, enter an alternative work area name here.

 

 

 

Choose Insert Entries

 

 

Save and go back to the previous screen.

 

On save, you can see that the data elements of all the fields of the dictionary are set as change document = ‘X’ indicating that the changes will be logged by the corresponding change document.

 

 

 

 

 

Now, Position the cursor on the change document object (SCDO screen) that you just created and choose the menu option Generate update pgm. A dialog box, in which you must make the following entries, is displayed:

 

 

 

• Enter the name of the function group to which the change document update program is to belong. If this function group does not yet exist in the system, it is automatically created during generation. Exactly one function group must belong to each change document object. Other function modules may not be assigned to this function group.
• Enter the prefix (Y/Z) that you want to attach to the change document structures that will be created. Multiple-case table transfer structures are created at generation. Their names are constructed from this prefix and the name of the multiple case tables. A value is proposed. An update-compatible function parameter must not be longer than 28 characters, so the prefix and the longest table name must not be longer than 28 characters together.
• The application-specific error messages generated are stored under this message ID (work area). A value is proposed.
• Number with which errors occurring in connection with this change document object can be identified in the system. A value is proposed.
• Select the type of processing that you want for the update function module that will be created.(immediate update / delayed update / dialog )
• Special text handling flag is used to log long text changes. The old and new status of long texts is not logged. Only the fact that they have been changed is noted.

 

Click on Generate. You get the following log.

FZMARACDT: INCLUDE program part with FORM statement for calling the object-specific update program.

FZMARACDF: INCLUDE program part with data definitions which are the same for all change document objects.

FZMARACDV: INCLUDE program part with data definitions, which are specific to the change document object.

ZMARA_WRITE_DOCUMENT is an update function module created with the object-specific program code.

YMARA: structure created for MAKT (as shown)

 

Click on save.

When the user clicks on Save in the Z application to save the material entries, call the function module ZMARA_WRITE_DOCUMENT after the save code has been written, in update mode.

The importing parameters in the function module signify the following:

• OBJECTID- Object value (key) of the object e.g.: MATNR
• TCODE - Transaction, with which the change was made (create/change)
• UTIME - Change time
• UDATE - Change date
• USERNAME- Changed by

Object-specific data

These are the fields which are defined in the INCLUDE program part FZMARACDV.

Single case tables:

• O_MARA contains the original data.
• N_MARA The table header record must contain the new data.
• Table *<ref. table name>
  (only if ref. tab. name was specified when the change document object was defined)
  The table header record must contain the original currencies and units.
• UPD_MARA : With this flag, you specify the processing logic.
  The following values are possible:
• "D" (DELETE)
  A change document item is to be created for the record in *<table name> or <old record fields name> which is to be flagged as deleted. <table name> is not processed.
• "I" (INSERT)
  A change document item is to be created for the record in <table name > which is to be flagged as created. *<table name > or <old record fields name > is not processed.
• "U" (UPDATE)
  *<table name > or <old record fields name > and <table name > are compared and a change document item is created for each changed field. The keys of *<table name > or <old record fields name > and <table name > must be identical.
• " " (space, no processing)
  *<table name > or <old record fields name > and <table name > are not processed by the update program. (If no changes have been made, the processing can be skipped to save time.)

Multiple case tables:

• YMAKT

The table must contain the original version of the changed or deleted records. The structure consists of the table, as specified in the change document object definition under table name, a processing flag (TYPE C, length 1) and possibly the structure of the associated currency and units table, as specified in the definition of the change document object under Ref. table name. It is created during the change document object INCLUDE generation and saved under the name V<table name > in the Dictionary.

The processing flag can be switched from space to "D", if it is to be processed in the application. Otherwise it has no effect.

• XMAKT

The table must contain the current version of the changed or created records. The structure is the same as Y<table name > (see above).
The following values are possible for the processing flag:

• "I" (INSERT)
  Records were created, or table records were deleted, then a record with the same key was created in the same transaction, and this is to be documented as "Delete" and "Create" (special case), not as "Change".
• "U" or " " (space) (UPDATE)

The parameter UPD_<table name > (see below) initially determines whether the record is new or changed. The processing flag is only checked when, with the parameter value "U", the following key comparison between the two tables TABLE_OLD and TABLE_NEW finds two records with the same key.

Multiple case internal table processing flags can always contain space, with the exception of the special case (in X<table name >). The possibility of setting the processing flag to "D", "I" or "U" as well was created so that the tables could also be used for other purposes in which such processing flags are useful, in application programs.

• UPD_MAKT

With this flag you determine the processing logic.
The following values are possible:

• " D " (DELETE)
  A change document item is to be created for each record in Y<table name > which is to be flagged as deleted. X<table name> is not processed.
• "I" (INSERT)
  A change document item is to be created for each record in X<table name> which is to be flagged as created. Y<table name> is not processed.
• "U" (UPDATE)
  The keys of TABLE_OLD and TABLE_NEW are compared. The following cases are distinguished:
• 1. Record exists in TABLE_OLD but not in TABLE_NEW: Change document items are to be created for the record in TABLE_OLD which is to be deleted.
• 2. Record exists in TABLE_NEW but not in TABLE_OLD: A change document item is to be created for the records in TABLE_NEW which are to be flagged as created.
• 3. Record exists in both TABLE_OLD and TABLE_NEW: A change document item is created for each changed field which is defined as change document-relevant in the Dictionary.
• " " (space, no processing)
  Y<table name> and X<table name > are not processed by the update program. (If no changes have been made, the processing can be skipped to save time.)

Text changes:

If text changes are to be logged (according to the change document object definition), the following fields are to be completed:

• ICDTXT_ZMARA

This structure contains the change document-relevant texts with corresponding details:

• TEILOBJID
  Key of the changed table record
• TEXTART
  Text type of the changed texts
• TEXTSPR
  Language key
• UPDKZ
  Change flag for the table record: D(elete), I(nsert) or U(pdate)

• UPD_ICDTXT_ZMARA
  Change flag for the text table:
• " " (space) Table is ignored by the update program
• "U" Table is taken into account by the update program

 

 

 

 

The function modules in function group SCD0 create object specific update change documents. These function modules are called, in the right order, by the object-specifically generated update program, as soon as it is called. They are generally not required for application developments. Only in exceptional cases, in which an individual update is to be programmed, should the change document creation be programmed by the user with these function modules.

• CHANGEDOCUMENT_OPEN
  This function module is required by every change document creation. It initializes the internal fields for a particular change document object ID.

• CHANGEDOCUMENT_MULTIPLE_CASE
  This function module creates change document items. The change data are passed in tables.

• CHANGEDOCUMENT_SINGLE_CASE
  This function module creates change document items. The change data are passed in a work area.

• CHANGEDOCUMENT_TEXT_CASE
  Change document-relevant texts are passed in a structure with this function module.

• CHANGEDOCUMENT_CLOSE
  This function module is required for every change document creation. It writes the change document header for a particular change document ID, and closes the document creation.

• CHANGEDOCUMENT_PREPARE_TABLES
  With this function module, you compare the records in two tables, which you pass as TABLE_OLD and TABLE_NEW.
  You can specify via a parameter, whether these internal tables should be prepared for the multiple case. Identical records are then deleted, and a processing flag is set in changed records.

 

The function modules in the group SCD1 are used to read the change documents

• CHANGEDOCUMENT_READ_HEADERS
  This function module reads the change document numbers, with the associated header information, for a particular change document object. The search can be restricted by various parameters (changed by, date, time).
  You can use this function module in the database and in the archive.

• CHANGEDOCUMENT_READ_POSITIONS
  This function module reads the change document items for a given change document object number, and formats the old and new values according to their type.
  You can use this function module in the database and in the archive.

• CHANGEDOCUMENT_PREPARE_POS
  You format a previously read change document item for printing with this function module.

 

The function modules in the function group SCD2 are used to process change document objects by classes.

• CHANGEDOCUMENT_READ
  With this function module, you read change document headers and the associated items for a given object class and format the old and new values according to their type. The search can be restricted by various parameters (changed by, date, time).
  You can use this function module in the database and in the archive.

The function modules in SCD3 function group is used for finding planned changes

• PLANNED_CHANGES_READ_HEADERS
  With this function module, you find the document headers of planned changes for a given change document object. The search can be restricted by various parameters (changed by, date, time, change number).
• PLANNED_CHANGES_READ_POSITIONS
  This function module reads the change document items for a given change document number, and formats the old and new values according to their type.

With the function modules in SCD4 function group, you delete log entries of changes or planned changes.

• CHANGEDOCUMENT_DELETE
  This function module deletes the change documents for a given change document object. The deletion can be restricted to a given change document number and/or a change date.
  An authorization check is made before the deletion.

• PLANNED_CHANGES_DELETE
  With this function module, you delete planned changes. The deletion can be restricted to a given change document object, a change document number, or specified change numbers.

The function module in function group SCD5 is the archiving class for the change document

• CHANGEDOCU_ARCHIVE_OBJECT
  With this function module, you pass the objects for which change documents are to be archived, to the archiving.

 

The tables CDHDR and CDPOS are the header and detail tables in which the data changes are recorded.