on 12-20-2011 1:41 PM
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,
Glenn
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)
regards.
Mickael
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Thanks for the response. It is ok to say that all is fine on our side even if I get mapping errors. The only requirement is that in the HTTP response back to our partner (in the same call, ie without breaking the session) we can refer to the exact order respons message number he sent to us as part of his order respons payload.
But I guess that I can use option number 1 then?
kind regards,
Glenn
Hi Glen,
May be its a good idea if you can map that HTTP order response to IDOC type ORDRSP.
Thanks,
Pushkar
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
80 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.