Novell Identity Manager has a bunch of drivers. The documentation for the various functionality in the drivers has varied from version to version. As a person who has to implement and deeply understand the inner workings of these drivers I often find the documentation lacking in things I would like to see.

Personally I would like to see the troubleshooting section of each driver doc enlarged to the point where it is possibly larger than the rest of the document. After all, we spend more time troubleshooting issues, in the real world, than in implementing the drivers. Or at least it feels that way.

You would think a link to articles or TIDs at least would be handy to have in the docs. Alas, I also understand that documentation writers cannot really satisfy this requirement of mine, but that does not mitigate the need for such documentation. Thankfully Novell has the Cool Solutions approach, where community contributed content can try and help cover some of the weak areas.

Since Novell will not fix the issue, I have decided to put my money where my mouth is, and do my best to help out.

When I work with a driver, I almost always run into some kind of problem. The trick is, find the problem in trace, copy the text of it, and save it somewhere. Then you have a record of what happened, and how you fixed it.

I have written a number of articles on a variety of drivers, trying to show sample error documents, explain what happened, and how you might fix it, using my approach of collecting error messages. You can read some of those at:

AD Driver:

• Active Directory Driver Error Messages - Part 1

• Active Directory Driver Error Messages - Part 2

• Active Directory Driver Error Messages - Part 3

• Active Directory Driver Error Messages - Part 4

• Active Directory Driver Error Messages - Part 5

eDir Driver:

• Error Codes of the eDirectory Driver for Identity Manager - Part 1

GW Driver:

• Troubleshooting GroupWise Driver External User Creation

JDBC Driver:

• Error Codes of the Novell Identity Manager Driver for JDBC: Part 1 of 4

• Error Codes of the Novell Identity Manager Driver for JDBC: Part 2 of 4

• Error Codes of the Novell Identity Manager Driver for JDBC: Part 3 of 4

• Error Codes of the Novell Identity Manager Driver for JDBC: Part 4 of 4

SAP HR driver:

• http://www.novell.com/communities/node/9271/error-codes-sap-hr-driver-identity-manager-part-1

User App:

• http://www.novell.com/communities/node/11931/user-app-soap-integration-activity-interesting-errors

SOAP:

There are more generic troubleshooting tips in my collection of articles as well, but this is mainly a list of the specific error code articles.

Recently I was working on a SOAP driver to talk to Salesforce.com, and had collected some errors I would like to talk about. You can read my series on building such a SOAP driver from scratch at the links below. Now while the series focused on Salesforce.com's particular API, the information in the article can be extrapolated to most any SOAP interface you need to work with.

• Getting Started Building a SOAP Driver for IDM - Part 1

• Getting Started Building a SOAP Driver for IDM - Part 2

• Getting Started Building a SOAP Driver for IDM - Part 3

• Getting Started Building a SOAP Driver for IDM - Part 4

• Getting Started Building a SOAP Driver for IDM - Part 5

• Getting Started Building a SOAP Driver for IDM - Part 6

• Getting Started Building a SOAP Driver for IDM - Part 7

• Getting Started Building a SOAP Driver for IDM - Part 8

• Getting Started Building a SOAP Driver for IDM - Part 9

Some of these errors are specific to Salesforce.com, and others are more generic and related to SOAP in general. So lets dig into some error messages.

While I was working on that Salesforce.com (SFDC) driver, we did a lot of workflow stuff. Along the way, we realized that while there is a very useful Start Workflow token in Policy, there is no corresponding Stop Workflow, nor Approve Workflow token. To resolve this lacking, we made a pair of workflows. One called Cancel Workflow, and one called Approve Workflow. They are very simple and use the SOAP Integration Activity that is available within the Provisioning side of IDM, to make SOAP calls to the User Applications SOAP end point.

So follow me on this one. We used a Start Workflow token in Policy, which is really just a SOAP call to start a workflow, that calls a SOAP function to approve or cancel another workflow, using a SOAP integration activity. On the one hand that sounds silly, but on the other hand, it seems to work pretty well.

I need to find the time to write an article about those two workflows as it is an interesting discussion to have. As I was getting those two workflows working, I ran into a number of issues. If you look at the errors that SFDC throws in the first part of this error code series, you will see, when you compare to the errors that User Application throws, why I wish Novell took after SFDC more, in this aspect. (Not that I am a big fan of Salesforce.com. They have their odd quirks as well).

It turned out that Cancel a running workflow was pretty easy to do, and high on the thrill of having accomplished that in under an hour I was all ready to tackle Approve a workflow. Well turns out, that was not as easy. It is actually a two step process. Along the way I found all sorts of fun errors.

I had retrieved the WSDL from User Application, and opened it in soapUI (A great tool for working with SOAP!) and tried to understand it, so I was sending it, and getting responses.

The WSDL for User Application is not as self descriptive as the WSDL that SFDC provides, so I was left guessing often at what arg3 or arg0 was supposed to be. The documentation sort of contains the information, but is written more for someone who already knows what is going on, and is not really clear for beginners. Turns out arg0 is for the work entry ID of the running workflow you want to approve, arg3 is the string to go in the Approval comment, but I was not sure what the EntitlementState node was for, so I left it commented out.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://www.novell.com/provisioning/service">
   <soapenv:Header/>
   <soapenv:Body>
      <ser:setResultRequest>
         <!--Optional:-->
         <ser:arg0>c31756d637474984a8d8bc04d8d33b0a</ser:arg0>
         <!-- <ser:EntitlementState>?</ser:EntitlementState> -->
         <ser:EntitlementStatus>Success</ser:EntitlementStatus>
         <!--Optional:-->
         <ser:arg3>Approved by the IDM 3.0 system</ser:arg3>
      </ser:setResultRequest>
   </soapenv:Body>
</soapenv:Envelope>

Well, clearly User Application did NOT like that! It is interesting that it reported and EOFException, as an End of File exception seems a bit strange here. However, it does seem like it was because I left, what was flagged as optional, commented out. Would be nice to get a more informative error message, but that's life for you!

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring>no serializer found for "java.io.EOFException"</faultstring>
         <detail>
            <ns1:stackTrace xsi:type="ns1:stackTrace" xmlns:ns1="http://www.novell.com/wssdk">
               <ns1:dump xsi:type="xsd:string">com.novell.soa.ws.binding.MarshalerNotFoundException: no serializer found for "java.io.EOFException"
	at com.novell.soa.ws.impl.soap.LiteralEncodingStyle.writeObject(LiteralEncodingStyle.java:414)
	at com.novell.soa.ws.impl.xml.OutputStreamImpl.writeObject(OutputStreamImpl.java:122)
	at com.novell.soa.ws.impl.soap.ServerResponseImpl.writeException(ServerResponseImpl.java:81)
	at com.novell.soa.af.impl.soap.Provisioning_ServiceSkeleton._invoke(Provisioning_ServiceSkeleton.java:2583)
	at com.novell.soa.ws.server.ServletSkeleton.invokeEndPoint(ServletSkeleton.java:208)
	at com.novell.soa.ws.impl.soap.MessageHandlerInvoker.invokeServerMessageHandlers(MessageHandlerInvoker.java:348)
	at com.novell.soa.ws.impl.soap.SOAPHandler.handleServerRequest(SOAPHandler.java:84)
	at com.novell.soa.ws.impl.rpc.ServerDelegateImpl.handleServerRequest(ServerDelegateImpl.java:92)
	at com.novell.soa.ws.server.ServletSkeleton.handleRequest(ServletSkeleton.java:107)
	at com.novell.soa.ws.server.ServletSkeleton.doPost(ServletSkeleton.java:317)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.JAASFilter.doFilter(JAASFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.saml.AuthTokenGeneratorFilter.doFilter(AuthTokenGeneratorFilter.java:90)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.sso.SSOFilter.doFilter(SSOFilter.java:91)
	at com.novell.common.auth.sso.SAPFilter.doFilter(SAPFilter.java:37)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.sso.SSOFilter.doFilter(SSOFilter.java:91)
	at com.novell.common.auth.sso.KerberosFilter.doFilter(KerberosFilter.java:49)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.soa.common.i18n.BestLocaleServletFilter.doFilter(BestLocaleServletFilter.java:233)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)</ns1:dump>
            </ns1:stackTrace>
         </detail>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Since I could not find any good docs on how to do what I was trying it was off to the merry go round of trial and error. If leaving out the EntitlementState throws an error, that looks like an End of File error, then looks like it needs to be included, so ok, lets include it. What value to send? I dunno. So lets try a null value. This is probably going to fail, but lets see if we get a different or more informative response from the User Applications SOAP end point.

Sent in the document below with <ser:EntitlementState> left with a null value.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://www.novell.com/provisioning/service">
   <soapenv:Header/>
   <soapenv:Body>
      <ser:setResultRequest>
         <!--Optional:-->
         <ser:arg0>c31756d637474984a8d8bc04d8d33b0a</ser:arg0>
         <ser:EntitlementState></ser:EntitlementState>
         <ser:EntitlementStatus>Success</ser:EntitlementStatus>
         <!--Optional:-->
         <ser:arg3>Approved by the IDM 3.0 system</ser:arg3>
      </ser:setResultRequest>
   </soapenv:Body>
</soapenv:Envelope>

Got a different exception, illegal argument exception, which is a good sign! Had it still been an End of File error then I would have suspected something else as the cause. Sometimes a different error can be a good sign as well!

Sometimes the stack trace is interesting and useful, and sometimes, not so much. Might be a hint that last calling function of interest was: LiteralEncodingStyle.writeObject and that might not like null values at all.

<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring>no serializer found for "java.lang.IllegalArgumentException"</faultstring>
         <detail>
            <ns1:stackTrace xsi:type="ns1:stackTrace" xmlns:ns1="http://www.novell.com/wssdk">
               <ns1:dump xsi:type="xsd:string">com.novell.soa.ws.binding.MarshalerNotFoundException: no serializer found for "java.lang.IllegalArgumentException"
	at com.novell.soa.ws.impl.soap.LiteralEncodingStyle.writeObject(LiteralEncodingStyle.java:414)
	at com.novell.soa.ws.impl.xml.OutputStreamImpl.writeObject(OutputStreamImpl.java:122)
	at com.novell.soa.ws.impl.soap.ServerResponseImpl.writeException(ServerResponseImpl.java:81)
	at com.novell.soa.af.impl.soap.Provisioning_ServiceSkeleton._invoke(Provisioning_ServiceSkeleton.java:2583)
	at com.novell.soa.ws.server.ServletSkeleton.invokeEndPoint(ServletSkeleton.java:208)
	at com.novell.soa.ws.impl.soap.MessageHandlerInvoker.invokeServerMessageHandlers(MessageHandlerInvoker.java:348)
	at com.novell.soa.ws.impl.soap.SOAPHandler.handleServerRequest(SOAPHandler.java:84)
	at com.novell.soa.ws.impl.rpc.ServerDelegateImpl.handleServerRequest(ServerDelegateImpl.java:92)
	at com.novell.soa.ws.server.ServletSkeleton.handleRequest(ServletSkeleton.java:107)
	at com.novell.soa.ws.server.ServletSkeleton.doPost(ServletSkeleton.java:317)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.JAASFilter.doFilter(JAASFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.saml.AuthTokenGeneratorFilter.doFilter(AuthTokenGeneratorFilter.java:90)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.sso.SSOFilter.doFilter(SSOFilter.java:91)
	at com.novell.common.auth.sso.SAPFilter.doFilter(SAPFilter.java:37)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.common.auth.sso.SSOFilter.doFilter(SSOFilter.java:91)
	at com.novell.common.auth.sso.KerberosFilter.doFilter(KerberosFilter.java:49)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at com.novell.soa.common.i18n.BestLocaleServletFilter.doFilter(BestLocaleServletFilter.java:233)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)</ns1:dump>
            </ns1:stackTrace>
         </detail>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

So now I know I need the optional attribute (not so optional is it?) and that it cannot be null. Lets try what look like a valid value, Granted. Since this is all about EntitlementStatus.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://www.novell.com/provisioning/service">
   <soapenv:Header/>
   <soapenv:Body>
      <ser:setResultRequest>
         <!--Optional:-->
         <ser:arg0>c31756d637474984a8d8bc04d8d33b0a</ser:arg0>
         <ser:EntitlementState>Granted</ser:EntitlementState>
         <ser:EntitlementStatus>Success</ser:EntitlementStatus>
         <!--Optional:-->
         <ser:arg3>Approved by the IDM 3.0 system</ser:arg3>
      </ser:setResultRequest>
   </soapenv:Body>
</soapenv:Envelope>

Well would you look at that? This time it worked, and accepted it.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <SOAP-ENV:Body>
      <ns1:setResultResponse xmlns="http://www.novell.com/provisioning/service" xmlns:ns1="http://www.novell.com/provisioning/service"/>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Now as it turns out, I was using the wrong API call out the WSDL, and had to change over, but the same basic principles all apply. Need to understand what the application is expecting, when the WSDL, nor the documentation make it sufficiently clear. Trial and error can quickly discover a fair bit of information. The issue for approving a workflow was, what did you have to start with? Well we had our other workflows write out the request ID value onto the user objects. Initially we did it with just a single valued attribute, but we realized we should use a multi valued Path syntax attribute instead, so we could store the DN of the workflow for which the Request ID was related too. Useful information to have, so you can decide if there is a workflow you want to cancel, since users might have many workflows running at any moment in time. But you cannot approve a workflow by request ID, or at least if you can, I have no idea how. But you can approve it by work entry ID. Which you can get if you have the request ID. So my Approve a Workflow workflow had two SOAP integration activities. First a call to getWorkEntriesRequest which takes the request ID and gets back the work entry ID.

Then the second one takes the results of the first and passes it into forwardRequest, which takes the work entry ID to identify the workflow.

Still a bit Rube Goldberg'esque, but whatcha gonna do? Gotta get the stuff working, right? Also it turned out to be a lot of fun to get going.

Using a SOAP integration activity is mildly challenging, as it is a hold over from the Silverstream Composer application, which was really cool, but had a UI that to be polite was less than optimal. Composer could do a large number of things, but was primarily an XML mapping tool. It was designed to convert data in one XML format to another. Sort of a natural fit for IDM, right? Alas it has languished and fallen by the way side. One of the really interesting things it could do was to actually work as a screen scraper. You could build a driver using it, that would read and push characters into a TN3270 terminal session. We actually built a 3270 and two HTML screen scrapers with it. Lots of fun, very challenging, but amazingly powerful. The planned replacement for much of its functionality is the Rapid Driver Development toolkit from the good folk at Omnibond. (www.omnibond.com). They are the guys who wrote the various fanout and bi-directional drivers. (Linux, Unix, AS400 (aka i5os, aka midrange), mainframe (ACF2, RACF, Top Secret)) and the scripting drivers. They also have Sentinel collectors for midrange and mainframe boxes available. Check them out. Their drivers are really well done, and nice to work with. In fact, they have their own version of the remote loader (for use on Unix, Mainframe, and AS400) that has a trivially simple approach to getting the trusted root certificate for SSL to work. This is probably the hardest part about setting up a remote loader. Getting the trusted root for the signing trees Certificate Authority into the remote loaders trusted keystore. It confuses most people the first few times. The Omnibond guys said, there's a better way. Its so simple you wonder why Novell has not implemented it yet! They ask you for the IP address (name or number, whatever will work) of an LDAP server in the tree that supports LDAP over SSL. They do a Start TLS, get through the certificate exchange, and snag a copy of the Certificate Authorities trusted root public key. In other words, to configure it, you tell it the IP of an LDAP server in the tree, and it is done. No fuss no muss. Way easier than remembering to get a DER formatted file for Java remote loaders, and a Base 64 encoded version for Windows remote loaders. Or remembering the keytool syntax to import the .DER file into the java/lib/security/cacerts keystore. Or else into your own custom keystore. None of this is hard, just unnecessarily complex. The Omnibond approach is simplicity in itself! I am greatly awaiting the release of RaDD, so I can play with it! It sounds like it is going to be a ton of fun, and open up a whole new class of applications that can be integrated into IDM.

Anyway. having used Composer before, I was fairly familiar with it, and it was straight forward. One key thing to note is that XPATH in IDM Policy and XPATH in the SOAP integration activity have a single major difference. In the SOAP integration activity, the current context is the absolute root, unlike in IDM Policy, where the current context that XPATH works from is the event node. (I.e. <instance> or <add> or <modify> or the like).

As you can see, there is lots of stuff to do in a SOAP driver, and lots of possible errors to deal with! Hope some of these have helped you out. If you run into any interesting errors, please consider returning the favour by writing it up in any format, and getting it published and out there for all of us to benefit from!