on 02-05-2009 1:55 AM
Dear Consultants,
Happy new year!
About Delta Process , please provide me the good proposals , examples , documents, or link addresses .
Thanks a lot !
Best Regards,
Ricky
Dear Consultants,
Thanks a lot for your high viewpoints and rapid responses.
The points awarded to you !
Thanks a lot & Best Regards
Ricky
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi.........
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
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
values:
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.
RecordMode
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........
/people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
/people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
/people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
/people/sap.user72/blog/2005/04/19/logistic-cockpit-a-new-deal-overshadowed-by-the-old-fashioned-lis
Regards,
Debjani.......
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Read here:
http://help.sap.com/saphelp_nw04/Helpdata/EN/84/81eb588fc211d4b2c90050da4c74dc/content.htm
http://www.tud.ttu.ee/material/enn/IDU0010/BW_ETL.ppt
/people/swapna.gollakota/blog/2007/12/27/how-does-a-datasource-communicates-delta-with-bw
Generic Delta:
GENERIC EXTARCTIONS:
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/bi/generic%2bextraction
Thanks..
Shambhu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
90 | |
23 | |
11 | |
9 | |
9 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.