ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.
Cadet 3rd Class
Cadet 3rd Class

XDS code for input transformation policy to understand/parse XML input from Messaging queue

Hello ,

I wanted to know the XDS code to be written in input transformation policy to understand XML input coming from MQ(messaging queue ) on publisher channel from success factor application.

Inputs are coming from application-->MQ in XML format




Labels (1)
4 Replies
Vice Admiral
Vice Admiral

You create the transformation to convert the input you receive from an application over into an NDS document.  This is typically done with DirXML or XSL.  If you post a sample of what you're getting, I may be able to help you understand one way to attack parsing it.

Robert Ivey
GCA Technology Services
Cadet 3rd Class
Cadet 3rd Class

Thanks for your response Rivey.


Here is what i am receiving.


the input we are receiving from MQ. We need to do transform these to IDM Driver understandable attribute/values.

<nds dtdversion="3.0" xmlns:jms="urn:idm:jms">


    <jms:message event-id="ID:414d512056434330bfa85dd748e925" jms:received-from="ibm2344.CorpID.RQST">


        <jms:header jms:name="JMSCorrelationID">50c48b66-f40c-11e9-c9f3-00000bfb7cc3</jms:header>

        <jms:header jms:name="JMSDeliveryMode">2</jms:header>

        <jms:header jms:name="JMSExpiration">0</jms:header>

        <jms:header jms:name="JMSMessageID">ID:414d512056434330bfa85dd748e925</jms:header>

        <jms:header jms:name="JMSPriority">4</jms:header>

        <jms:header jms:name="JMSRedelivered">false</jms:header>

        <jms:header jms:name="JMSTimestamp">1571666934442</jms:header>



        <jms:property jms:name="JMS_IBM_Format">MQSTR</jms:property>

        <jms:property jms:name="JMS_IBM_PutDate">20191021</jms:property>

        <jms:property jms:name="JMS_IBM_Character_Set">UTF-8</jms:property>

       <jms:property jms:name="JMSXDeliveryCount">1</jms:property>

        <jms:property jms:name="JMS_IBM_MsgType">8</jms:property>

        <jms:property jms:name="JMSXUserID">mqm</jms:property>

        <jms:property jms:name="JMS_IBM_Encoding">273</jms:property>

        <jms:property jms:name="JMS_IBM_PutTime">14085444</jms:property>

        <jms:property jms:name="JMSXAppID">WebSphere MQ Client for Java</jms:property>

        <jms:property jms:name="JMS_IBM_PutApplType">28</jms:property>

        <jms:property jms:name="Novell_IDM_MessageType">text</jms:property>

        <jms:property jms:name="Novell_IDM_ContentType">xml</jms:property>



        <ns0:MT_ibm2344_CreateCorpID_Request event-id="ID:414d512056434330bfa85dd748e925" jms:received-from="ibm2344.CorpID.RQST" xmlns:ns0="">



























Vice Admiral
Vice Admiral

I recommend creating an OOTB DSML SOAP driver and inspecting two policies in the input transform.  Both are XSL policies for converting SOAP messages into NDS events.  While it isn't exactly what you're looking for, it is essentially doing the same thing.

Don't use the SOAP driver, simply create it with default settings and the DSML base package.  Once it has been created, go look at:

- NOVLDSML-its-SOAPInputTransform - this policy skips all of the SOAP headers.  I'm not sure if you need any of your jms:headers, but if you don't, that policy will give you a good template for ignoring them.

- NOVLDSML-its-DSMLInputTransform - this policy goes through the XML of the SOAP body and converts each attribute over into appropriate NDS elements to be processed by DirXML throughout the rest of the policies.  You're data points don't look too complicated.  The for-each loop looking at dsml:attr could probably be quickly converted into a for-each to look at each child element under Employee.

XSL can be a pain in the rear, I don't use it too frequently and when I do, I typically have to relearn a few aspects of it, apply them, then forget about them over the next few months while I'm not writing XSL.  Samples are your best friend.  I personally would retrofit these two mentioned policies to get the job done.

Robert Ivey
GCA Technology Services
Vice Admiral
Vice Admiral

I avoid XSLT like the plague. It's a complicated declarative language which is hard to grasp for traditionally trained procedural language developers. You have to think sideways.

I have developed a reusable framework for transforming SOAP XML to XDS we call LiQuiDSOAP(tm) - a Lightweight, Quick Deployed SOAP model. It originally ran using the SOAP shim and the only thing we preserved from deliverable functionality was the stylesheets to remove and apply the SOAP envelope. Part of the methodology to use this relies on SOAP UI and getting a WSDL for the service to make it easier.

I would get comfortable with XPath, understand the XPath explorer in Designer, then familarize yourself with the XML tokens which are your friend. Once you get those under your belt you can avoid XSLT in most cases. 

Since we originally deployed this for a client 6 years ago, we have built a dozen different drivers using this approach, and we now have developed our own Shim to add new functionality useful for particular drivers.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.