Update Rules

Definition

Update rules specify how the data (key figures, time characteristics, characteristics) is updated to data targets from the communication structure of an InfoSource. You are therefore connecting an InfoSource with a data target.

Use

An update rule must be specified for each key figure and the corresponding characteristics of the InfoCube. For an ODS Object, it must be specified for the data and key fields, and for an InfoObject it must be specified for the attribute and key fields.

The following update types exist:

...

       1.      No update

       2.      Addition, minimum or maximum

       3.      Overwriting (with ODS objects and InfoObjects only)

A data target can be supplied with data from several InfoSources. A record of update rules must be maintained for each of these InfoSources, describing how the data is written from the communication structure belonging to the InfoSource into the data target.

The InfoObjects of the communication structure belonging to the InfoSource are described in the update as source InfoObjects (meaning source key figure or source characteristic). The InfoObjects for the InfoCube, on the other hand, are described as target InfoObjects (meaning target key figure or target characteristic). Similarly, the InfoObjects of an ODS object/InfoObject are called target InfoObjects (therefore, target data field or target key field).

Structure

There is an update rule for each key figure of the InfoSource. This comprises the rule for the key figure itself and the current rules for characteristics, time characteristics, and units assigned to it.

InfoSource

Definition

In BW, an InfoSource describes the quantity of all the data available for a business transaction or a type of business transaction (for example, cost center accounting).

An InfoSource is a quantity of information that logically belongs together, summarized into a single unit. It prepares consolidated data for updating to the data targets. InfoSources contain either transaction data or master data (attributes, texts and hierarchies).

An InfoSource is always a quantity of InfoObjects that logically belong together in the form of the communication structure.

Use

In BW, a DataSource is assigned to an InfoSource. If fields that logically belong together exist in various source systems, they can be grouped together into a single InfoSource in BW, in which multiple DataSources can be assigned to an InfoSource.

In the BW Processing Transfer Rules, individual DataSource fields are assigned to the corresponding InfoObject of the InfoSource. Here you can also determine how the data for a DataSource can actually be transferred to the InfoSource. The uploaded data is transformed using transfer rules. An extensive library of transformation functions that contain business logic can be used here to perform data cleansing and to make the data analyzable. The rules can be applied in a simple way without code with the use of formulas.

The transfer structure is used to transfer data to the BW system. The data is transferred 1:1 from the transfer structure of the source system into the BW transfer structure.

Integration

If fields that logically belong together exist in various source systems, they can be grouped together into a single InfoSource in BW. The source system release is not important here.

If you are dealing with an InfoSource with flexible updating, then the data is updated from the communication structure into the InfoCube into other data targets with the aid of the Update Rules. InfoSources with direct updating permit master data to be written directly (without update rules) into the master data tables.

InfoSources are listed in the InfoSource tree of the Administrator Workbench under an application component.

Sources systems

Sources systems are all the data feeding pipes to the Staging Area. TYPICALLY any Transformation on the data is done after the data in its raw OR unchanged form is picked from the source systems. The further details of the Source Systems can be Data Warehouse Design & Architecture in Data Warehousing

Core source Systems

These system include the core systems mostly having well organized database, set schedules, the data being updated on online basis. Typical systems are core product manufacturing systems, accounting systems, Money Management systems, commission/Sales Compensation Systems, tightly coupled job/workflow systems.

Field OR Front-end Source Systems

These systems, include the systems, which are primarily used by theCustomer acquisition and retention staff. These include Customer service systems, Sales automation systems, leads management systems, campaign management systems.

Modeling and Analysis systems

This family of systems include budgeting, planning, forecasting, pricing and valuation type of system.

External Data

This is the data, which you receive from regulators, credit bureau, medical bureau, industry associations, market research firms, database marketing companies and other sources. This data (unlike data provided by your suppliers and Customers;which goes into your core OR field systems) follows a standard format generally governed by the supplier.

Non-Data Base/Desk top Sources

Wealth of information and critical operational data resides in the excels and MS access tables in the desktops OR local servers of organization. If you want to shock yourself, just make a study of the number of excel based applications, which have become critical part of operational delivery and reporting. The numbers could go in hundreds, if not in thousands.

Off-line Databases

As no organization data management strategy goes through a systematic & planned growth, it is possible that you might have some offline database used by the users to generate their reports. For the sake of speed, one may tend to use that as a source system. However, in a medium to long run, this may become counter productive because you will make that offline database redundant.

InfoPackage

 Definition

An InfoPackage (active object: ISIP/delivery object :SHIP) is a source-system dependent object that has the GUID as key. There is one object for each source system.

You can find additional information about this BW object under Maintaining an InfoPackage.

Structure

Key Fields of an InfoPackage (ISIP/SHIP)

Version	Key Fields	Data Fields
A (active) / M (modified) / T (Transport) - ISIP	GUID	Source System
D (Delivery /. Content) - SHIP	GUID	Source system release

As the source system does not exist in the key, but is contained within the data part, the InfoPackage objects is also delivered as a shadow table.

Example

The following example aims to show what you need to be aware of when delivering InfoPackages within partner Content.

The Content development system is connected to source system Q1. There is exactly one InfoPackage with GUID1 for this source system.

In the customer system, this InfoPackage is to be activated for several source systems with the same release status:

·        Source system X1, Release 4.0

·        Source system X2, Release 4.0

Accordingly, the InfoPackage is copied into the A version twice. The logic behind this is the same as for transfer rules (see Transfer Rules and DataSource). Conversion is carried out byRSSM_SHIP_PSEUDO_DVERSION_WIR. The copies contains GUID3 and GUID4.

When SAP delivers again, you need to know from which InfoPackage GUID3 and GUID4 are derived. This information is stored in table RSSHIPDVERS:

Table RSSHIPDVERS

LOGDPID_SH	LOGSYS	LOGDPID
GUID3	X1	GUID2
GUID4	X2	GUID2