Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

SAP BW system can be connected with multiple source systems. Among those source systems SAP ECC is central nerve for BW data source.  Most of BW systems are linked with at least one ECC system. How about linking more than one ECC system with single BW system?

First question – is it possible? Yes it is very much possible.

Second question - what is the best data modeling strategy to follow which minimize complexity in design as well as eliminate data redundancy?

Here I am summarizing a few best data modeling strategy while linking multiple ECC system with one BW system

A. Master Data

To minimize repetition of master data info objects utilize  single (standard or customized) master data info objects. Compound master data info object with source system (0SOURCE_SYSTEM). Due to compounding record from each system will be unique along with combination from source system.

If you are wondering, why Compounding is required? It is required because if same value arrives from both systems then it will through duplication error or even if duplicate handling is enabled at DTP level, it will overwrite existing value with new one. In such case we will have value from one system only.

For Example, if we are getting 0Materail having material number M001 with different attributes from Source system ECC1 and ECC2.

0Material details are as below

0Material Attributes

Source System ECC1

Source System ECC2

Material No

M001

M001

Material type

Semi-Finished

Finished

Merchandise Category

Casual

Formal

Color

Red

Blue

Weight

10

5

In such case if 0Material is not compounded with source system, we will have only one M001 that gets uploaded recently i.e. either from Source system ECC1 or ECC2. To retain M001 from both systems, compounding with source system is required.

 

B. Transaction Data

In case of transaction data any such specific mapping is not required. Best practice is to keep data in separate DSO/info cube from each system.

To create consolidated report utilize multiprovider with DSO/Info cube from both systems.

At query level as per need restrict source system in restricted key figures.

C. Process chain

Since Master data info objects are same, so we need to upload data from each system in sequence to avoid lock situation.

Transaction data have no impact because source system and target providers are different.

D. A few more frequently asked questions

- Delta Handling

No impacts on delta load and delta pointer since source systems are different.

- Data Load Performance

Data load performance will not have much impact if process chain to upload data from each system organized efficiently to avoid dead locks.

- Reporting

We can create reports as per need either from single system or consolidated one inclusive of each system. It will be more flexible. To optimize performance restrict info provider wherever possible.

- Data Volume

It is based on transaction data in each system.

Please note above list is not exhaustive. It can be adopted as per requirement and specification.

Hope it will help.

Thanks.

13 Comments
Labels in this area