cancel
Showing results for 
Search instead for 
Did you mean: 

Consuming web services provided 3rd

former_member286225
Participant
0 Kudos

Hello experts,

I have a scenario SAP -> XI -> 3rd party WS (with multiple actions)

The 3rd party WS contains several actions for manipulating a Business Object.

I would like to define one Inbound Service Interface with several Operations for consuming the web service with its actions.

Everything is okay at design time. I defined all necessary objects based on the WSDL that represents the WS.

The problem is at configuration time:

1. I can define only one Receiver Agreement for the given Service Interface & Business System (There is no indication or seperation for the different operations defined in the Service Interface).

2. In the Receiver Agreement I can choose only one SOAP Receiver Communication Channel.

3. In the SOAP Receiver Communication Channel I can define only one Action for the provider WS.

According to SAP paradigm (backed up by the SAP ProComp Model in the modeling tool available in PI 7.1) one can define an Inbound service interface with several operations. it seems that the configuration does not support this kind defenition for SOAP adapter.

If anyone encountered this problem and have a solution, I will appreciate sharing the information.

Regard.

Accepted Solutions (0)

Answers (4)

Answers (4)

former_member286225
Participant
0 Kudos

Hi Suraj,

Thank you for your fine advice.

The solution you gave seems to do the trick.

Having said that, I still think this is a work around and SAP should enhance the receiver agreement to handle communication on a service interface or an operation basis. When selecting a service interface, the actions should appear as a table and one can decide whether to select a comm channel for the entire service interface or for each action.

Regards,

Effi.

former_member187339
Active Contributor
0 Kudos

Hi Effi,

Glad that my hint helped you.

I don't think this to be a workaround. See the SOAPAction itself is not a mandatory field in Receiver SOAP Adapter that means a single communication channel is capable of supporting more that one soap action.

The only thing is you need to explicitly take the ACTION and update SOAP Header field..

But again it is just my opinion. Let SAP choose the best approach

Have a good day

Regards

Suraj

former_member286225
Participant
0 Kudos

Hi Suraj,

Thank you for your reply.

Unfortunatlly, your suggestion did not help. I tried it and as expected, I got the following error:

SOAP: response message contains an error XIAdapter/PARSING/ADAPTER.SOAP_EXCEPTION - soap fault: Server did not recognize the value of HTTP Header SOAPAction

It seems that SAP forgot to support the design time defenitions in the configuration time defenitions when it comes to 3rd party WS.

Any other suggestions will be appreciated.

Regards,

Effi.

former_member187339
Active Contributor
0 Kudos

Hi Effi,

Another approach is tho dynamically assign the SOAP Action and then retrieve it in the Communication channel

Use this peice of codeto assign SOAP Action value to

DynamicConfigurationKey keyURL = DynamicConfigurationKey.create("http://sap.com/xi/XI/System/SOAP","THeaderSOAPACTION");

// access dynamic configuration

DynamicConfiguration conf = (DynamicConfiguration) container

.getTransformationParameters()

.get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);

conf.put(keyURL,"<your action>");

return "";

Then switch on the *adapter specific identifiers (and select use variable binding) *in SOAP Channel and specify as specified in this link

http://help.sap.com/saphelp_nw04s/helpdata/EN/29/5bd93f130f9215e10000000a155106/frameset.htm

Also check the Keep Header checkbox

I dont have a XI box here to give a try, so please give a try and I am sure you will get the result.

Regards

Suraj

former_member286225
Participant
0 Kudos

Hello Abhishek,

Thank you for you quick reply.

I looked at your excellent weblog. Unfortunately, it does not solve my problem.

In your weblog you use 2 different systems for dealing with the 2 operations. This gives you the ability to define 2 receiver agreements for the given 2 operations.

In my case, the operations are exposed by the same business system (which is defined in our SLD) hence, I can define only one receiver agreement as: SYS_A | SI_In.

This takes me back to my first post: I can attach only one receiver SOAP Communication Channel with a given SOAP action to the defined receiver agreement.

Regards,

Effi.

former_member187339
Active Contributor
0 Kudos

Hi Effi,

One doubt, the receiver structure (soap side) was made from a wsdl right? so each operation type shoudl have a action associated with it. So what will happen if we dont specify any action in the receiver SOAP channel?

Will it not go to the desired action? Can you try this option?

Regards

Suraj

former_member200962
Active Contributor
0 Kudos
1. I can define only one Receiver Agreement for the given Service Interface & Business System (There is no indication or 
seperation for the different operations defined in the Service Interface).

It never is. No differentiation based on Operation in Receiver Agreement.

2. In the Receiver Agreement I can choose only one SOAP Receiver Communication Channel.
3. In the SOAP Receiver Communication Channel I can define only one Action for the provider WS.

This is the expected behavior.

Interface Determination plays the important role of mapping the relevant Source Interface/ Operation with the corresponding target Interface/ Operation.

In Interface Determination you can select only the Source Operation and then include the relevant mapping program. Selection of Target Operation is not possible.

May be this blog will help you a bit: /people/abhishek.salvi/blog/2009/07/31/using-service-interfaces-now-reuse-one

Regards,

Abhishek.