User App, SOAP Integration activity interesting error
Novell's Identity Manager product has a couple of major parts to it. Of course with Identity Manager 4.0 coming out soon there are more components coming, but for now lets address the simpler model we have with the Identity Manager 3.6.1 release.
There are really two major pieces to the puzzle, and when you spend time in either part, you recognize the commonality, until you have to switch to the other side. The first is the more traditional event driven policy side. That takes events from a remote system, filters, processes, and sends them to the Identity Vault. And the converse. Then there is the second component that handles more of user interaction, the Provisioning side. This allows a user to request access to a resource can handle approvals and what not. This has evolved into a much more coherent and comprehensive solution. In fact many of the new features coming in the next release of Identity Manager will be working through the Provisioning side.
The thing about Provisioning is that it is a really big space. There is so much going on with it. I tried to explain some of that complexity in this series of articles:
- Introduction to Workflows and PRDs in Identity Manager - Part 1
- Introduction to Workflows and PRDs in Identity Manager - Part 2
I am not sure I really covered it, since I missed Roles, Resources, Teams, and much of the DAL in that article series. Anyway, I think we need more articles on the product and some of the various issues involved in running it.
The more I work in this space, the more interesting error messages I run into, and I think are worth spending some time talking about. I recently posted a discussion about errors that occur in starting a User Application JBoss application server instance in the article:
I like writing articles about error codes and error events, since I hope that others who run into it will pop some string into the Google search box and find my article which might help them with the problem.
Some of my error code articles can be found at:
AD driver related:
- Sub-Error Codes for LDAP Error 49
- 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
eDirectory driver related:
JDBC Driver Related:
- 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 related:
User Application driver related:
And many other articles. You can find my entire collection of 200+ articles at:
Recently I was working on a system where we actually made a Cancel a Running Workflow workflow. Sounds silly right?
Well it turns out, if you want to cancel a running workflow in a DirXML Policy, there is no token Cancel Workflow. There is a Start Workflow token. This is basically a wrapper around the SOAP call, and it behaves very much like you would do it in soapUI or something that supports making SOAP calls.
So it is 'easy' to start a workflow, but hard to stop one. Well easy in the sense that there is a token. Turns out to be a bit of a tricky to use token, and I am working on more articles on that process, like these:
I have more in that series. Man have I been collecting start workflow error traces! Does that mean I am doing something right, or something wrong? You be the judge!
Well to solve the Cancel a workflow problem, we made an easy to start workflow, that when passed the Request ID value, will stop the running workflow. So yes, we call a workflow to stop a workflow. You use the cards you are dealt. Heck for a variety of reasons we did a Approve a Workflow workflow as well. These are things it would be nice to have tokens to do.
This is a trivial three step workflow. Start, make a SOAP call, and Finish. As usual the devil is in the details, and the SOAP call is quite an interesting thing and probably the topic of its own complete article. If ever you use the Integration Activity in a Workflow, you will see a very different view in Designer. This is about all that remains of the SilverStream Composer tool that was let fade into the sunset. Composer was basically an XML mapping tool, that had an astonishingly complex UI to use. (If you think Designer's Provisioning view has a tough User Interface (UI) then you never saw Composer!) You get a small segment of it in the Integration Activity, and I wish we had more of it available to use in IDM these days! The next best thing will likely be the RaDD tool (Rapid Driver Development tool) from Omnibond, the guys who brought us the Fan out and Bi-directional Unix, Linux, Mainframe (RACF, Top Secret, and ACF2), and Midrange (AS400, aka i5os) drivers as well as the Scripting driver. They were talking about it at BrainShare and I am very much looking forward to getting my dirty little paws on it as soon as it is available! You can read more about it at:
Anyway, one of the things the Integration Activity needs is a WSDL file, the Web Services Descriptor Language file. This basically provides a definition (in XML of course, these are Web Services after all) of the available web services being provided.
Well it turns out the User Application has both SOAP and REST interfaces. I have yet to play with REST, but am getting deeper and deeper into SOAP with User Application. When you log into the User Application web page as the User App administrator, on the Administration tab you should see a Web Services pane on the bottom left. You can download the WSDL files for each of the User App components. There are WSDLs for:
Directory Layer Service
For this function, you need the Provisioning WSDL. When you drag an Integration Activity onto your Provisioning Request Definition's (PRD) workflow pallet, you get asked immediately for a path to the WSDL file. You browse your file system, and find it. It gets parsed, and you get a list of functions made available according to the WSDL's definitions. Now when you look in the Properties tab, when the Integration Activity is highlighted there is a WSDL path item. Alas, it does not seem editable after it is set. Indeed, to make it worse, if you check your project into SVN (Subversion, a Version Control package that Designer supports) the path is part of the code that comes to a new Designer instance, if you import the project from SVN, but the file path on Linux and Windows would be radically different (c:\projects\acme\provisioning.wsdl vs /opt/acme/data/wsdl/provisioning.wsdl).
If you are not using SVN, you are missing an opportunity to both back up your work, but also to manage changes, in case you need to revert back to get some old code versions. Version control is really important, and it forms if absolutely nothing else a form of backup. But more so, in the case of Policy stuff, it is pretty easy when making major code changes, to copy the current mostly working rule, disable one copy, and work in the new copy so that you can easily fall back if you make a mistake.
In Provisioning this is much harder, and often simple changes can require complex changes. With SVN you could revert back, grab some code you changed in a way that ended up being incorrect, move forward back to the current project state, and paste the pieces back in.
But if you are using SVN, then the file path issue becomes an issue when you try to work on a different machine. We ran into this recently at a client, where Designer started showing this error as soon as we tried to open the Provisioning Request Definition (PRD) for the Cancel a Workflow workflow:
at com.novell.prov.pal.ui.actions.handler.ProvActionHandler.handleOpenAction(Unknown Source)
at com.novell.prov.pal.ui.actions.handler.ProvActionHandler.handleAction(Unknown Source)
at com.novell.prov.pal.ui.provview.views.ProvisioningView$6.run(Unknown Source)
at com.novell.prov.pal.ui.provview.views.ProvisioningView$8.doubleClick(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
As usual with Java errors, the final error is often not that useful. You can see this by focusing in on the first three lines of the error message:
Null Pointer Exception seems like the most common Java error I run into and is functionally meaningless, beyond telling you that the value it was given to look at is missing or incorrect. Oh well. However, if you look at the function classes that are in the Java stack, you can see a number of things. First lets look at the basic class path for most of these calls, which is:
Well lets break that down. The first part, com.novell makes it clear that although we are working in Designer which is really a Java application environment called Eclipse with custom plugins from Novell, this is a Novell class being called that is erroring.
Next we see 'soa', which I think stands for Service Oriented Architecture, which is really another way of saying Web Services, or at least a model of a multi tier system, in which web services are often involved.
Enterprise Application Integration, 'eai' is yet another flavour of SOAP related functionality. I do not know the correct words for each of these pieces along the way, but it is sufficient to know this is all SOAP related.
integrationActivity.impl.IntegrationActivity is the next part and makes it clear what part of the functionality we are working in. This is all about the SOAP integration activity we are using inside the PRD.
Finally, lets look at the first few functions within that Integration Activity class that are involved. We have:
You actually read these sometimes from the bottom up, other times top down. Starting all the way at the bottom is too much information, as who cares if it is related to drawing a window or some other low level Eclipse function. Usually what we want it is at the top of the stack. But once you are at the top, you want to read the last 3-6 items from the bottom up.
EMF is the Eclipse Modeling Framework, which is how Eclipse (The underlying environment that is Designer) reads and manages data. So when we see readEMF being called, we know it is reading some kind of information for the window about to be opened as an Eclipse window. Read then setup make sense as being the next logical steps.
Finally we get to the heart of the issue, the setOriginalWSDLDoc, well in my case, I was running Designer 3.5.1 on Windows XP, and my colleague who had checked in the project to our shared SVN server was running 64 bit Open SUSE on his laptop. Obviously the path to the WSDL is different on Linux than it would be on Windows as I gave the example earlier.
Now as it turns out if you edit the PRD file in a text editor, from within the Designer Workspace, you can see the actual line that defines the file. Hehe. I love editing files raw. You do need to be careful, since the file contains the localization information, and if you save it incorrectly you will loose all your localization information.
What we did was copy the file to a local path, and then edit the PRD file to point at the right location.
What I found interesting was that the Integration Activity is stored within that PRD as a Base64 encoded string and it looks like the contents of the WSDL functions are included in the definition, so having the file seems kind of redundant. But Designer will error if you do not have it correctly when you try and open the PRD.
Hopefully if anyone else runs into this issue, it will help you figure out what is going on faster. More importantly I hope that the approach I took in figuring out what was happening in the unhelpful top level error (Null Pointer Exception) by looking at the Java stack trace will be useful in figuring out what is causing other errors you might run into.