Risks-Compounding 0SOURSYSTEM to more than 150 InfoObjects(Standard & Customised)

[neerajnaik]

Hi Experts,

I have been checking various posts and articles on SDN on compounding of infoobjects and have seen mixed responses on the risks and advantages of compounding multiple infoobjects.

In my current project we are doing a shell conversion of BW on HANA system to BW/4HANA, post which we will be enhancing the existing data model to inculcate/ingest data from multiple ERP (SAP & Non SAP). Currently, we just have one ECC system. We have done the analysis and short listed around 180 InfoObjects(based on current reporting and attributes) from list of 4100 active infoobjects for compounding with 0SOURSYSTEM and 0SOURSYSTEM ID will also be a key in our ADSOs.

The list of 180 InfoObjects still seems too much to compound too. The question is, in the long run is there a potential risk of compounding so many infoobjects in terms of designing and performance?

Thank You.

[marcfbe]

Hi Neeraj,

you are making an assumption here: Do all the ERP systems have the same master data attributes because that's what using one InfoObject means?

Using 0SOURSYSTEM compounding isn't necessarily the best option. Maybe look into using local and corporate InfoObjects like shown in the attachment. image.png. In the example, the "German Cost Center" has the "Corporate Cost Center" as an attribute. Using CompositeProviders you can then join either corporate or local master data (or even several different local master data). It is a much more flexible data model and performs well.

For more, lookup LSA++ in documentation but there are also training courses on this topic.

Best

Marc

[neerajnaik]

Hi Marc,

Thank You for your response. The different customized master data for different system and having corporate master data as an attribute works well when a BW system has few source systems. The solution has a major challenge in wider scenario like ours, where number of source system is greater than 10. The development and tracking effort for source system specific master data object and their respective transactional data targets(ADSOs & CPs) will be very high. In future, if any source system is decommissioned or new source system is added then, there will be heavy lifting work of identifying/creating all relevant dataflows with new nomenclature and also to check their inter-dependencies,look ups if any with any other cross module data flow etc.

[bhavinvyas]

Hi Neeraj,

As per my point of view, During designing you might face some issues like wherever you are using this info objects, its dependent transformations/info providers you need to validate thoroughly whether those are activated or not. Also you need to reload the data for all ADSOs to reflect source system in your transactional data for the existing ECC system. For newly added source system anyhow you will perform fresh loads.

Regarding performance, The extensive use of compounding IO may influence performance for that particular master data. Maximum 13 chars can be added as compounding object. So out to those 180 IOs you can check if there is any heavily compounded objects and plan accordingly.

Tab Page: Compounding

Also for standard IOs, If you are adding source system as compounding then make sure in future no-one activate that standard IO without merge option else it will bring back the original version of IO and remove source system from it. So for those case better to create custom IO similar to standard IO and add source system into it.

Thanks,

Bhavin

[neerajnaik]

Hi Bhavinkumar,

Thank You for your response.

Yes, the checks you have mentioned have been performed. Since, we have a strong gateway process between landscape and BW stacks, the overwriting of standard business content infoobjects 'without merge' can be caught in development system itself.

3 is the maximum number of compounded attributes we have seen so far for an infoobject and since we are aware maximum it can go upto is 13, we are pretty much confident of compounding these infoobjects. However, since we have not seen 180 infoobjects being compounded with 0SOURSYSTEM before, seems like first of its kind, we are being extra cautious to check and plug the gap for any potential issues in future. If anyone has been through same scenario or heard of any such scenario, your esperience and feedback would be greatly appreciated.

Thank You.