Introduction to Workflows and PRDs in Identity Manager Part 1:
I was looking through my collection of articles on the various Novell topics (http://wiki.novell.com/index.php/Geoffrey_Carman's_personal_collection) and noticed a nice gapping hole in my coverage.
While I have written about 20 or so different drivers (or driver categories) I have missed on piece of the Identity Manager solution almost entirely. That is the Provisioning side.
I think the reason has been that the Provisioning side feels so different from the rest of Identity Manager that it sometimes feels like another product, and at some level that is true. However with each release the integration between the two halves has gotten better and better. In fact you can see the two pieces merging closer and closer as time goes on, which I think is a good thing.
With all the great new stuff coming in Identity Manager 4.0 this takes a step further, and we can see that a lot of the new functionality is relying on the base laid down by the Provisioning half, and crossing over into both spheres. (The details are tricky and may have to wait for the full release before talking about them).
The first thing to understand is how Provisioning works. If you are used to Identity Manager drivers, this is a different world. The design tool is still Designer, but you use a different view and editor that looks nothing like what you are used to. Additionally there is so much to the Provisioning side that sometimes the user interface (UI) can be very confusing. Lets see if we can help out a bit.
There are several core components:
The User Application is the web portal that you interact with when using Provisioning. The UA runs as a WAR file inside a Java Application server (Default is JBoss, but IBM's WebSphere, and WebLogic are support as well). You login with eDirectory credentials, and the configuration data for the User Application is mostly stored in eDirectory, but there is a database that stores some of the configuration and most of the information about workflows in progress (Default is MySQL but there is additional DB support).
The User Application driver looks a regular driver and there is not much in the way of policy in it. It serves two purposes. It is a place to store configuration data in the directory, like the PRD (Provisioning Request Definitions), the Roles catalog, the Resources catalog, the DAL (Directory Abstraction Layer) definition, and it is a place for queries into the engine to run.
From the driver view, there is a Provisioning view in Designer, which you should have in the small window below the fishbone diagram, but if you do not you can open it from the Window menu, Show view item, Provisioning selection.
Novell ships a stack of sample template PRD's with Designer, which is great since you can start with one and modify, instead of starting from scratch. They have simple examples like no approval needed, to a 5 approval parallel workflow, where each workflow needs to be approved by five different people, before it proceeds. Clearly a nonsense example, but then again, there are a lot of nonsense business practices out there.
These are PRD objects where the vast majority of the Provisioning work is done. The UI here is very busy, and there is lots to do, but first lets get some infrastructure out the way.
Before you can interact with the directory via the PRD's you need to set up and define the DAL (Directory Abstraction Layer). This is sort of confusing, because you need to identify the eDirectory attribute, get its LDAP attribute name, and in fact possibly give it a third name, to be used in the namespace that PRD's use.
If you look at the attached screen shot, you can see that in the bottom left, I have the Provisioning view shown, and have expanded the User Application item to show the DAL, PRD, Provisioning Teams, and Role Catalog objects.
Then I opened up the DAL editor.
You can see that each various object type that is of interest to the PRD is represented by an Entity. There are Lists,. Queries, and Relationships as well. Basically in each of these locations in the DAL you define information about each of these cases. In the Entity case you need to enable access (View, Edit, Create, Remove) for the system, define the naming in the General section where Display Label is that third name that the DAL exposes to the PRD.
In the Search section it uses the User container you set via configupdate.sh when you installed the User Application, and you can control some of the query information here.
Filter is really powerful as you can limit the queries with a filter in order to further control the scope.
If you expand the User entity object, you get to see all the supported attributes, and each attribute has a similar page where you control access.
There are lots of subtleties here that usually bite you bad, like forgetting to Include in Search (in the General section), and gee it does not show up when searching, or not enabling View (in Access) so gee, you cannot get values back. There is a bit of switch of directions, since we are used on the engine side to have the driver given sufficient rights, and thats done. Here we have to define those 'rights' again in the DAL.
Queries are cool, since you can create a query that is more than just a simple "Attr1=value1" style thing.
I have shown a query called App, that looks for RecordType objects, and in the Query Conditions, it requires that AppShortName has a value (contains *). Thus the results of this query will only show the values that have a value, before you do anything else. You can also do queries where the value of a specific attribute needs to match a passed in value to the query. Thus allowing you to do what I call hopping. I.e. My user object has a DN attribute called Floor, which points at a Floor object. When this query is called it would show the data on the Floors assigned to the user, having looked up the Floors referenced by the users. This is very powerful for leveraging references within the directory a real strong point of eDirectory.
There is a search root specified, to constrain the query and it is only container level deep.
Again, there is tons of subtleties that matter, but lets leave those for another article.
Finally on to PRD's. You can see in the attached image the list of default PRD's that come with Designer.
and you can see from the naming, in the Template section, there is Template4SerialApproval_TA as an example. That is a template for 4 approvals, run in serial as opposed to in parallel, and _TA means Timeout Approve, instead of _TD Timeout Deny.
You can look at one of these to see how complex they are. For fun, lets compare TemplateNoApproval
with Template5ParellelApproval_TD
while looking at the Workflow tab.
You can see how you can be really simple or really crazy complex, all with the same tool.
Now that we are starting with PRD's here comes the confusing UI. I really think they need to clean this part of the UI up. However, there is so much data being represented here that I do not know how they could actually do it. I am one of those 'Tics in Piers Anthony's world of Xanth. (How is that for an obscure reference? Any fans?)
Ok, lets dive in.
When you open a PRD to start working on it, you will see the Overview page. The things to notice are the 4 tabs on the bottom, Overview, Workflow, Forms, and Signature Declarations. There is plenty of content on each, and many subtabs on each page.
Most of the stuff here is obvious, but here is one I have seen bite people. The Status line in the middle is important. There are 4 values, Active, Inactive, Retired and Template. This example is a Template, and you would probably copy the template to start working in it, and if you do not change it to Active, you cannot start working with it in the User App interface.
User Application has its own rights model that is merged with eDirectory trustees as well, so visibility of the PRD to an end user is actually controlled by eDirectory trustees (as long as the User Application ACL's allow users to start workflows). You do need to be careful of the [Public] object having Browse rights to this container inside the User Application driver object (It is actually name cn=AppConfig if you are looking for it) as that will be sufficient to allow all users to see all the PRD's.
The workflow page is where we see the pictorial drawing of the flow.
There are a number of UI things to notice. First off, we used the bottom tab to get to the Workflow view. Then on the far left I switched from the Provisioning view to the Properties view. Then I selected an appropriate node, right clicked and selected Show Data Item Mappings.
I selected Fifth Approval, since it demonstrates much of what we need to see.
On the Properties page we see that Addressee has the string: IDVault.get(recipient,'user','manager') which is the ECMA function that PRD's provide ( IDVAult.get() ) to read data via the DAL. This approval step is addressed to the value of the manager attribute, of the user, whose DN is in the variable recipient. In other words, send the approval to the manager. You can see the same thing for the Escalation address with a more complex expression trying to decide whom to escalate this approval request too, if the Escalation Interval is reached. Each different item on a workflow can have different properties. Many of these can be ECMA expressions, thus you can do fancy tricks in each (or nothing at all!). An extreme example of that is Escalation Interval. You would assume it would just take units of time, but even that field allows ECMA, so you could read a value from the parent container say, for a custom escalation value per container.
Down below I opened the Data Item mapping view, that has two perspectives Pre-Activity and Post-Activity. This is where you take the Source expression (the data coming into this step from the preceding one) from the Target Form Field, since Approval steps are expected to start with a Form submission, at first a Request form, then later an Approval form (as we will see in the Forms pages). In the first column, Source Expression, you either specify a variable like recipient or a more complex ECMA expression that will be set as the Form values fields coming into the item in the flow.
In the Post Activity Mapping you want to click Map All to copy the data coming out of the action (Source Form Fields) into the Target expression that will get passed on.
This is confusing, and as you use it more, it does becomes clearer. I wish I had a simple analogy to make it clearer.
Another important example that can help is in the case where the five approvals converge down to a single point since we are talking about a 5 approver parallel case. If you look back at the screen shot of that you will see that Approval Condition item is where that converges. In the Properties tab there, we have a Condition Expression that is ECMA.
The screen shot shows the ECMA editor you get when doing server side ECMA. That is stuff that is going to execute on the server side. (We will see later that Forms use ECMA that execute on the client web browser, so the rules are different, just to be confusing!)
This is a nice editor that provides easy access to a bunch of built in functions like flowdata, which has information that came from the forms. In this case, since we are at the bottom of a 5 way approval, we get the output of the 5 approval workflow actions as well. Out on the far right is the Identity Vault and Role Vault, where you can query data from eDirectory via the DAL. In the middle is general ECMA functions for math, strings, etc.
You can see the ECMA here is basically to ensure that the resulting boolean value is either true or false. So they are OR'ing together all 5 approval results, and if ANY are denied, then follow the denied chain. If you look at the choices coming out of this approval, you can see they sort of did it backwards from what you might have expected. So if any DENIED then the condition is true, in which case it logs a denied action. Whereas if none are denied then the condition test is false, so it follows the False path, which is actually add the entitlement.
Well there is so much more, lets pause for part 2 for working through forms and the rest.
Support
Documentation
Learning Services
Partner Programs