cancel
Showing results for 
Search instead for 
Did you mean: 

ECC6 and PI integration design question

Former Member
0 Kudos

Hello experts,

We have a customer that is going for ECC6 and going to use PI to integrate with external systems. We are designing the way to design the logic for distributing materials so two options are on the desk and I wanted to ask which one you consider the best one and also if you can mention some documentation about the topic. The options are:

Option one: To distribute master data like Materials, the Materials are classified under a class using the classifcation for each of the external systems and then using these classes on the distribution model. So whenever a material needs to go for a external systems, it is classified on the corresponding class. The main Con we see with this is that we generate an idoc for each of the external systems.

Option two: All materials are sent to PI using a unique idoc and the we put the logic for distribution on PI, using data like Plant, Sales organization, material type and so on it is possible to derive the system that they need to be distributed to. This way only one idoc per material is sent to PI and the PI will send the messages wherever they are needed.

I hope I have explained it ok

What do you guys think about it?

Best regards,

Accepted Solutions (1)

Accepted Solutions (1)

Shabarish_Nair
Active Contributor
0 Kudos

Personally, I will prefer option 1 for its clarity.

In a day today business, the end user will have more and more access to the application system than the middle-ware. hence it is critical that there is a simplicity in understanding the data. If there is a complex logic of determining the receiver based on X parameters, then from looking into the source message it will not be very easy to deduce the information from an end user perspective. Incase you use option 1, there will be clarity as to what is the message that was send to whom. I see simplicity in that approach and hence that will be my preference.

Answers (2)

Answers (2)

bhavesh_kantilal
Active Contributor
0 Kudos

The CON to approach 1 is the volume. From my experience, I have seen that master data replication requires a huge volume ( definitely during cutover from legacies to SAP ) and also generally as a principle.

Before you go for approach 1 determine the volume,

1. How many initial loads are expected?

2. Is the full load supposed to be done periodically?

3. How is delta load to be done? Volume per day etc.

If the volume is acceptable, then having duplicated IDoc's in XI would not be a issue but if not probabaly you would need to consider using IDoc collection patterns on the Source using files / or IDoc packaging using Sender IDoc adapter etc.

I have always had performance issues with master data loads and hence I am always careful on the design of such interfaces and hence while approach 1 sounds a good solution for all points listed above, I would also ask you to do some diligence on the volume and design your interface to address such volumes!

Regards

Bhavesh

Former Member
0 Kudos

hi,

as we don't know your context and your complete business scenario, it's difficult to say "THE" solution is ...

Else by what you say, I would prefer the option 1, because:

- you can managed easily different scheduled job (time of extraction) depending on your different Legacy needs (perhaps your legacies are localized in different countries, so different timezones). You can use the same extraction program with different variants.

- you limit the risk to only one legacy sending if something is wrong with your idoc. If you have only one big idoc to split, the risk of a pi mapping dump will be for all your legacies. is it in compliance with your business ?

- If you have only one idoc, and do the split in PI based on plant, sales areas, material type, etc... that means when you will change one of this structural data , you (in fact business or functional) have also to think that you have this data also hard-coded in PI mapping and/or in a receiver dertemination condition, so somewhere in the 'technical' side (e.g middleware). Well could be a real nightmare and 100% of chance that you will have an issue. And see previous point, issue could be global.

- with only one idoc split in several messages for several legacies, when you will have a new legacy or have to remove one, that means you will have also to change the spliting mapping, and so in theory you should do regression tests for ALL your legacies, and not only the new one.

there are probably other points of view, but here mine with what you explained us.

Regards.

Mickael