Scenario
To load updated transactional data, the DataSource and Transformation do not have to be adapted as the structure of fields stays the same. Instead of updating the file T_COSTCENTER_PLAN.csv, another file is used (T_COSTCENTER_PLAN_UPDATE.csv) which has new and changed records. The same Data Transfer Process is used, but in the definition of the DTP the file T_COSTCENTER_PLAN.csv will be replaced with T_COSTCENTER_PLAN_UPDATE.csv.
The flat file T_COSTCENTER_PLAN_UPDATE.csv includes 6 records. Two plan items, with currency USD, are new. Also notice that two records have been updated with adjusted amounts. We'll see how the delta handling in a Standard DataStore Object is used to update this accordingly in SAP BW/4HANA.
Request Handling with Updated Data in a Standard DataStore Object
Remember the example that was used after activating the first request.
The figure above shows the records in the tables of the Standard DataStore Object after loading and activating the first request. So, the inbound table is empty and the active data table and the change log table show data.
So, what happens if a new request is loaded with the same key (Doc.No.)? Let's see how delta handling is managed.
The figure above shows the tables after loading request 2 with updated data. Document 4711 was changed in the source system (Value has changed from 10 to 30) and loaded with a DTP (Request 2), and the record with Doc. No. 4711 and Value 30 is loaded in the Inbound Table.
On the figure above, request 2 is activated. During the activation, the system detects that the key is already there. According to the Transformation, the Value is defined to be overwritten, so the Active Data and Change Log are updated accordingly. Active Data shows the updated value, the Change Log shows the record modes N (New), X (Before Change) and Empty (After Change), and Request 2 is deleted from the Inbound Table.
The activation run (activating the data in the inbound table so that it can be used) can either be triggered automatically via a process chain, or started manually. Data sorting occurs at the start of the activation run. This process takes place, primarily, according to the semantic key of the DataStore Object (that is, the table with the active data). Next, the data is sorted according to the technical key of the activation queue. This is the same as the upload sequence involving the different data records. The sort sequence guarantees that activation can run in parallel. The number of data records to be activated determines how many activation processes are started. You can set whether the processes are to run in parallel or in series.
You can choose whether changes called up from the load requests are combined in one change log request, or generated for each loaded request. A change log request identifies when the records were activated and moved into the change log from the activation queue. This process is similar to that of a load request identifying when records were loaded. In most cases, this process should happen nightly at a minimum. You can activate request by request or activate many requests together.
The Standard DataStore Object is completely integrated in the staging process. This situation means that data can be loaded into and out of the Standard DataStore Object during the staging process. Using a change log means that all changes are also written and are available as delta uploads for connected data targets.