#FACT,Ī record with a time stamp falling in this time safety interval will be selected twice from the CDS view. If you do not add this annotation, a default delay of 1800 seconds, i.e. You can specify the safety interval using this maxDelayInSeconds This can accommodate technical delays like waiting for a database commit on the application system side.
In case of a real-time delta subscription by a streaming process chain, the real-time daemon checks for new records in the CDS views every 15 seconds by default.įor non-real-time delta subscriptions new records according to the delta criterion are directly pulled from the CDS view during extraction.Īs safeguarding measure, a safety interval can be specified. On a subsequent extraction request, only records with a higher time stamp/date value are extracted. Using this field, the ODP framework determines up to which record a data consumer has extracted records already. The following annotation identifies the relevant time/date field to be used by the ODP framework: #FACT, If no appropriate UTC time stamp is available in the application tables/CDS view, a date field can be used as well. Using a UTC time stamp is the preferred way for delta extraction.
You can use the following field types as delta criterion: The generic delta based on date / timestamp has been around since release SAP S/4HANA 1809 on-premise and relies on a date/time element being present in the CDS view reflecting the changes of the underlying records. Let’s check the two delta mechanisms in detail below, from which you can infer which option suites your data model and logic best.
The good news, the ODP framework for CDS extraction provides delta capabilities. Extraction of transaction data should always be delta enabled as this allows a seamless loading and reporting scenario.
Ibackup extractor safe full#
In most of the cases daily (nightly) full uploads are not what you want, as time windows for data extractions are limited. transaction data like sales orders or similar, the application needs to provide delta records. In cases, in which big data volumes with a frequent changes are expected, e.g. As promised in part one, let’s have a closer look at the delta handling in CDS based extraction.
0 kommentar(er)
