Skip to Content
avatar image
Former Member

HTTP response

Hi Experts,

I am quite new to PI and I have a problem with the following scenario.

We are sending ORDERS04 idocs from R/3, converting to an xCBL-order in pi and futher on via Seeburger HTTP to the partnert.

They respond with a Order response xml message via HTTP (which we receive with the Seeurger HTTP Adapter) and convert to an idoc for R/3.

My problem: our partner in the other end expects a HTTP respons (in the same call) containing, among some texts, also information from the original order respons message. We do not need to add info about the processing in R/3. So it is basically a normal 200 or 400 HTTP respons but with some added info from the incoming message.

My thought is to somehow split the incoming message, using the first copy to sent to R/3 and the other copy to map the http-response back to the partner. To somehow attach the extra info to the HTTP respons.

Is that how you do it? Other, simpler ways to do it? How do I set that up? Basically the only restriction I have is to NOT use ccBPM.

best regards,


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Dec 20, 2011 at 01:54 PM

    Hi Glen,

    May be its a good idea if you can map that HTTP order response to IDOC type ORDRSP.



    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Jan 13, 2012 at 10:32 AM

    hi Glenn,

    It depend mainly on why you have to return it. See below the two cases:

    Case 1: like a Technical Acknowlegdment

    With your solution: you return back a response to your partner when PI receive your partner HTTP message... and not when ECC will receive this info. So if inside flow "partner's HTTP message -> ECC", you have an error in PI (mapping dump), in PI queue (connexion issue) or ECC queue, or when the IDoc is integrated in ECC (status=51).... then with your solution, you will say to your partner "everything is good" whereas in fact you have an issue. If it's ok with your partner, yes your solution is ok, as it's like "me, PI, I confirm to you I received your HTTP response, and I will treat it according to my process".

    1st flow: ECC -> PI -> Partner

    2nd flow: "Partner (response) -> PI -> ECC (response)" + "Partner (response) -> PI -> Partner (like a technical Ack)", so two receiver for this Partner response.

    Case 2: like a Functional Acknowlegdment

    But if your partner want to know if its data has been correctly integrated/updated in ECC (so idoc status = 53), then you have to add a step in the idoc integration (inside the function module which is beside the process code, WE02) like to get the Idoc status and/or its error message, and then to call a abap proxy to return back to PI and to to your partner the HTTP response that he want. So in PI you have to define a flow "ECC (proxy for response) -> PI ->Partner (HTTP)".

    1st flow: ECC -> PI -> Partner

    2nd flow: Partner (response) -> PI -> ECC (response: update with an Idoc)

    3rd flow : ECC (ack of response) -> PI -> Partner (Ack of its response)



    P.S: no need of BPM for both cases.... if for all exchanges you are smart and get/provide a unique key which will be used to know it's the response of this exchange xxx for this order yyyy. do not forget you can have parallel treatment.

    Edited by: Mickael Huchet on Jan 13, 2012 10:36 AM

    Add comment
    10|10000 characters needed characters exceeded