Functionality of DSO

Question

Hi Folks,
Could you please send me the links of the general basic functionality of DSO? All relevant information about DSO.
Regards,
Geeta.

Answer 1

Hi,
SAP Notes:
ODS Object
Definition
An ODS object acts as a storage location for consolidated and cleaned-up transaction data (transaction data or master data, for example) on the document (atomic) level.
This data can be evaluated using a BEx query.
An ODS object contains key fields (for example, document number/item) and data fields that can also contain character fields (for example, order status, customer) as key figures. The data from an ODS object can be updated with a delta update into InfoCubes and/or other ODS objects or master data tables (attributes or texts) in the same system or across different systems.
Unlike multi-dimensional data storage using InfoCubes, the data in ODS objects is stored in transparent, flat database tables. Fact tables or dimension tables are not created.
The cumulative update of key figures is supported for ODS objects, just as it is with InfoCubes, but with ODS objects it is also possible to overwrite data fields. This is particularly important with document-related structures, since changes made to documents in the source system do not apply solely to numeric fields such as order quantity, but also to non-numeric fields such as goods receiver, status, and delivery date. To map these changes in the BW ODS objects, the relevant fields in the ODS objects must also be overwritten and set to the current value. Furthermore, a source can be made delta-capable by overwriting it and using the existing change log. This means that the delta that, for example, is further updated in the InfoCubes, is calculated from two, successive after-images.
Use
Before you can begin with modeling, you need to consider how the ODS object needs to be set. Accordingly, select your ODS object type and the implementation variant.
The following ODS objects can be differentiated:
1. Standard ODS Object
2. Transactional ODS object: The data is immediately available here for reporting. For implementation, compare with the Transactional ODS Object.
The following implementation variants are conceivable for standard ODS objects:
· ODS object with source-system oriented data: Here the data is saved in the form it is delivered from the DataSource of the source system. This ODS type can be used to report on the original data as it comes from the source system. It serves to handle administration more comfortably and to selectively update.
· Consistent ODS object: Data is stored here in granular form and consolidated. This consolidated data on a document level creates the basis for further processing in BW. To do this, compare level one of the Implementation Scenarios
· Application-related ODS object: The data is combined here according to the business-related problem and can be used specifically as a basis for operative reporting problems. You can report directly for these ODS objects, or you can continue to update them in InfoCubes. To do this, compare level two of the Implementation Scenarios.
Structure
Every ODS object is represented on the database by three transparent tables:
Active data: A table containing the active data (A table)
Activation queue: For saving ODS data records that are to be updated but that have not yet been activated. The data is deleted after the records have been activated.
Change log: Contains the change history for delta updating from the ODS Object into other data targets, such as ODS Objects or InfoCubes for example.
An exception is the transactional ODS object, which is only made up of the active data table.
The tables containing active data are constructed according to the ODS object definition, meaning that key fields and data fields are specified when the ODS object is defined. Activation queue and change log are the same in the table’s structure. They have the request ID, package ID and the record number as a key.
This graphic shows how the various tables for the ODS object work together during data loading.
Data can be loaded performantly from several source systems simultaneously because a queuing mechanism enables parallel inserting. The key allows records to be labeled consistently in the activation queue.
The data get into the change log via the activation queue and is written to the table for active data upon activation. During activation, the requests are sorted according to their logical keys. This ensures that the data is updated in the correct request sequence in the table for active data.
See also the Example of Updating Data to an ODS Object
Integration
Integration with data flow
The diagram below shows the data flow in BW, enhanced with ODS objects. The data flow consists of three steps:
1. Loading the data from the DataSource into the PSA.
In this step, the data from a source system DataSource is loaded and stored in the transfer structure format. The PSA is the input storage location for BW. DataSources with the IDoc transfer method are not supported with ODS objects.
2. Updating the data into the ODS object, and activating the data
¡ Updating the data into the ODS object using transfer and update rules.
The transfer rules transform and clean up the data from the PSA. Generally, the update rules are only used here for one-to-one transfer into the ODS object. This is because transformation has already taken place in the transfer rules. The data arrives in the activation queue.
¡ Activating the data in the ODS object.
When you activate the data, the data necessary for a delta update is sent to the change log. The data arrives in the table of active data.
3. Updating the data from the ODS object
¡ Updating the data in the related data targets such as InfoCubes or ODS objects, for example.
In this step, the system uses the update rules to update the data that has not yet been processed in the change log (the delta) into InfoCubes, other ODS objects, or master data tables. Only update rules are used here, because the data is already available in a cleansed and consolidated format.
¡ Transferring the data from an ODS object into other BW systems.
In this step, it is possible to use the data mart interface to load data from one BW into another BW. In the BW source system, the corresponding ODS object acts as a DataSource that the BW target system recognizes as a DataSource replica, through the metadata comparison. The BW target system is now able to request data from the source system, just as it does with every other DataSource. The requested data is stored in the input storage PSA for further processing, such as updating into InfoCubes, for example.
Integration with the Administrator Workbench - Modeling
Metadata
The ODS objects are fully integrated with BW metadata. They are transported just like InfoCubes, and installed from Business Content (for more information, see Installing Business Contentsapurl_link_0004_0005_0008). The ODS objects are grouped with the InfoCubes in the InfoProvider view of the Administrator Workbench - Modeling, and are displayed in a tree. They also appear in the data flow display.
Update
The update rules define the rules that are used to write to an ODS object. They are very similar to the update rules for InfoCubes. The most important difference is how the Data Fields Are Updated. When you update requests in an ODS object, you have an overwrite option as well as an addition option.
The Delta Process , which is defined for the DataSource, also influences the update. When you are loading flat files, you have to select a suitable delta process from the transfer structure maintenance, this ensures that you use the correct type of update.
Unit fields and currency fields operate just like normal key figures, meaning that they must be explicitly filled using a rule.
Scheduling and Monitoring
The processes for scheduling InfoPackages for updating into InfoCubes and ODS objects are identical. Error handling is an exception here. It cannot be used with ODS objects.
It is also possible to schedule the activation of ODS object data and the update from the ODS object into the related InfoCubes or ODS objects.
The individual steps, including the ODS object processing, are logged in the Monitor. Logs detailing the activation of the new records from the existing request in the ODS object, are also stored in the Monitor.
Loadable DataSources
In full-update mode, every transactional DataSource contained in an ODS object is updated. In delta-update mode, only those DataSources that are flagged as ODS-delta compatible are updated.
In ODS there are three types of tables available
1.New table
2.Active table
3.Change log Table
When a new data is entered in to the ODS it is get in to the New data Table, And if u activate the ODS these data will be move to Active table. If there is is any Change occurs in the data based on the key fiels this modification and chages can be entered in the Change log table....and those can categorized based on the Record mode
ODS have 3 tables .
New Table
Change Log table
Active Table.
New Table :
When ever a new data comes from source system through scheduing , It will be in the new data table . Do the scheduling , You will get the status in Monitor as Red Green circle . This means that new table is having data . To view data in new table , Just Rt click the ODS -> Manage -> Requests , You select the table as new and extecute .
Active Table .
To make the data to reach the data target , You activate the ODS , So that data from new is moved to Active table . Then the status will become green. Now the data in the new table will be deleted . The active and change log will have entries .
Change Log table :
This table will keed the entries to do the change log processing such as Before Image , After Image Etc..
You need to use a ODS when you have to maintain the data inside BW but in a trasactional way.
The ODS works like a R3 table and maintain the data in that way.ODS doesn not cumulate data as a cube and only maintain certain fields as primary key (like R3 tables).In that way it works as a table and could be the source for an infocube...
Normally tha data in ODS is trasnferred to an infocube in order to report it through a BEX Query.
Also, normally, time characteristics form part of the ODS Key as well.
If you create a Generic Extractor from a Table or View, it's even easier. Just use as your ODS Key the same Key fields you have in your Table or View.
Always analyze the specific case and make this question "What Characteristics combination makes each record unique?" The answer is your key.
Check the following links for details.
http://help.sap.com/saphelp_nw70/helpdata/en/a8/6b023b6069d22ee10000000a11402f/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/F9/45503C242B4A67E10000000A114084/content.htm
Key fileds are like Primary keys -- Chars are placed
Data fields --> Key figures and Chars
it is because ODS follows Overwrite property for keyfigures based on the combination of keyfields..so make sure on what level of detail you want the data and select your keyfields based on that.
ODS and Cube differences
*Hope info is useful*
Regards
CSM Reddy
CSM Reddy