XDS code for input transformation policy to understand/parse XML input from Messaging queue
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
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.
GCA Technology Services
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:property jms:name="JMSXAppID">WebSphere MQ Client for Java</jms:property>
<ns0:MT_ibm2344_CreateCorpID_Request event-id="ID:414d512056434330bfa85dd748e925" jms:received-from="ibm2344.CorpID.RQST" xmlns:ns0="http://ibmmqmqint.com/xi/HR/ibm2344_SAP2IDM_CreateCorpID_Request">
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.
GCA Technology Services
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.