After having established a delta process with the Xtract IS DeltaQ component, there are usually only delta updates (update mode D). If a delta update fails, you may use update mode R and fill the Request ID in the setting dialog to repeat a failed delta. If you fail to do so and just execute the next delta update a repetition of the failed delta is not possible anymore as SAP ERP only “remembers” the last delta. This is why we have to design an architecure that suppresses delta updates after a failure and makes sure, that the admin has repaired or repeated the failed delta BEFORE the next delta update takes place. This article shows, how to do that very simply.
The first thing we need is a simple table in SQL server to store so called DeltaBlockers in. We just simply design this table for multiple data sources, so the name of the data source is the primary key and a timestamp as column to store, when the blocker was set.
The second step is done within the control flow. When the data flow (with the delta update in it) fails, an SQL statement is executed to create an entry in the blocker table.
INSERT INTO DeltaBlocker (DataSource, TIMESTAMP) VALUES('0CUSTOMER_ATTR',getdate())
The last step is to set an additional control flow item BEFORE the data flow takes place. The SQL checks the DeltaBlocker table for possible entries and writes the number of found entries into a variable.
The last thing to do is to apply a constraint within the control flow, that makes sure, that the data flow is only executed when the variable is 0.
An that’s it! Now we have created a simple error monitoring. You may create a report on top of the DeltaBlocker table to give an overview of blocked sources. Any suggestions? Just email me at patrick.theobald(at)theobald-software.com.