cancel
Showing results for 
Search instead for 
Did you mean: 

synchronous RFC --> SOAP Scenario: problem with SOAP Response/Fault Mapping

Former Member
0 Kudos

Hi,

I've a synchronous RFC --> PI --> SOAP Scenario. The problem is that the message structure of the sending RFC doesn't match the Webservice Structure.

The (SAP standard) RFC has just a Request / Response message structure. Part of the Response Message structure is a exception structure.

The Webservice has a Request / Response message structure and in case of an error I get a SOAP:Fault.

Problem now is that I cannot configure that scenario without usage of BPM as I will have to map SOAP:Response or SOAP:Fault to the RFC Response structure.

Has anybody another idea to do that synchronous scenario (with usage of message mapping) without BPM?

BR

Holger

Accepted Solutions (0)

Answers (2)

Answers (2)

rodrigoalejandro_pertierr
Active Contributor
0 Kudos

1)

you maus define 3 mapping.

1)request

2)response

3)Fault

in Interface mapping define at response boths (2-3) mapping. its clear??

2)

otherwise sometjhing is not clear, why do you want fault?? why dont you get only response message. we implement this kind of response:

<response_MT>

<ID> (error ID)

<system> (target system)

<error> (Error Description)

</response>

by this way fault message is not needed. but if you must have it just follow the top of message else, propose second.

Thanks

Rodrigo

Thanks

Rodrigo

Edited by: Rodrigo Pertierra on Feb 25, 2008 11:52 AM

Former Member
0 Kudos

hi Rodrigo,

it's already clear that I'll need 3 mappings, but it's not clear how to do it. As described the RFC interface just has 3 "interfaces" (request, response), but no fault "interface". So I cannot assign a mapping therefore in the Interface Mapping.

So as far as I've understood I'll have to manipulate the RFC message WSDL and manually create a fault "interface" within, I don't know actually how it should look like within the WSDL, and then I'll have to work with the manipulated WSDL instead of the imported RFC object.

BR

Holger

Former Member
0 Kudos

no no...

Holger, you have only one response and it is BAPI response, right? So when you receive standard soap response, you'll use standard mapping. If there is a soap fault, SOAP fault will be mapped again to BAPI.response, but other nodes (RETURN - type BAPIRET2). Clear?

Unfortunately, in your outbound interface you can't define an application message as BAPI.response. (just try it and you'll see). but you can use an external definition. So create the BAPI.reponse structure as an exteranl definition and you'll use this one in the outbound interface as a fault message.

Is it clear now?

Peter

rodrigoalejandro_pertierr
Active Contributor
0 Kudos

hi

if RFC does not have a exception response just you have two possibilities:

define a ZRFC with exception or just do y propose you in my previous post but sure the RFC must has one.

thanks

Edited by: Rodrigo Pertierra on Feb 25, 2008 12:22 PM

Former Member
0 Kudos

Hi,

I think you could map the SOAP response as well as SOAP fault messages with RFC response with multi-mapping. No need of BPM.

If you are expecting the exact format then probably you could create the dummy function module as RFC in R/3 use the structure of Import , export and exception for it. In source code call the SAP standard RFC. that way also you could achieve it.

Thanks

Swarup

Former Member
0 Kudos

Hi Swarup,

I don't think a Multimapping will help as the elements <SOAP:FAULT> or <SOAP:ENV> (root elements in case of a exception or normal response) are not part of a message mapping programm. Within message mapping I can just declare the payload itself, not the SOAP specific envelope around it. Please let me know if I'm wrong.

The other solution won't help as I cannot modify the SAP standard in that case.

BR

Holger

Former Member
0 Kudos

Holger,

map the soap-fault to RETURN param of a BAPI.response, and SOAP response to BAPI.Response normally. Unfortunately, you cant use BAPI.Return structure for a Fault message (outbound interface fault message), so create this structure as an external definition by exporting BAPI-Response's WSDL and creating this external definition from it.

Peter

Former Member
0 Kudos

Hi Peter,

can you please explain a little bit more in detail what I should do? Unfortunately I didn't get it how your solution should work.

Thanks

Holger

Former Member
0 Kudos

a, Holger, create 3 message mappings, one for request, one for response, and one for fault (from SOAP fault message to BAPI.Response).

b, in sync interface you should define outbound message, inbound and fault, right? Ther is no problem with standard messages, but there is a problem with the fault one, since you can't define an application message (BAPI.response) as an fault message. So you must do a workaround - create this BAPI.repsonse as an external definition) and use it in outbound interface as a fault message.

Then, in interface mapping use developed mappings.

Is it clear?

Peter

Former Member
0 Kudos

Hi Peter,

yes, now I got it. I'll try it, sound good

Thanks

Holger

Former Member
0 Kudos

Sounds good, I'm just not sure if this will work but try... There is no reason why it shouldn't...

Peter

Former Member
0 Kudos

Hi Peter,

just thought further about your solution: When I call from the backend the sender RFC, I'll have a configuration for the SenderInterface = RFCName SenderNamespace = urn:sap-com:document:sap:rfc:functions.

When I'd use your solution, I'll have to create a synchronous MessageInterface (direction = outbound) in order to archieve your solution creating a fault message structure with my BAPI response. But now, having that MessageInterface and Interface Mapping, I cannot assign it to my configuration as MessageInterfaceName != RFCName. Am I right?

BR

Holger

Edited by: Holger Geisser on Feb 25, 2008 4:09 PM