Skip to Content

How to set soap action in soap adapter during configuration when there are multiple operations in a web service?

In this blog, I would like to illustrate how configurable parameters, adapter specific message attribute, dynamic configuration and function library concepts are utilized to set soap action at configuration time. The concepts used here are not new and you will find documentation and blogs on many of these concepts. I am trying to illustrate how these concepts were used together in one single scenario.

If you have consumed a web service with multiple service operations, then you would have already experienced the need to set soap action dynamically. Using dynamic configuration and UDF you can set the THeaderSOAPACTION in the message map. Setting soap action in message map constrains you to set the soapAction,  a configurtion time value, during design time. In addition, if your message map is capable of handling maps for multiple operations then you are stuck. This is where you can combine parametrized mapping, dynamic configuration, UDF in Function Library and ASMA to set the soap action at configuration time.

Pictorial requirement description:

For the love of flow chart, i have illustrated the steps in the below diagram. Please note that the steps are just indicative and do not indicate any strict order. Steps 1 through 4 are performed in ESB and 5,6 are performed in IB.

Step 1: ESB Message map: Create a parameter for soapAction

Step 2: ESB Function library: Create a function in function library

public String setSoapAction(String soapAction, Container container) throws StreamTransformationException {
String funcName = "setSoapAction: ";
// get trace object using container
AbstractTrace trace = container.getTrace();
// If soapAction is null or blank, then return
if( soapAction == null || soapAction.equals( "")) {
    trace.addInfo(funcName + "called with  null or blank value. Returning. " );
    return soapAction;
else {
       trace.addInfo(funcName + "called with  value - " + soapAction);
// Get dynamic configuration object
trace.addDebugMessage(funcName + "getting dynamic configuration ");
DynamicConfiguration conf = (DynamicConfiguration)container.getTransformationParameters().get (
// If dynamic configuration object is null, return
if(conf == null){
     trace.addInfo(funcName + "Unable to get dynamic configuration. Returning. ");
    return soapAction;
// Create the dynamic configuration key
trace.addDebugMessage(funcName + "creating dynamic configuration key THeaderSOAPACTION");
DynamicConfigurationKey key = DynamicConfigurationKey.create("","THeaderSOAPACTION");
if(key == null){
    trace.addInfo(funcName + "Unable to create configuration key THeaderSOAPACTION. Returning.");
    return soapAction;
// set the THeaderSOAPACTION key value
trace.addDebugMessage(funcName + "setting value " + key.toString() + " "+ soapAction);
conf.put(key, soapAction);
return soapAction;

Step 3: ESB: Use the function library in message map. Provide the parameter created earlier as input to function

Step 4: ESB: In operation map, create the binding between message map parameter and operation map parameter. You will see the operation map parameter during interface determination configuration in IB when operation map is used in the interface determination..

Step 5: IB: content based routing with different operation maps. You will be able to set different soap action values for each operation map. Note: Setting parameter values in integrated configuration is supported only from 7.31 version.

Step 6: IB: configuration illustration: You can leave soap action blank.Ensure that you use THeaderSOAPACTION.

Brief description of concepts used:

Configurable Parameter: A configurable parameter is a parameter to which a value is provided during configuration. In PI, design and configuration is handled separately. During design a parameter is created. During configuration a value is provided to the parameter. This feature allows multiple usages with different values. When configurable parameters are used in Mapping programs, the mapping programs are called Parametrized mappings. Additional details re available in sap help at Parameterized Mapping Programs.

UDF: An user defined function is a java method written to be used in a message mapping.When a UDF is created in a message mapping, it will be stored as a local function to that specific message mapping and will bot available in other message mappings. Additional details are available in sap help at User-Defined Functions.


Function Library: When you need to reuse a function across mappings, you need to create it as a function library. A function library can have multiple functions. Additional details are available in sap help at Function Libraries.

ASMA: Some adapters support specific message attributes which are called adapter specific message attributes. The values are set in the sender adapter and are used in routing, mapping or receiver adapter. More details on supported attributes are available at Using Adapter-Specific Message Attributes in the Message Header.

Dynamic Configuration: The message header that contains adapter specific message attributes and customer attributes is called dynamic configuration. Additional details are available at DynamicConfiguration API

Version information: This solution is tested and working on SAP NW 7.30 SP05. As of 30-July-12, this solution is not working in 7.31 SP04 due to an issue with configurable parameters.

Update as of 16-Aug-12: Configurable parameter issue is resolved using same parameter name in message map and operation map. The solution is working in 7.31 SP04 as well.

You must be Logged on to comment or reply to a post.
    • Venu, Thanks for the comment. Hope it looks better now(Flow chart should be... ). Some of the images are slightly blurred when the blog is published. I have to find a way to work around that...

  • This was a great help for me, to connect a webservice with 4 different soap actions, implemented by DotNet, to our PI (7.11).

    Because of PI 7.11 parameters in operation mappings are not supported in integrated configuration.

    So I decided to set soap action in ESB at message mapping.

    For this I created a message- and an operationmapping for every soap action.

    It would have been more helpful if the whole settings for message mapping settings were in the screenshot, because I'm not very familar with message mappings.

    Generally I would say, that ESB is the better place to set soap action, because soap action is a design time element of a webservice.

    • Finally I solved the problem by implementing the service with four receiver service interfaces with one action per interface at PI. Then I created 4 communication channels for the receiving Business System and set the proper soap action in communication channel settings.

      This is easier to understand for the people, which have to care for the scenario at productive system.

      Because I'm working with "matching interfaces" at inbound and outbound of PI, there is no message mapping or operation mapping required for the scenario at all.

      It's not easy to understand that there is a message mapping, which does nothing with the message content but with the proprietary PI message header elements.

  • Is there a way to set the SOAP Action Dynamically without using an UDF?

    We have an WebService with no Mapping in between and I dont want to create a Mapping just for the SOAP Actions.