
RAP - Implement Change Documents (native)
If you have the appropriate release, you can now implement change documents natively in RAP without much manual implementation. Let's look at the different steps.
Table of contents
In this article, we'll look at the native implementation of change documents in RAP and how to activate the feature in the appropriate release.
Introduction
We already demonstrated a manual implementation of change documents in another article. Therefore, in this article, we want to make further adjustments to our Sales App and have the change documents generated automatically. For this, we will use the currently built-in RAP capabilities.
Preparation
To avoid manually writing the documents, we will comment out the logic in the extended save method. To do this, we simply disable the calls to the various methods within the SAVE_MODIFIED method. We had implemented this method for manual change documents and modified it in the last article to move the code out of the way. Therefore, commenting it out is relatively easy, as only the three different method calls need to be disabled.
METHOD save_modified.
TRY.
DATA(helper) = NEW zcl_bs_demo_rap_auxiliary( ).
* helper->change_document_for_create( create ).
* helper->change_document_for_update( update ).
* helper->change_document_for_delete( delete ).
CATCH cx_chdo_write_error INTO DATA(error).
RAISE SHORTDUMP error.
ENDTRY.
ENDMETHOD.
Implementation
The new implementation of change documentation is now defined in the behavior definition. There are new keywords we can use. You can find more information about the keywords and examples from the standard in the documentation at the bottom of the article.
Activation
We already activated change documentation for data elements in the first parts of this series. If you are building a data model, for example based on Table Entities, you can also work with Simple Types. There is a separate annotation for this to activate change tracking, as there is no corresponding flag in a graphical editor. You activate change tracking via the following annotation:
@AbapCatalog.typeSpec.changeDocumentRelevant: true
Under the "typeSpec" section, you can also configure further settings, such as the conversion exit or the output length.
Behavior Definition (Activation)
To activate the change documents, we need to go to the behavior definition. There, we add the suffix CHANGEDOCUMENTS MASTER to the main entity. There are several attributes we can maintain; you can find more information in the documentation. In this case, we set the mapping to UTC so that the generated entries are saved in UTC time. After that, we specify the actual change object, which we created in the first article. The definition of the entity SASale now looks like this.
define behavior for ZBS_R_SASALE alias SASale
persistent table zbs_sasale
...
authorization master ( global )
with additional save
changedocuments master utc ( ZBS_CO_SALES )
We now need to do the same for all dependent entities. Here, however, we don't use the Master entity, but rather CHANGEDOCUMENTS DEPENDENT to reference our root entity, where we defined the actual change document.
define behavior for ZBS_R_SASELLER alias SASeller
persistent table zbs_saseller
...
authorization dependent by _SASale
with additional save
changedocuments dependent by _SASale
Behavior Definition (Logging)
Now that we have activated change documentation for the individual entities, we need to define the corresponding properties for the various CRUD operations in the behavior definition. The keyword CHANGEDOCUMENTS is used for this purpose. The properties for Create, Update, and Delete are maintained there. The logging mode is specified after each operation. In this case, three different options are available: None, Data, and Key.
changedocuments ( create : data, update : data, delete : key );
Here you will find an explanation of the different values:
- None - None means that no logging takes place for this operation.
- Key - With Key, only the corresponding key is logged.
- Data - And with Data, all data and fields intended for change are logged.
Display
In principle, we can still display the data via the reusable ABAP API. SAP also delivers a Core Data Service, I_ChangeDocument_2, which we can use to view the change documents or integrate them directly into our application. In this case, we use the Core Data Service to enrich our data model and later make the changes visible in the UI. You can find further details about the views and how best to implement them in the official SAP documentation for the RAP implementation.
Hint: The current implementation in the ABAP environment unfortunately does not yet work. An error message appears when we implement the CDS view in our root view. ADT and the IDE are reporting a missing view release, even though it is actually released.
Test
Finally, we test the new implementation. Since we commented out our previous manual logic, the new logic must now take over. To do this, we go into our application, create a new record, modify it, and then delete it. For the test, we run our class ZCL_BS_DEMO_RAP_SALES_CHANGE again and receive all of today's changes. Here we see that the various records were created correctly. We then changed the partner and the currency amount, precisely where the update flag (U) is set. Finally, we deleted the entire dataset. The changes were automatically applied by the system without any manual implementation on our part. Therefore, this approach is highly recommended, as it is significantly faster and less error-prone than manual implementation.
Complete Example
You can find the complete example in GitHub in the corresponding package for the Sales App. The changes from this article can be found in this Commit and you can thus understand the changes, plus the additional information.
Conclusion
With the appropriate release, the change documents are easily integrated into the application. You should therefore take a detailed look at how to configure the various settings.
Source:
SAP Help - Enable Change Document Integration
ABAP Doc - Changedocument
ABAP Doc - Changedocument (Options)
