Skip to Content

PI 7.5 interface architecture possibilities

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.

Add a comment
10|10000 characters needed characters exceeded

Related questions

3 Answers

  • Best Answer
    Posted on Jul 21, 2016 at 02:56 AM

    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

    Add a comment
    10|10000 characters needed characters exceeded

    • 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

  • Posted on Jul 21, 2016 at 03:10 AM

    Hello Yuri,

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

    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;

    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

    Add a comment
    10|10000 characters needed characters exceeded

    • 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.

  • Posted on Jul 21, 2016 at 12:08 AM

    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

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.