PI best practice and integration design ...

[Former Member]

Im currently on a site that has multiple PI instance's for each region and the question of inter-region integration has been raised my initial impression is that each PI will be in charge of integration of communications for its reginal landscape and inter-region communications will be conducted through PI - PI interface . I havent come across any best practice in this regard and have never been involved with a multiple PI landscape ...

Any thoughts ? or links to best practice for this kind of landscape ?...

to Summaries

I think this is the best way to set it up, although numerous other combinations are possible, this seems to be the best way to avoid any signifcant system coupling. When talking about ECC - ECC inter-region communications

AUS ECC -

---

> AUS PI -

---

> USA PI -

---

> USA ECC

[former_member200962 · Accepted solution]

I havent come across any best practice in this regard and have never been involved with a multiple PI landscape ...

For PI-PI or XI-XI integration normally PROXY communication is used..... AUS PI (integration engine) will communicate with US PI (integration engine)

References to such scenarios can be found on SDN.

Regards,

Abhishek.

[Former Member]

Thanks for the input guys, Im a bit disappointed there is no best practice in relation to this kind of integration scenario given it cant have been the first time a single company has had multiple PI instances but I guess its a little out there ..

Monika, I think you may have misinterpreted Stefans reference to B2B. I assume he was just using that as a way of illustraiting the relationship, in reality there is no need for reverse proxies (web dispatcher) as all the lanscapes exists with a single company.

Thanks for taking the time all.

[Former Member]

Hi

The best approach is always

A-PI(A)-PI(B)-B

A would never communicate directly to B. A would send data to PI(A). PI(A) would talk to PI(B). PI(B) will send the data to B.

This is because of security concerns. In between PI(A) and PI(B) would be a reverse proxy or a Web dispatcher.

Regards

Monika

[Former Member]

Thanks for the reply guys, unfortunately you have sort of missed the point ...

1. Im easily able to integrate the 2 systems via ABAP proxies

2. They are both production landscapes.

The question in essence is;

What is the SAP Best practice guide for integrating multiple lanscapes each with their own PI system. If the Australian ECC production system has an output bound ultimately for the USA ECC production system in order to decouple sender and receiver one would normally just use PI as a communication broker but given both landscapes have their own PI would the correct approach be ECC AUS -> PI AUS -> PI USA ->ECC USA.

Please keep in mind the actual communication is very simple to acheive (directly, through a single PI, through both PI's).

Presently the directive is that each PI will manage communications with its own landscape only respectively, given this it would seem appropriate to simply address the local PI and have it send the message onto the receiving PI system to then pass the message onto its local ECC - completely decoupling the landscapes.

If either PI system addresses non-local systems directly I can see a spider web of interfaces emerging between each PI instance and the sending and receiving system, not to mention there would be no way at a high level to tell which PI was being used for any given integration scenario

eg. I need to get data from my local ECC to USA ECC, do i send the data to their PI/my PI/directly to their ECC, all will work, all are valid but I wager that one and only one would be regarded as the best way to approach the problem.

[former_member200962]

I need to get data from my local ECC to USA ECC, do i send the data to their PI/my PI/directly to their ECC, all will work, all are 
valid

If LocalECC --> onePI --> USA ECC is valid, then you dont have to go for other PI in between...why to increase the processing time....and it seems to be a good option to bet on.

But then what about this statement (is it a restriction or business requirement)

Presently the directive is that each PI will manage communications with its own landscape only respectively

Lets see what experts have to say on this.

Regards,

Abhishek.

[Former Member]

I need to get data from my local ECC to USA ECC, do i send the data to their PI/my PI/directly to their ECC, all will work, all are 
 valid
 If LocalECC --> onePI --> USA ECC is valid, then you dont have to go for other PI in between...why to increase the processing time....and it seems to be a good option to bet on.

The issue is

1. Which PI system should any given peice of data be routed through and how do you manage the subsequent spider web of interfaces resulting from PI AUS talking to ECC US, ECC AU, BI US, BI AU and the reverse for the PI USA system.

2. Increased processing time Integration Engine - Integration Engine should be minimal and it will mean a consistent set of interfaces for support and debug, not to mention the simplification of SLD contents in each PI system.

I tend to think of like network routing, the PI system is the default gateway for any data not bound for a local systems you send and let PI figure out what the next step is.

 But then what about this statement (is it a restriction or business requirement)
Presently the directive is that each PI will manage communications with its own landscape only respectively

When talking multiple landscapes dev / test / qa / prod, each landscape has its own PI system generally, this is an extention of the same idea except that both systems are productive, from a interface and customisation point of view given the geographical remotness of each system local interface development for local systems and support makes sense, whilst not limited to this kind of interaction typically interfaces for a given business function for a given location (location specific logic) would be developed in concert with the interface and as such has no real place on the remote system (PI).

To answer your question there is no rule, it just makes sense.

[stefan_grube]

> What is the SAP Best practice guide for integrating multiple lanscapes each with their own PI system.

There is no best practice guide from SAP.

> would the correct approach be ECC AUS -> PI AUS -> PI USA ->ECC USA.

In my opinion this is the only valid approach.

Note that the PI - PI system will be treated like a B2B scenario. So the PI systems only know the local business systems. The remote business systems are replaced by party services.

This has the advantage that you see in any scenario, whether another PI system is involved or not.

[Former Member]

Hi Richard,

I think this is the best way to set it up, although numerous other combinations are possible, this seems to be the best way to avoid any signifcant system coupling. When talking about ECC - ECC inter-region communications

If i understand your question correctly :One option could be to have AUS PI -

---

> USA PI in the same DMZ

my assumption is like your AUS PI is your dev system and USA PI is your Prod system. if it is B2B integration with two xi systems

i am wrong:).

inter-region communications will be conducted through PI - PI interface

/people/arvind.ravindran/blog/2009/05/19/the-use-of-receiver-agreement-header-mapping-in-a-b2b-scenario-150-pi-to-pi-integration

the similar threads, XI to XI scenarios:

result of forum search :)... Please do a search

Regards,

Srinivas