Beautiful Program to delete DTPs (Data Transfer Processes)

When you got burned to deal with some bogey DTP issues, after you've tried everything to activate it, deactivate it, delete it, still no success? Don't given up. Here's your new best friend.

Try this program RSBKDTPDELETE. Work like a charm. Only thing is it doesn't generate transport request, you need to run this program in Development, QA and Production systems separately.

Hope it helps.

Find CTM Profiles from a particular Process Chain

Copy process chain technical name: BRAZIL_HYB_NET_UNC_SUM



Go to table: RSPCCHAIN, give process chain technical name, then copy all the Process Variants.

Then go to table: RSPCVARIANT, paste all the process variants, then use the "SCM_CTM01" as the Type, execute to get all CTM profiles

Create Creating VirtualProviders

Source: https://cw.sdn.sap.com/cw/docs/DOC-15722

Virtual InfoProvider can be used to read real time data from Livecache without acutally saving data to database.

Prerequisites

If you are using a DataSource as the source for a VirtualProvider, you have to allow direct access to this DataSource.

Procedure

...

1. In the Data Warehousing Workbench under Modeling, choose the InfoProvider tree.

2. In the context menu, choose Create VirtualProvider.

3. As the type, select VirtualProvider based on data transfer process for direct access.

In terms of compatibility, a VirtualProvider that is based on a data transfer process with direct access can also be connected to an SAP source system using a 3.x InfoSource. See Creating VirtualProvider Based on 3.x InfoSources.

The Unique Source System Assignment indicator controls whether this source system assignment needs to be unique. If the indicator is set, you can select a maximum of one source system in the assignment dialog. If the indicator is not set, you can select multiple source systems. In this case, the VirtualProvider acts like a MultiProvider.

If the indicator is not set, characteristic 0LOGSYS is automatically added to the VirtualProvider when it is created. In the query, this characteristic allows you to select the source system dynamically: In each navigation step, the system only requests data from the assigned source systems whose logical system name fulfills the selection condition for characteristic 0LOGSYS.

4. Define the VirtualProvider by transferring the required InfoObjects. Activate the VirtualProvider.

5. In the context menu of the VirtualProvider, select Create Transformation. Define the transformation rules and activate them.

6. In the context menu of the VirtualProvider, select Create Data Transfer Process. DTP for Direct Access is the default value for the DTP type. Select the source for the VirtualProvider. Activate the data transfer process. See Creating Data Transfer Process for Direct Access s.

7. Activate direct access. In the context menu of the VirtualProvider, select Activate Direct Access. In the dialog box that appears, choose one or more data transfer processes and select Save Assignments.

Result

The VirtualProvider can be used for analysis and reporting in the same way as any other InfoProvider.

ODS Object

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.

It describes a consolidated dataset from one or more InfoSources. This dataset 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

There are different ODS object types. Before you can begin with modeling, you need to consider how the ODS object needs to be set. Accordingly, select your ODS object type.

The following ODS objects can be differentiated:

1. Standard ODS object: There are three different types of applications:

• Inbound ODS object: The data is saved in the same form as they are when delivered from the source system. This ODS type can be used to report 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.

2. Transactional ODS object. The data is immediately available here for reporting. For implementation, compare with the
Transactional ODS Object.

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: For updating delta 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.

Data can be loaded from several source systems at the same time. The queueing mechanism allows parallel insertion. The key allows records to be labeled consistently in the activation queue.

The data is loaded into the change log via the activation queue and reaches the active data table when activated. From here, it is made available for reporting. During activation, the requests are sorted according to their logical keys. This ensures that the data is updated in the active data table in the correct request sequence.

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. 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.