PI 7.5 interface architecture possibilities

[Former Member]

Dear experts,

My company is preparing to upgrade its PI 7.0 (dual stack) version to 7.5. We are currently debating our installation options based on a critical interface that has been built using ccBPM (brief simplification can be found at the bottom of the thread). Our first option would be installing PO 7.5 (single stack), and build a BPM to substitute our old ccBPM solution, but we were considering simplifying this interface architecture in order to remove the need for a BPM solution which would result in a full PO installation. Our main goal is to keep our landscape as simple as possible.

Brief explanation of the interface:

1. SAP ECC start a async call starting ccBPM;
2. ccBPM executes a sync interface with an external web service;
3. After some transformations and validations, ccBPM starts a async interface routing to multiple abap proxy possibilities;
4. Return to step (2) while the external web service still has some data to be consumed;
5. At the end of ccBPM execution, it calls a RFC to inform that the processing has ended.

The minimal practical simplification for us would be:

1. SAP ECC start a sync request to PI wich route it to external web service
2. After PI receive the response, it should be able to do the following things:
   1. Start a async interface to ECC (taking advantage of all the proxy that have already been built*)
   2. Reply to the sync call of ECC passing some basic information of the message processed;

* Considering that the transformation of abap to java proxy has already been done, if a single stack installation has been chosen.

It is important to state that this external web service can return more than 100 different message types with completely distinct xsd, this is the reason for us to keep the PI to ECC async proxy call.

The main question is... is it possible to build such interface with a PI only installation? Both single stack and dual usage are acceptable for our basis team.

Thanks in advance.

[engswee · Accepted solution]

Hi Yuri

From the details provided, I'm guessing you are trying to avoid going for a full PO license in this upgrade. If you go for dual usage (which I personally would not considering SAP's roadmap), ccBPM is still available for you since there is an ABAP stack.

If you want to go for an AEX-only installation (PI without NW BPM/BRM), it might be possible to achieve your requirement using module based async-sync bridge, but I need to clarify some items.

1. I haven't done ccBPM for a while, but I don't think you can have step 3 before step 4, i.e. you need to wait for sync response before you can proceed with doing anything else (transformation, call proxy, etc)

2. Will each invocation of this ccBPM process only call one async ABAP proxy? Or it could be that many items are returned from the web service, and you need to loop through and call multiple proxies (or one proxy multiple times)?

3. What do you mean in step 4 "web service still has some data to be consumed"?

4. What type of information is returned to the RFC - does the content come from the async call in step 1 and/or from the web service call in step 2?

Regards

Eng Swee

[Former Member · Accepted solution]

Hi Eng Swee Yeoh,

Thanks for the time spent trying to get a better understanding on our scenario.

It surely would the easier for us going to a dual usage installation, we were not sure if ccBPM would still be available, but you already clarified it for us thanks! However, we are aware that the SAP recommended installation would be the Java single stack.

What we are considering while trying to avoid the full PO installation is the trade-off on increasing the complexity of our landscape, by installing BPM and BRM we could have the need for augmenting our support and infrastructure teams, and the complexity of redesigning our interface from the ground up in order to keep a simpler landscape.

1. You are completely right, the transformation step occurs only after we have a response for the sync web service call. I might have oversimplified while trying to explain, my bad.

2. You are right again; We only receive one message from the web service per round. It is only the set of different messages it could send us each round that is great.

3. This is the condition to keep the loop going. Before step (2), we write on a variable a value which guarantees entering the loop (which runs steps (2), (3) and (4)) at its first round. One of the information we get from the web service response is whether there are new messages ready for us or not.

4. This step is necessary only for log purposes, since we could spent some time getting new messages from the web service, this is the way we know when the ccBPM processing has ended and the time it has finished.

Best regards,

Yuri.

[engswee · Accepted solution]

Hi Yuri

Firstly, I'm trying to understand why you feel that having NW BPM and BRM will increase the complexity of your landscape. From an infrastructure perspective, there is no difference because under PO installation, all three components of PI/AEX, BPM and BRM is on the same server, and is just installed via a wizard - either choose AEX or PO. As for integration skillset, the developers just need to learn NW BPM and it is not a big learning curve if they already know ccBPM - there are plenty of resources on SCN. There is not much to redevelop from ground up other than the ccBPM -> NW BPM processes.

If you go for an AEX installation, you need to be aware that your landscape will be lacking BPM-type functionality. While you might feel this simplifies the landscape in the short term for your migration efforts, in the long term it might hamper or limit your options for future developments. You might have future integration requirements that are best fulfilled with BPM-type functionality, but since your landscape would not have it, you might end up having to design ugly workarounds to fulfill those requirements.

IMHO, it is as important to ask and answer the why questions (i.e. why are we choosing AEX over PO) over the how questions (i.e. how can we achieve this in AEX).

Now back to your questions.

From your responses, in particular to Q2 & Q3, it is clearer now that it is possible for your ccBPM process to issue multiple calls to the web service, and in return execute multiple async calls to ECC proxy. As such, this requires a stateful integration pattern, because you need to keep track of the call to the web service and figure out when to stop. Such stateful integration is best fulfilled by a BPM process (whether ccBPM or NW BPM).

The approach mentioned by Bhavesh might have been a possible solution if you only call the web service once. If you have to potentially call it many times, and you want to design it in a mapping, there is a risk of the mapping having side effects. This is not good especially since your scenario has a mix of async and sync calls. Think about what would happen in case there are errors at some point in the scenario - what if some of the web service calls (and the subsequent async proxy call) were successful but there was an error after that before you finish consuming all the new messages from the web service - how are you going to restart/resume the interface making sure that previous successful ones are not duplicated?

Regards

Eng Swee

[bhavesh_kantilal · Accepted solution]

Hi  Eng Swee,

As for integration skillset, the developers just need to learn NW BPM and it is not a big learning curve if they already know ccBPM - there are plenty of resources on SCN. There is not much to redevelop from ground up other than the ccBPM -> NW BPM processes.

The fact is : The number of PI developers who truly understand ccBPM are far and few in between and those who PI Developers who understand NW BPM are even more less. While technically I agree that hey, it was a easy transition for people like us, what I have seen is that this competence is not very prevalent in PI Developers. Also, I have seen customers reluctant to move to PO for this reason as theie support organization would then say - hey, this is a niche skill, you need to pay more $$ or get more people onboard etc./ Not Logical yes but this happens..

Another comment here in terms of license - I have seen companies that have got a good deal on PI licensing as they were early adopter of XI 3.0  / PI 7.0. Such companies now when they have built a huge PI footprint when going into a new licensing for PO are worried that they would have do invest lot more than their initial investments. I have seen licensing and Annual Maintenance costs for PI to be $1000 / year. For such customers,renegotiating licenses to move to PO does not seem to make sense as the procurement and financing teams want a better understanding on a non available ROI

But yes, having said this I do agree that if licensing cost is not a challenge, then getting PO definitely makes any organization ready for better Integration Capabilities and build normal integration patterns for BPM using NW BPM capabilities.

Regards,

Bhavesh

[Former Member · Accepted solution]

Hi End Swee and Bhavesh,

Firstly I would like to thank you guys for this rich quality discussion, I really appreciate it.

Eng Swee,

We share the same point of view on the importance of the “why question”, and that going for a PO installation would definitely pay off in the long term specially if we consider the possibilities that BPM + BRM could provide for future projects. The information you’ve provided that PO entire stack can run in the same server will definitely help our evaluation. However as Bhavesh pointed out, in my country, PI/PO developers are not found easily and for that reason I feel obliged to present to our board of directors all available options in order for them to take an informed decision.

You are perfectly right concluding we have a state full integration, and the only way I could think of changing this architecture in order to remove this impediment, would be removing the responsibility of looping and calling the web service multiple times from PI and handing it over to ECC. This way, an ABAP program would take the decision whether or not to keep looping based on the response PI provided to it (step 4 of the attached sketch).

Best regards,

Yuri.

[engswee · Accepted solution]

Hi Bhavesh

I totally missed out your previous reply above - happens quite commonly when there are more than 1 replies across different thread/hierarchy within the discussion.

Thanks for adding your opinion to this matter - it's great to hear the different perspectives for a more holistic view of the issue. Saying that, my previous response was within the context of Yuri's reply regarding avoiding full PO installation which was due to support (I read it as skillset) and infrastructure. Regarding skillset, I had assumed that since there is a current ccBPM design in place, there would be personnel(s) with such skillset to support it and therefore assume such personnel(s) could be cross-trained to NW BPM. I would have thought it would be a good opportunity too for the personnel(s) to pick up a new skill - but as you pointed out, I might have had my Utopian hat on.

With regards to licensing, that is such a subjective matter (at least in the world of SAP) - there are so many factors that goes into that equation (discounts, credits, commissions, etc, etc) that what applies for one customer might not for another. Furthermore, it wasn't mentioned specifically that licensing cost was a challenge.

Yuri,

I guess you are already aware yourself that at the end of the day, you have to sift through the comments/feedback here and that what is relevant to be presented to your board. It's definitely important to provide a holistic assessment of the situation and alternatives for them to make the decision.

Lastly, I just add a last point on having a good design in relation to cost. Since you mentioned that this is a critical interface, you should assess the impact of a non-optimal/reliable design - what is the cost, i.e. loss of business, increased support effort, etc.

Regards

Eng Swee

[bhavesh_kantilal]

Hello Yuri,

I am looking at just to to-be scenario that you have described

The minimal practical simplification for us would be:

SAP ECC start a sync request to PI wich route it to external web service
After PI receive the response, it should be able to do the following things:

Start a async interface to ECC (taking advantage of all the proxy that have already been built*)
Reply to the sync call of ECC passing some basic information of the message processed;

Below is how my technical implementation would look like,

Scenario 1 -> SAP Sync to Webservice Sync

• SAP triggers call to PI using your Synchronous ABAP proxy
• Request Mapping remains as -is and then the call to Webservice is triggered
• Response Mapping would need a change.
  • In the Response Mapping add an additional UDF that make a SOAP Loopback call to PI.
  • What is a SOAP Loopback call - in your UDF you make a SOAP Lookup call to a SOAP Receiver Adapter. The SOAP Receiver Adapter points to the SOAP Sender Adapter URL of PI.
  • The SOAP Sender Adapter will in turn trigger your respective ABAP Proxies through Scenario 2

Scenario 2 -> SOAP Sender to ABAP Proxy Calls

• Create a Interface that takes the request message from the UDF of the Response mapping of Scenario 1.
• This will then process it either through a Conditional Receiver or Interface Determination to make the Async Call to ABAP Proxy as you require.
• The UDF written in Scenario 1 might need to have the know -how to tell scenario 2 which Proxy to trigger etc. But this should be easy to do by either having a generic structure or multiple Operations in your Outbound SI etc.

I am not sure if this fits in perfectly but this could be one option that you can enhance on!

Have I used this SOAP Loopback before - extensively and it works like a charm with just minor irritants around monitoring as correlating the messages in production between Scenario 1 and Scenario 2 was a challenge. We had TREX in our set up and hence we could then use Payload Based Search and get the correct messages. Using User Defined Message Search could also address this "monitoring" challenge.

Regards

Bhavesh

[Former Member]

Hi Bhavesh Kantilal,

That is a great possibility, we have some RFC lookup UDF implementations here but we have not considered this design! Using this strategy we could go for a PI java only installation and reduce the development time for the interface’s redesign, is that correct?

It is indeed a problem the monitoring difficulties you have pointed out, I appreciate it, this will surely enter our tradeoff list. In your experience performance wise, did the SOAP Lookback increased the processing time extensively?

Explaining a little further what happens between the response from the web service and the async proxy call:

1. The response from the web service is stored in a generic message type;
2. After some transformations with soap envelope and cdata, we have a Java mapping class to determine which message was received and through namespace changing we point it to its correct xsd type;
3. A send step is triggered and a conditional receiver determination defines which proxy will be called.

Considering this design, if we keep our Java mapping before the MM for the SOAP lookup, would we have a runtime error considering it would not be a generic message anymore? Maybe we could trigger the SOAP Lookback from the java mapping itself, would this be possible?

Best regards,

Yuri.

[bhavesh_kantilal]

Hello Yuri,

What Eng Swee has mentioned in his comment that if you are making multiple Webservice calls, this can become a challenge is definitely true. So if it is more than one Webservice call, do not use this design pattern. Do consider the fact that what happens is a resubmission is done etc when the mapping is retriggered in the case of errors etc.

Having said that - below is my understanding of your ccBPM

1. Receive Step - Receives a Sync Request & Opens Sync Async Bridge
2. Send Synch Step - Makes a Webservice call and gets a response
3. Transformation Step - Has a Java Mapping that takes the Webservice response and forms a message to point to correct Message Type / XSD.
4. Send Step - Sends this Message from Step 3 to a Conditional Receiver Determination / Interface Determination to trigger a Proxy Call.
5. Transformation Step - Webservice Response to original Proxy Response
6. Send Step ( Close Synch -Asynch Bridge ) - To send response back to Original Proxy of Step 1.

If yes, the design work be as below,

You would need to move the Mapping Logic of Step 3 above to the Mapping of Step 5. What I mean by that is, Your Operation Mapping should have the request as Webservice Response and Response as the Proxy Response.Modify Java Mapping to

• Make the SOAP Lookup call from Java Mapping with the correct message formed ( as per the XSD ) to trigger Interface 2. You can call the SOAP Lookup API from a Java Mapping. No challenges there.
• Return the original Webservice response or as needed by the Webservice Response to Proxy as the output of the Java Mapping.
• Next Mapping will the actual Webservice Response to Proxy Response mapping and so on.

Regards,

Bhavesh

[Former Member]

Hi Bhavesh,

Actually our curent ccBPM starts of with a async receive step:

1. Receive Step - Receives a Async Request & Opens  Async Sync Bridge
2. Send Synch Step - Makes a Webservice call and gets a response
3. Transformation Step - Has a Java Mapping that takes the Webservice response and forms a message to point to correct Message Type / XSD.
4. Send Step - Sends this Message from Step 3 to a Conditional Receiver Determination / Interface Determination to trigger a Proxy Call.
5. Transformation Step - Webservice Response to a generic message type (loggin purposes)
6. Send Step - Async send step to provideECC the log of processed message

Nevertheless, considering the architectural modification I've provided in response to End Swee, it seems that the SOAP loopback you've suggested would be a viable alternative for the PI only installation strategy, considering we could implement the SOAP loopback with a java mapping.

I have to say thought that considering the facts you and Eng Swee provided, going with a full PO instalation redisigning our ccBPM to a BPM solution, seems to be a cleaner and more reliable solution.

Best regards,

Yuri.

[Harish]

Hi Yuri,

The best possible scenario is to avoid BPM and redesign the interface. but you can not call the multiple interfaces in sync call response. The alternate option is

Design

1. Create the multi-operation interfaces in source and target side.
2. Multi-operation interface will have multiple structure (message types)
3. Enhance the abap proxy code to handle multi opetaion interface and reuse the existing interface proxy cide.

Run time

1. SAP ECC start a sync request to PI wich route it to external web service
2. After PI receive the response, it transform the response and trigger the relevent operation.

regards,

Harish

[Former Member]

Hi Harish Mistri,

Thanks for the tip on the multi-operation interfaces, I'm not familiar with them but I'll certainly study this solution considering the steps you provided analysing its applicability to our scenario.

Best regards,

Yuri