Skip to Content

How to get the Additional Adapter Attributes of Sender JMS in Message Mapping

Here in this blog I have given an example how we can retrieve additional adapter attribute values of Sender JMS Adapter in our message mapping by using Dynamic Configuration. 

Let’s say our requirement is to get TransactionId & ContractId which is coming from MQ. MQ is sending the values for these two parameters in JMS header and we need to fetch & use these value into our mapping. So here is step by step solution to get the same.


Step 1. Set the ASMA (Adapter-Specific Message Attributes) settings in Sender JMS adapter.


Step 2. Enter TransactionId & ContractId under “Additional JMS Properties” as shown in below picture. You can use any name but it should be exactly same as it is maintained in sending system i.e MQ. Consult the MQ people to know the names.

Here I also need JMS Message ID in my mapping so I have selected it as well.



Technical names for above mentioned additional JMS properties are DCJMSMessageProperty0 and DCJMSMessageProperty1 respectively.

For more information on Technical Names, please refer the sap help.


Step 3. Create the UDF which will retrieve the Dynamic Configuration values from SOAP Header of inbound payload in Moni.

No Arguments Please! 😉 While creating the UDF don’t pass any arguments because we don’t want to feed any input to it. See below picture.



In side the UDF code it is important to mention the correct “DCJMSMessageProperty” for which you want to retrieve the value from payload. Here in my case I want to get the value of “ContractId” so I have used “DCJMSMessageProperty1“.


Also for each additional JMS property you have to create a separate UDF if you want to retrieve the value in your mapping separately. But of course you can always create only one UDF and can get multiple DynamicConfig values. So it all depends upon your requirement.




UDF Code:-


Step 4. After doing appropriate mapping & configuration, scenario is ready for Testing.

Before we start testing, there is one thing which is important that if we test the scenario directly from Run Time Work Bench (RWB) Message Monitoring then we will not see the DynamicConfiguration under SOAP Header of inbound payload in MONI and mapping will fail. 

Also testing the UDF under test tab will not show any results.  

Mapping will show results only at run time. So only end-to-end testing will help to get the results. 

Once we do end-to-end testing we can see the values under DynamicConfiguration of inbound payload in MONI, which will be fetched up by the UDF at run time in message mapping.



Be the first to leave a comment
You must be Logged on to comment or reply to a post.