Showing results for 
Search instead for 
Did you mean: 

About Delta Process

Former Member
0 Kudos

Dear Consultants,

Happy new year!

About Delta Process , please provide me the good proposals , examples , documents, or link addresses .

Thanks a lot !

Best Regards,


Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Dear Consultants,

Thanks a lot for your high viewpoints and rapid responses.

The points awarded to you !

Thanks a lot & Best Regards


Former Member
0 Kudos


The table RODELTAM defines the properties of the delta process for a DataSource:

• Delta type (explained in detail later)

• Record modes in the delta process (explained in detail later)

• Serialization


The serialization field (RODELTAM-DREQSER) describes to what extent the

sequence of individual data records within a delta process reflects the origination

of these data records in the application. Serialization is above all necessary in

overwriting data targets (DataStore object) to enter changes to data records in the

correct sequence.

The following provides a complete overview of all the possible characteristic


1. No serialization takes place.

2. Serialization required between requests. The data packages within a request

do not need to be serialized.

3. Serialization required at data package level. The data packages in a request

must be serialized too. This is necessary if an extractor can only supply after

images (see record modes) and several records with the same key can be

sent within a request, for example.

Delta Type

The delta type field (RODELTAM-DELTATYPE) is a property of a delta process. It

describes how the delta is staged within a delta process. Two of the most important

characteristic values that are only used in conjunction with SAP source systems

are illustrated in the above graphics.

The following characteristic values are possible:

• ' ': The delta type is not defined.

• 'A': The DataSource determines the delta with ALE update pointers. This

method is used in the main in connection with DataSources for attributes

and texts from SAP source systems. It can also be used to enable generic

DataSources to provide delta figures (providing the underlying master data

table supports this). ALE update pointers for master data have been available

for many years. In the past, they were used to coordinate master data beyond

SAP systems.

• 'D': The SAP application writes delta data records directly to the delta queue

(“PUSH”) for the DataSource. Each data record is either a) stored in the

delta queue individually on saving / updating the corresponding transactions

in the application (for example, FI-AR/AP or direct delta in the LO Cockpit),

or b) written in groups of delta data records (after updating the transaction) to

the delta queue by means of application-specific jobs. In each case, however,

the delta data records are in the delta queue for the SAP source system before

the delta update is executed. In the case of a delta update for the DataSource,

this delta queue is read and the data records that exist there are transferred

to the BI system. This delta type is normally used in applications in which

delta data records cannot be determined through fields or control tables for

the underlying application tables.

• 'E': The DataSource determines the delta through the extractor on request.

This means that the extractor must be capable of providing the delta records

for the DataSource on request (“PULL”). The delta data records that

have been determined are placed in the delta queue by the extractor and

transferred from the there to the requesting BI target system. If you have

carried out delta initializations for more than one BI system, or several delta

initializations for the same BI system, the extractor has to stage delta records

for all the delta initializations and store them in all the delta queues that

are specific to the BI target systems. This delta type is normally used in

applications in which delta data records can be determined through fields or

control tables for the underlying application tables (for example, time stamp

information for each data record).

• ‘F‘: The delta data records are loaded by flat file. This delta type is only used

for DataSources for flat file source systems. Flat files are imported to the

PSA when you execute the InfoPackage. The staging process then begins.

The delta queue is not used here.


The record mode concept deals with the question of how changes to data records

are recorded in the delta process.

The record mode now describes the type of change that a data record contains. The

difference between the various delta processes is that each supports only a subset

of the seven possible characteristic values. If a DataSource implements a delta

process that uses several characteristic values, the field ROCANCEL (in which the

record mode is saved) is automatically part of the DataSource. This field for the

DataSource is assigned to the InfoObject 0RECORDMODE in the BI system.

The characteristic values are as follows:

• ' ': The record provides an after image.

The status of the record is transferred after it has been changed, or after data

has been added. The record can only be directly updated to an InfoCube if

the corresponding before image is in the request (this will be explained later).

• 'X': The record provides a before image.

The status of the record is transferred before it has been changed or deleted.

All attributes for the record that can be aggregated (key figures) must be

transferred with a reversed plus/minus sign. Responsibility for reversing the

plus/minus sign lies either with the extractor (default) or with the service

API. These records are ignored in a non-additive (overwriting) update of a

DataStore object. The before image complements the after image.

• 'A': The record provides an additive image.

With attributes that can be aggregated, only the changes are transferred.

In the case of attributes that cannot be aggregated, the status after data

was changed or created is transferred. The record can be updated to an

InfoCube without restrictions, but requires an additive update to be made

to a DataStore object.

• 'D': The record must be deleted.

Only the key is transferred. This record (and therefore the DataSource too)

can only be updated to a DataStore object.

• 'R': The record provides a reverse image.

The content of this record is equivalent to a before image. The only

difference occurs when updating a DataStore object: An existing record

with the same key is deleted.

• 'N': The record provides a new image.

The content of this record is equivalent to an after image without a before

image. A new image should be transferred instead of an after image when a

record is created. The new image complements the reverse image.

Check this........








Former Member
0 Kudos