Response from SOAP driver on publisher channel

Hello,

I would like to add to the response that the soap driver returns when a document is sent through the publisher channel. For example, a typical response when a user ID is sent through the publisher channel and an ID is created in eDirectory:

<soap-env:Envelope xmlns:soap-env="">schemas.xmlsoap.org/.../">
<soap-env:Body>
<batchResponse xmlns="urn:oasis:names:tc:DSML:2:0:core" xmlns:xsd="">www.w3.org/.../XMLSchema" xmlns:xsi="">www.w3.org/.../XMLSchema-instance">
<errorResponse requestID="none" type="success">
<message>DirXMLwdStudio (\IAMT-WD-VAULT\OSU\vault\users\IDM800011)Publisher</message>
<detail>success</detail>
</errorResponse>
</batchResponse>
</soap-env:Body>
</soap-env:Envelope>


I would like to add other attributes that were not necessarily part of the original document. For example:

<soap-env:Envelope xmlns:soap-env="">schemas.xmlsoap.org/.../">
<soap-env:Body>
<batchResponse xmlns="urn:oasis:names:tc:DSML:2:0:core" xmlns:xsd="">www.w3.org/.../XMLSchema" xmlns:xsi="">www.w3.org/.../XMLSchema-instance">
<errorResponse requestID="none" type="success">
<message>DirXMLwdStudio (\IAMT-WD-VAULT\OSU\vault\users\IDM800011)Publisher</message>
<detail>success</detail>
</errorResponse>
<field1>blablabla</field1>
<field2>abc simple as</field2>
<field3></field3>
</batchResponse>
</soap-env:Body>
</soap-env:Envelope>


how can I add to the response. I cannot be that hard. Some sample code would be highly appreciative.

Thanks in advance,
Frank
  • Yes, it should be easy. Wherever you have your (likely) XSLT to convert
    XDS back to the SOAP envelop you could just add a few more lines to add in
    those hard-coded values. If you have a full level three (3) trace to
    share, we could probably help you identify the name of the policy,
    assuming it is not one of the defaults.

    Also if you could share a business case for what end this achieves, that
    may be useful just to fully understand the options available within IDM.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • Hello,

    Thanks for your reply. As far as the business case, we are bringing up Workday and are using a SOAP driver to which Workday connects and gives us a document. From the response to the initial connection to the publisher channel, Workday needs a response for certain attributes from the vault side: DEVPSEmplID, DEVnewNameN and DEVidmId. Unfortunately, we have not figured out a way so that Workday sends a document to the publisher and then listens on the subscriber channel.

    Unfortunately, the level 3 trace is too long to paste here (almost 4 times too big). Is there another way to add the trace? It is 346K (27K compressed).
  • Hello again,

    after some trial and error, I have found the section of code (located in the Output Transform: NOVLDSML-otp-SOAPOutputTransform) where I can put the attributes into the response:

    <xsl:template match="add|modify|delete|rename|move|query|output/status">
    <xsl:choose>
    <xsl:when test="operation-data/return-to-me[@command='heartbeat']">
    <xsl:message>Output: Do not add SOAP header to heartbeat</xsl:message>
    <xsl:copy>
    <xsl:apply-templates select="node()|@*"/>
    </xsl:copy>
    </xsl:when>
    <xsl:when test="operation-data/return-to-me[@command='remote-loader-query']">
    <xsl:message>Output: Do not add SOAP header to remote loader query</xsl:message>
    <xsl:copy>
    <xsl:apply-templates select="node()|@*"/>
    </xsl:copy>
    </xsl:when>
    <xsl:when test="operation-data/return-to-me[@command='check-password']">
    <xsl:message>Output: Do not add SOAP header to check-password</xsl:message>
    <xsl:copy>
    <xsl:apply-templates select="node()|@*"/>
    </xsl:copy>
    </xsl:when>
    <xsl:otherwise>
    <xsl:message>Output: Add SOAP Headers</xsl:message>
    <soap-env:Envelope xmlns:soap-env="">schemas.xmlsoap.org/.../">
    <soap-env:Body>
    <xsl:copy>
    <xsl:apply-templates select="node()|@*"/>
    </xsl:copy>
    << believe my stuff goes here >>

    </soap-env:Body>
    </soap-env:Envelope>
    </xsl:otherwise>
    </xsl:choose>
    </xsl:template>


    I am not familiar with XSL coding... so I am not sure on the to put into the section in question. How would I reference the following variables: DEVPSEmplID, DEVnewNameN and DEVidmId

    and is there a way to check to see if these have attribute have any variables in them?

    Thanks in advance for your help.
  • You can paste it somewhere like SUSE Paste, or PasteBin, or whatever, and
    then just post the link to that here for review.


    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • After you pass through the stylesheet that extracts the payload from the SOAP envelope, you can add an XML script based rule. Your current context should be batch-response. That would match the condition, "if operation equals batch-response". So that's the first step in a rule.

    That means that the xpath expression "." which represents the current context is batch-response, so if you do

    if operation equals batch-response
    append XML element, element name "field1", XPath expression ".",
    append XML text, XPath expression "field1", string "blablabla"
    append XML element, element name "field2", XPath expression ".",
    append XML text, XPath expression "field2", string "abc simple as"
    append XML element, element name "field3", XPath expression ".",

    you should be able to accomplish your example.

    BTW, I've developed and deployed a mature, fully featured Workday driver which supports all kinds of cool features like a highly automated configuration for workday setup, event driven push to IDM, bidirectional communications, workers and contingent workers as well as transitions between them, synchronize whatever attributes you wish including pictures, reference synchronization (locations, departments, contingent worker types, time zones, you name it) to roles and role assignments, effective dated transactions, and way more at several different clients (which doesn't rely on XSLT except for the one OOTB unmodified stylesheet that strips off or adds the SOAP envelope).