SAP DataSource in the SAP Source System in BW BI

Definition

Data that logically belongs together is stored in the source system in the form of DataSources.

A DataSource consists of a quantity of fields that are offered for data transfer into BI. The DataSource is technically based on the fields of the extraction structure. By defining a DataSource, these fields can be enhanced as well as hidden (or filtered) for the data transfer.

Additionally, the DataSource describes the properties of the associated extractor with regard to data transfer to BI. Upon replication, the BI-relevant properties of the DataSource are made known in BI.

Integration

DataSources are used for extracting data from an SAP source system and for transferring data into BI. DataSources make the source system data available to BI on request in the form of the (if necessary, filtered and enhanced) extraction structure. In the DataSource maintenance in BI, you determine which fields from the DataSource are actually transferred. Data is transferred in the input layer of BI, the Persistent Staging Area (PSA). In the transformation, you determine what the assignment of fields from the DataSource to InfoObjects from BI should look like. Data transfer processes facilitate the further distribution of the data from the PSA to other targets. The rules that you set in the transformation apply here.

SAP Extraction Structure in BW BI

Definition

In the extraction structure, data from a DataSource is staged in the source system. It contains the amount of fields that are offered by an extractor in the source system for the data loading process.

You can edit DataSource extraction structures in the source system. In particular, you can determine the DataSource fields in which you hide extraction structure fields from the transfer. This means filtering the extraction structure and/or enhancing the DataSource for fields, meaning completing the extraction structure. In transaction SBIW in the source system, choose Business Information Warehouse ® Subsequent Processing of DataSources.

SAP Installing the Business Content DataSource in the Active Version in BW BI

Use

The DataSources delivered by SAP with the BI Content and any DataSources delivered by partners or customers in their own namespace are available in the delivery version (D version) in the SAP source system. If you want to transfer data from an SAP source system to a BI system using a DataSource, you must first copy the data from the D version to the active version (A version) and make it known in the BI system.

You have two options:

● You can copy the DataSource in the SAP source system to the active version and then replicate it.

● You can copy the DataSource remotely from within the BI system to the active version. In this case the replication takes place automatically.

Prerequisites

● The remote activation is subject to an authorization check. Authorization object S_RO_BCTRA is checked. System administration must have assigned you the role SAP_RO_BCTRA in order for you to be able to activate the DataSources (more information: Changing Standard Roles). This authorization applies to all the DataSources in a source system.

● For remote activation, the D versions of the DataSources must exist in the BI system. They are replicated when you connect a source system and when you replicate to the BI system for an application component or a source system.

Procedure

In the SAP Source System

...

1. To transfer and activate a DataSource delivered by SAP with Business Content, in transaction SBIW in the source system choose Business Information Warehouse à Business Content DataSources or Activating SAP Business Content àTransfer Business Content DataSources.

The following figure displays the DataSources in an overview according to the application component.

2. Select the nodes in the application component hierarchy for which you want to transfer DataSources into the active version. Do so by positioning the cursor on the node and choosing Highlight Subtree.

The DataSources lying under the subtree and other subtrees are selected.

3. To check for differences between the active and delivery versions of the DataSources, choose Select Delta.

DataSources for which differences were found in the check (for example, due to changes to the extractor) are highlighted in yellow.

4. To analyze the differences between active and delivered versions of a particular DataSource, select the DataSource and choose Version Comparison. The application log contains further information regarding the version comparison.

5. To transfer a DataSource from the delivery version into the active version, select it in the overview tree using the button Highlight Subtree and choose Transfer DataSources.

If an error occurs, the error log appears.

Regardless of whether data has been successfully transferred into the active version, you can call the log by choosing Display Log.

6. To provide the active version of the DataSource in the connected BI systems and to enable data extraction and transfer, replicate the DataSource(s) with a metadata upload to the BI system.

You can then activate the objects for this source system that depend on the source system in the BI system.

When you activate BI Content DataSources, the system overwrites the active customer version with the SAP version.

You can only search for DataSources or other nodes in expanded nodes.

For information about changing the installed DataSources, see Editing DataSources and Application Components.

Remotely From Within the BI System

DataSources are activated remotely under the given circumstances when BI Content is activated. Information about the general procedure for installing content: Installing BI Content.

In BI, the system collects the DataSources for those objects that are one level (at most) before the selected object. This is sufficient to provide transaction and master data.

For example, if this object is an InfoCube, the following DataSources are collected:

■ DataSources from which the corresponding InfoSource supplies transaction data to the InfoCube (see above graphic)

■ DataSources that contain the original master data of the InfoObjects contained in the InfoCube (characteristics of the InfoProvider as well as their display and navigation attributes). No DataSources are collected for the attributes of these InfoObjects.

When the objects are collected, the system checks the authorizations remotely. If you do not have authorization to activate the DataSource, the system produces a warning.

If you install BI Content in the BI system in the active version, the results of the authorization check are taken from the main store.

If you do not have the necessary authorization, the system produces a warning for the DataSource. Errors are shown for the corresponding source-system-dependent objects (transformations, transfer rules, transfer structure, InfoPackage, process chain, process variant). In this case, you have the option of manually installing the required DataSources in the source system from the BI Content (see above), replicating them in the BI system, and then transferring the corresponding source-system-dependent objects from the BI Content.

If you have the required authorization, the active versions of the DataSources are installed in the source system and replicated in the BI system. The source-system-dependent objects are activated in the BI system.

BI Service API with Release SAP NetWeaver 7.0 (Plug-In Basis 2005.1) in the source system and BI are prerequisite to remote activation. If this prerequisite is not fulfilled, you have to activate DataSources in the source system and replicate them in BI afterwards.

SAP Editing the DataSource in the Source System in BW BI

Use

You can edit DataSources in the source system, using transaction SBIW.

For more information on maintaining DataSources, choose Subsequent Processing of DataSources ® Edit DataSource in transaction SBIW.

SAP Replication of DataSources in BW BI

Use

In the SAP source system, the DataSource is the BI-relevant metaobject that makes source data available in a flat structure for data transfer into BI. In the source system, a DataSource can have the SAP delivery version (D version: Object type R3TR OSOD) or the active version (A version: Object type R3TR OSOA).

The metadata from the SAP source systems is not dependent on the BI metadata. There is no implicit assignment of objects with the same names. In the source system, information is only retained if it is required for data extraction. Replication allows you to make the relevant metadata known in BI so that data can be read more quickly. The assignment of source system objects to BI objects takes place exclusively and centrally in BI.

There are two types of DataSources in BI. A DataSource can exist either as a DataSource (R3TR RSDS) or a 3.x DataSource (R3TR ISFS). Since a DataSource cannot exist simultaneously in both object types in one source system and because these objects are not differentiated in the system, you have to choose which object you want the metadata to be replicated in when you replicate the DataSource.

Integration

Replicated 3.x DataSources can be emulated in the BI in order to prepare migration of the 3.x DataSources into a DataSource. As long as certain prerequisites are fulfilled, a 3.x DataSource can be restored from a migrated DataSource.

For more Information:

Emulation, Migration, and Restoring DataSources

Prerequisites

You have connected the source system to BI correctly.

Features

Depending on your requirements, you can replicate into the BI system either the entire metadata of an SAP source system (application component hierarchy and DataSources), the DataSource of an application component in a source system, or individual DataSources of a source system.

When you create an SAP source system, an automatic replication of the metadata takes place.

Whenever there is a data request, an automatic replication of the DataSource takes place if the DataSource in the source system has changed.

Replication Process Flow

In the first step, the D versions are replicated.

Here, only the DataSource header tables of BI Content DataSources are saved in BI as the D version. Replicating the header tables is a prerequisite for collecting and activating BI Content.

● If SHDS is available for the D-TLOGO object in the BI shadow content, the relevant metadata is replicated in the DataSource (R3TR RSDS).

The replication will only be performed if no A or M version of the other object type R3TR ISFS exists for the DataSource.

● If SHMP (mapping for 3.x DataSource) is available for the D-TLOGO object in the BI shadow content, the relevant metadata is replicated in the 3.x DataSource (R3TR ISFS).

The replication will only be performed if no A or M version of the other object type R3TR RSDS exists for the DataSource.

● If no BI Content exists in the D version for a DataSource (R3TR OSOD) in BI, the D version cannot be replicated because this version is only used in BI for BI Content activation.

In the second step, the A versions are replicated.

DataSources (R3TR RSDS) are saved in the M version in BI with all relevant metadata. In this way, you avoid generating too many DDIC objects unnecessarily as long as the DataSource is not yet being used – that is, as long as a transformation does not yet exist for the DataSource.

3.x DataSources (R3TR ISFS) are saved in BI in the A version with all the relevant metadata.

● As a basic principle, the object type of the A version follows the object type of the D version. If the DataSource already exists in BI in the A or D version, the DataSource is replicated to the existing object.

● If the DataSource does not yet exist in BI, the system performs replication according to the following logic:

...

a. If the DataSource is a hierarchy or export DataSource, this determines the object type for the replication:

■ Hierarchy DataSources are replicated to 3.x DataSources.

■ Export DataSources (8*) are replicated to 3.x DataSources.

b. If there is a D version in BI for a mapping object (R3TR ISMP), the system performs replication to 3.x DataSource (R3TR ISFS).

c. Otherwise, the system asks the user to which object type the DataSource is to be replicated.

Make sure that you replicate the DataSource correctly: For example, if you have modeled the data flow with 3.x objects from BI Content and are thus using update and transfer rules, make sure that you replicate the DataSource to a 3.x DataSource. If you have replicated the DataSource incorrectly, you can no longer use the BI Content data model.

Deleting DataSources During Replication

DataSources are only deleted during replication if you perform replication for an entire source system or for a particular DataSource. When you replicate DataSources for a particular application component, the system does not delete any DataSources because they may have been assigned to another application component in the meantime.

If, during replication, the system determines that the D version of a DataSource in the source system or the associated BI Content (shadow objects of DataSource R3TR SHDS or shadow objects of mapping R3TR SHMP) is not or no longer available in BI, the system automatically deletes the D version in BI.

If, during replication, the system determines that the A version of a DataSource in the source system is not or no longer available, the BI system asks whether you want to delete the DataSource in BI. If you confirm that you want to delete the DataSource, the system also deletes all dependent objects, the PSA, InfoPackage, transformation, data transfer process (where applicable), and, in the case of 3.x DataSource, the mapping and transfer structure – if these exist.

Before confirming that you want to delete the DataSource and related objects, ensure that you are no longer using the objects that will be deleted. If it only temporarily not possible to replicate the DataSource, confirming the deletion prompt may cause relevant objects to be deleted.

Automatic Replication During Data Request

You can use a setting in the InfoPackage maintenance under Extras ® Synchronize Metadata to define that, whenever there is a data request, automatic synchronization of the metadata in BI with the metadata in the source system takes place. If this indicator is set, the DataSource is automatically replicated from the BI upon each data request – that is, if the DataSource has changed in the source system.

This function ensures that requests are not refused in the source system because of the default time stamp comparison even though the DataSource has not really changed.

With replication, a distinction must be made between DataSource types and the types of changes in the source system.

DataSource (R3TR RSDS)

When a request is created in the InfoPackage, the DataSource is refreshed in BI if the DataSource in the source system has a more recent time stamp than the DataSource in BI. In addition, the DataSource is activated in BI (including transfer structure generation in the source system) if it is older than the DataSource in the source system. However, it is only activated if the object status is “active“ after replication.

This is not the case if changes have been made in the source system to the field property (name, length, type) or if a field has been excluded from the transfer (because, for example, the Hide Field indicator is set in the field list of the DataSource or the field property has been changed in the extraction structure). In these cases, the DataSource is deactivated in BI.

If the DataSource is not active after replication, the system produces an error message. The DataSource must be activated manually.

3.x DataSource (R3TR ISFS)

When a request is created in the InfoPackage, the DataSource replicate is refreshed in BI if the DataSource in the source system has a more recent time stamp than the DataSource replicate in BI. In addition, the transfer structure is activated in BI if it is older than the DataSource in the source system. However, it is only activated if the object status is “active“ after replication.

This is not the case if changes have been made in the source system to the field property (name, length, type) or if a field has been excluded from the transfer (because, for example, the Hide Field indicator is set in the field list of the DataSource or the field property has been changed in the extraction structure). In these cases, the transfer structure is deactivated in BI.

If the transfer structure is not active after replication because, for example, a field property has been changed, no transfer structure exists, or the transfer structure has been deactivated because of changes to the data flow, the system produces an error message; the transfer structure has to be activated manually.

Activities

Replication of the Entire Metadata (Application Component Hierarchy and DataSources) of a Source System

● Choose Replicate DataSources in the Data Warehousing Workbench in the source system tree through the source system context menu.

or

● Choose Replicate DataSources in the Data Warehousing Workbench in the DataSource tree through the root node context menu.

Replication of the Application Component Hierarchy of a Source System

Choose Replicate Tree Metadata in the Data Warehousing Workbench in the DataSource tree through the root node context menu.

Replication of the Metadata (DataSources and Possibly Application Components) of an Application Component

Choose Replicate Metadata in the Data Warehousing Workbench in the DataSource tree through an application component context menu.

Replication of a DataSource of a Source System

● Choose Replicate Metadata in the Data Warehousing Workbench in the DataSource tree through a DataSource context menu.

or

● In the initial screen of the DataSource repository (transaction RSDS), select the source system and the DataSource and then choose DataSource ® Replicate DataSource.

Using this function, you can also replicate an individual DataSource that so far did not exist in the BI system. This is not possible in the view for the DataSource tree since a DataSource that has not been replicated so far will not be displayed.

Error Handling

If a DataSource has been replicated into the incorrect object type R3TR RSDS, you can correct the object type by restoring the DataSource in the DataSource repository.

For more information, refer to Restoring 3.x DataSources.

SAP Editing DataSources from SAP Source Systems in BI in BW BI

Use

A DataSource is defined in the SAP source system along with its properties and field list. In DataSource maintenance in BI, you determine which fields of the DataSource are to be transferred to BI. In addition, you can change the properties for extracting data from the DataSource and properties for the DataSource fields.

Prerequisites

You have replicated the DataSource in BI.

Procedure

You are in an object tree in the Data Warehousing Workbench....

1. Select the required DataSource and choose Change.

2. Go to the General tab page.

Select PSA in the CHAR format if you do not want to generate the PSA for the DataSource in a typed structure but with character-type fields of type CHAR exclusively.

Use this option if conversion during loading causes problems, for example, because there is no appropriate conversion routine, or if the source cannot guarantee that data is loaded with the correct data type.

In this case, after you have activated the DataSource you can load data into the PSA and correct it there.

3. Go to the Extraction tab page.

a. Under Adapter, you determine how the data is to be accessed. The options depend on whether the DataSource supports direct access and real-time data acquisition.

b. If you select Number Format Direct Entry, you can specify the character for the thousand separator and the decimal point character that are to be used for the DataSource fields. If a User Master Record has been specified, the system applies the settings of the user who is used when the conversion exit is executed. This is usually the BI background user (see also: User Management).

4. Go to the Fields tab page.

a. Under Transfer, specify the decision-relevant DataSource fields that you want to be available for extraction and transferred to BI.

b. If required, change the setting for the Format of the field.

c. If you choose an External Format, ensure that the output length of the field (external length) is correct. Change the entries, as required.

d. If required, specify a conversion routine that converts data from an external format into an internal format.

e. Under Currency/Unit, change the entries for the referenced currency and unit fields as required.

5. Check, save and activate your DataSource.

Result

When you activate the DataSource, BI generates a PSA table and a transfer program.

You can now create an InfoPackage. You define the selections for the data request in the InfoPackage. The data can be loaded into the entry layer of the BI system, the PSA. Alternatively, you can access the data directly if the DataSource supports direct access and you have defined a VirtualProvider in the data flow.

SAP Using Emulated 3.x DataSources in BW BI

Use

You can display an emulated 3.x DataSource in DataSource maintenance in BI. Changes are not possible in this display. In addition, you can use emulation to create the (new) data flow for a 3.x DataSource with transformations, without having to migrate the existing data flow that is based on the 3.x DataSource.

We recommend that you use emulation before migrating the DataSource in order to model and test the functionality of the data flow with transformations, without changing or deleting the objects of the existing data flow. Note that use of the emulated Data Source in a data flow with transformations has an effect on the evaluation of the settings in the InfoPackage. We therefore recommend that you only use the emulation in a development or test system.

Constraints

An emulated 3.x DataSource does not support real-time data acquisition, using the data transfer process to access data directly, or loading data directly (without using the PSA).

Prerequisites

If you want to use transformations in the modeling of the data flow for the 3.x DataSource, the transfer rules and therefore the transfer structure must be activated for the 3.x DataSource. The PSA table to which the data is written is created when the transfer structure is activated.

Procedure

To display the emulated 3.x DataSource in DataSource maintenance, highlight the 3.x DataSource in the DataSource tree and choose Display from the context menu.

To create a data flow using transformations, highlight the 3.x DataSource in the DataSource tree and choose Create Transformation from the context menu. You also use the transformation to set the target of the data transferred from the PSA.

To permit a data transfer to the PSA and further updating of the data from the PSA to the InfoProvider, select the DataSource 3.x in the DataSource tree and choose Create InfoPackage or Create Data Transfer Process in the context menu. We recommend that you use the processes for data transfer to prepare for the migration of a data flow and not in the production system.

Result

If you defined and tested the data flow with transformations using the emulation, you can migrate the DataSource 3.x after a successful test.

SAP Data Reconciliation in BW BI

Purpose

An important aspect in ensuring the quality of data in BI is the consistency of the data. As a data warehouse, BI integrates and transforms data and stores it so that it is made available for analysis and interpretation. The consistency of the data between the various process steps has to be ensured. Data reconciliation for DataSources allows you to ensure the consistency of data that has been loaded into BI and is available and used productively there. You use the scenarios that are described below to validate the loaded data. Data reconciliation is based on a comparison of the data loaded into BI and the application data in the source system. You can access the data in the source system directly to perform this comparison.

The term productive DataSource is used for DataSources that are used for data transfer in the productive operation of BI. The term data reconciliation DataSource is used for DataSources that are used as a reference for accessing the application data in the source directly and therefore allow you to draw comparisons to the source data.

You can use the process for transaction data. Limitations apply when you use the process for master data because, in this case, you cannot total key figures, for example.

Model

The following figure shows the data model for reconciling application data and loaded data in the data flow with transformation. The data model can also be based on 3.x objects (data flow with transfer rules).

The productive DataSource uses data transfer to deliver the data that is to be validated to BI. The transformation connects the DataSource fields with the InfoObject of a DataStore object that has been created for data reconciliation, by means of a direct assignment. The data reconciliation DataSource allows a VirtualProvider direct access to the application data. In a MultiProvider, the data from the DataStore object is combined with the data that has been read directly. In a query that is defined on the basis of a MultiProvider, the loaded data can be compared with the application data in the source system.

In order to automate data reconciliation, we recommend that you define exceptions in the query that proactively signal that differences exist between the productive data in BI and the reconciliation data in the source. You can use information broadcasting to distribute the results of data reconciliation by e-mail, for example.

Modeling Aspects

Data reconciliation for DataSources allows you to check the integrity of the loaded data by, for example, comparing the totals of a key figure in the DataStore object with the corresponding totals that the VirtualProvider accesses directly in the source system.

In addition, you can use the extractor or extractor error interpretation to identify potential errors in the data processing. This function is available if the data reconciliation DataSource uses a different extraction module to the productive DataSource.

We recommend that you keep the volume of data transferred as small as possible because the data reconciliation DataSource accesses the data in the source system directly. This is best performed using a data reconciliation DataSource delivered by BI Content or a generic DataSource using function modules because this allows you to implement an aggregation logic. For mass data, you generally need to aggregate the data or make appropriate selections during extraction.

The data reconciliation DataSource has to provide selection fields that allow the same set of data to be extracted as the productive DataSource.

Selecting the DataSource for Data Reconciliation

Different DataSources can take on the function of a data reconciliation DataSource. The DataSources that can be used in your data reconciliation scenario are explained below.

BI Content DataSources for Data Reconciliation and Recommendations from BI Content for Data Reconciliation

Use the following process to validate your data:

● If a data reconciliation DataSource is specified for a productive DataSource in the BI Content documentation.

You can see that a DataSource of this type is delivered with BI Content if the documentation in the Technical Data table contains an appropriate entry in row Checkable.

● If the DataSource documentation contains instructions on building a data reconciliation scenario.

Special DataSources for data reconciliation can be delivered in systems that have PI Basis Release 2005.1 or higher or 4.6C source systems PI 2004.1 SP10.

If the BI Content documentation does not include a reference to a delivered data reconciliation scenario, the decision as to which data reconciliation DataSource you use depends on the properties of the data that is to be compared.

Generic DataSource for Database View or InfoSet

Use this process:

● If BI Content does not deliver a data reconciliation DataSource and the documentation for the productive BI Content DataSource does not include instructions on building a data reconciliation scenario.

● If the data that the productive DataSource supplies is made available in a database table or can be extracted using an InfoSet.

● If you can use selections to significantly limit the volume of data that is to be extracted and transferred.

This process is particularly appropriate for calculated key figures.

If you have created a suitable database view or InfoSet, create a corresponding generic DataSource in the source system in transaction SBIW Generic DataSources ® Maintain Generic DataSource.

Generic DataSource for Function Module

Use this process:

● If BI Content does not deliver a data reconciliation DataSource and the documentation for the productive BI Content DataSource does not include instructions on building a data reconciliation scenario.

● If the data is not available in a database table or cannot be extracted using an InfoSet.

● If you can supply equivalent data for data reconciliation, despite the complex extraction logic of the productive DataSource.

You can reproduce a complex extraction logic using a generic DataSource that extracts data using a customer-defined function module. This allows you to stage data that is equivalent to the productive DataSource, without using the same extraction module as the productive DataSource. In addition, you can use aggregation to reduce the volume of data that is to be transferred.

Note that the extraction logic of the data reconciliation DataSource is prone to errors if the extraction logic of the productive DataSource is complex. Errors in the extraction logic of the data reconciliation DataSource lead to errors in the data reconciliation. We recommend that only experienced developers use this scenario.

Productive DataSource with Direct Access

Use this process:

● If none of the processes described above are possible.

● If the productive DataSource allows direct access.

Since the runtime largely depends on the volume of data that has to be read by the database and transferred, the prerequisite for using this process is that you have set meaningful selections in order to keep the volume of data that is to be transferred small.

During data reconciliation, the data loaded into BI by means of delta transfer is compared with the data in the source system that the extractor accesses directly. Because the same extractor is used for loading and direct access, this process does not allow you to identify potential systematic errors in the logic of the extractor. Errors in processing the delta requests can be identified.

Prerequisites for Performing Data Reconciliation

You have to be able to use suitable selections (time intervals, for example) or pre-aggregation to restrict the scope of the data that you are going to compare so that it can be accessed directly by the VirtualProvider.

In addition, you have to ensure that the selection conditions for the productive DataSource and the data reconciliation DataSource filter the same data range.

Process Flow...

1. Create the object model for data reconciliation according to the requirements of your scenario.

2. Load data from the productive DataSource into the DataStore object using suitable selection conditions.

3. Make sure that there is no unloaded data in the delta queue or in the application for the productive DataSource when the check is performed. The application for validating the data is either stopped or the data that is to be reconciled is limited by means of selections (for example, by creating and using time stamps for the data records).

4. Check the data in the query.

5. If you find inconsistencies, proceed as follows:

6. Check whether all the data was loaded from the source system. Load the data that has not yet been loaded into BI, if applicable, and perform reconciliation again.

If the loaded data is not complete, start a repair request.

If the loaded data is complete but not correct, reinitialize the delta or contact SAP.

Example

Information about application-specific scenarios for performing a data reconciliation is available in the How-To-Guide How to… Reconcile Data Between SAP Source Systems and SAP NetWeaver BI in SDN at http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7a5ee147-0501-0010-0a9d-f7abcba36b14.

SAP Delta Process in BW BI

Definition

The delta process is a feature of the extractor and specifies how data is to be transferred. As a DataSource attribute, it specifies how the DataSource data is passed on to the data target. From this you can derive, for example, for which data a DataSource is suited, and how the update and serialization are to be carried out.

Use

The type of delta process affects the update into a data target. When you update data in an ODS object, you need to serialize it so that you can also overwrite it. According to the delta process, the system decides whether it is necessary to serialize by request or by data packet.

Structure

There are various delta processes for SAP source systems:

...

1. Forming deltas with after, before and reverse images that are updated directly in the delta queue; an after image shows the status after the change, a before image the status before the change with a negative sign and the reverse image also shows the negative sign next to the record while indicating it for deletion. This serializes the delta packets. The delta process controls whether adding or overwriting is permitted. In this case, adding and overwriting are permitted. This process supports an update in an ODS object as well as in an InfoCube. (technical name of the delta process in the system): ABR)

2. The extractor delivers additive deltas that are serialized by request. This serialization is necessary since the extractor within a request delivers each key once, and otherwise changes in the non-key fields are not copied over correctly. It only supports the addition of fields. It supports an update in an ODS object as well as in an InfoCube. This delta process is used by LIS DataSources. (technical name of the delta process in the system): ADD)

3. Forming deltas with after image, which are updated directly in the delta queue. This serializes data by packet since the same key can be copied more than once within a request. It does not support the direct update of data in an InfoCube. An ODS object must always be in operation when you update data in an InfoCube. For numeric key figures, for example, this process only supports overwriting and not adding, otherwise incorrect results would come about. It is used in FI-AP/AR for transferring line items, while the variation of the process, where the extractor can also send records with the deletion flag, is used in this capacity in BBP. (technical name of the delta process in the system): AIM/AIMD)

Integration

The field 0RECORDMODE determines whether the records are added to or overwritten. It determines how a record is updated in the delta process: A blank character signifies an after image, ‘X’ a before image, ‘D’ deletes the record and ‘R’ means a reverse image.

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. You can find additional information under InfoSources with Flexible Updating of Flat Files.