In part 1 of this series I started talking about the components that make up Provisioning with Novell's Role Based Provisioning Module for Identity Manager. Hmm, that was quite the mouthful.
We discussed the major components of the solutions:
I talked about some details of the Identity Manger driver, which stores much of the configuration in eDirectory. A quick overview of the application itself (User Application) which runs in a Java Application Server (Default is JBoss) that talks to a database (Default is MySQL) to store the Workflows in process. Then I started in on how the Directory Abstraction Layer (DAL) is used.
Once we have those basics down, we can start to talk about the actual Provisioning Request Definitions (PRD). Managed to get through the Overview page, and the Workflow page. Now on to the Forms, and Signature Declarations tabs.
On the Workflow page I complained about how overloaded the User Interface (UI) is, with information in the Workflow layout itself, in the Properties tab for each item in the Workflow, and then some items having a Data Item Mapping view that you need to manage.
Here on the Forms tab, we have another example of too much information being shown. Now in this case, I think they did a much better job of it.
Looking at the screen shot, once you select the Forms tab at the very bottom, you see two subwindows. There is the Form selection that has two tabs. Request and Approval, and then the Form Controls subwindow with 4 tabs.
See what I mean about data overload!!
The good news is that while there is tons of information, it is easier to understand here.
The thing to remember is that each workflow has at least one form, the Request form. That is where you define the information needed for the workflow to start up. If you have an approval step (in our example from the first article, I was working through a 5 approver, in parallel process, there could be 5 different approval forms) you will have an Approval form as well.
These forms are web based, and will be generated by the User Application, based on the Fields, in the right hand windows Fields. The key thing to remember here is that any ECMAScript that is used in a Form is rendered client side in the browser, so the set of functions, and access to Java libraries is different than in the Workflow tab, where the ECMA is run in the server context with different functions available. Far more confusingly is that there are some functions provided in both Workflow and Forms that take different parameters in each! This is very painful, and very misleading.
Each field you add in the Fields tab adds a line to the UI, in the simplest form. Each field gets a name, (used in the Pre and Post Activity mapping in the Data Item Mapping view from the Part 1 article) a data type, (string, DN, time, integer, --Role Request--, --Resource Request--, and others) and a control type. There are many control types, and each has it subtle features. Yet again the Properties window comes into play as each field has a properties page in left hand side.
Here is where the ability to do funky things starts to come in. In the properties of each form field, there is an Events item. When you select it, you get a Field Events pop up box, that lets you add and modify multiple events. You need to click the plus sign to add one, then you can select the specific event you want to add ECMA for. For example, you get:
As you can see you get a LOT of possible events to handle, and multiple events per field. Each event has an Action Expression associated with it, which means when the event triggers, you can add ECMA to do some additional magic.
Thus this unsupposing little Form builder, that looks so simple and unsophisticated suddenly gets a lot more interesting.
There are a number of articles in Cool Solutions explaining how to do even cooler things in Forms using Jquery or Juice (one of the underlying frameworks) and about the Form Script API:
Each type of Field, has different properties, and different little tweaks that can be used to control it. There are 12 or so different Control Types available in the list. CheckBoxPickList, GlobalList, Html, Localized Label, MVChecklist, MVEditor, Password, PickList, StaticList, Text, TextArea, Title. Again you can see how your ability to make a nice form that is very powerful, with minimal coding is possible.
You can begin to understand what I mean by UI information overload. Even something as simple as a form item has so many different options.
Once you have your forms lain out, you can see a sort of preview of what the page might look like, using the Preview Selected Form button, next to the Save icon for the Form Selection pane. I find this is a pretty rudimentary previewer and that once you start doing cool things with ECMA or some of the underlying frameworks the Preview window does a less and less complete job.
Now that was the Request form. Of which there needs to be at least one. But as noted above, you need to do much the same for the Approval form, if there is to be an approval process. Again you can have different approval forms for each approval step, should you so desire.
Onto the Actions tab, which is where the buttons are defined that either Submit or Cancel the operation when on the Request form, but on the Approval form your choices multiply. Here you get UpdateAction, CancelAction, CommentAction, ApprovalAction, DenyAction, RefusalAction. This sort of makes sense as it is all the possible things you might want to leave buttons to do on the bottom of the form. When you start a provisioning request, you really can only cancel or submit the request. When you are an approver you have a few more options, as you can approve it, deny it, cancel, just add a comment, refuse it, just update it, and so on.
Last but not least, you get a choice to set the buttons on the top, bottom, or top and bottom, but not much else direct control over the button placement. (I am sure you could some how move them in ECMA if you needed too).
The next tab under the Form Controls pane is called Events. There is only one event type available, onload, but this one can be powerful. When the page loads you can fire off events from here. Whatever you want to do in ECMA you can do now as the page loads. The events for the approval form are independent of the events for the request form as you would expect. If you need additional event types you would have to define them yourself in the scripts elsewhere in the form using the fireEvent() method.
The Scripts tab is where you define scripts that you want to use throughout the form. They can be inline, which means they get added as a script block on the form page as it is rendered, or external, where you call them from some kind of web resource. You can have a couple of these scripts, so that you can more easily manage the script library that you might need.
This is a definite weakness, where there is no easy way to manage a global script library for your entire provisioning environment. In the engine world, you can make an ECMA Resource object that can be linked to any driver, which makes the scripts available throughout. This would be really nice to have on the Provisioning side of the house.
Remember at this point that these scripts are executing in the browser rendering the form for the user. Thus the libraries and functions that you have available will be limited to those of the user's browser context.
The final tab, on the main PRD window, which is the one that started with Overview, is Signature Declarations. This is where you would declare the digital signature declaration. Once you do this, you can go back to the Workflow view, find the Start activity item, and if you look in the Properties tab for the Start activity (and each Approval step in the workflow following that) there is a line about Digital Signature Type. The options there are not required, Form and Data. Data stores the signature data in XML and form stores the signature data in a PDF file. You need to specify which Signature Declaration you want to use, from the ones you created.
I admit to not entirely being conversant in this option, as I have never actually used it. I understand the notion though. Like Adobe Acrobat will let you use a Digital certificate to sign a form to prove it was really you who signed it and no one else. Here too, if you have security requirements for your approvals and forms, then requiring the use of a digital certificate can help lock down and validate who really clicked the approve or deny link.
As you can see, at some levels the concept is simple. There is an abstraction layer to make directory queries easier, the DAL. There is a workflow layout tool that makes it easy to plan how the events should flow for the request. There is a simple form editor, for the request and approval forms that makes it easy to generate simple forms. There is support for digital certificates.
But at each of those levels, there is an opportunity to make things as complex as needed to satisfy your needs. It is this fusion of simplicity and complexity into a single tool that makes you realize how amazing a technology this really is.
You can do the simple stuff, and have it just plain work, nice and easy. Or you can start to play around with some really complex ECMAScript to get the form to dance for you. We have had clients that want simple forms, and we have had clients that want really cool and complex forms.
The power available to you to generate truly complex and amazing forms is hidden, but it is there, just waiting to be released and harnessed.
For a particular client we had 9 different services a user could request, and they wanted it all on a single form. Once the user initiated the PRD, the first thing it did was read back their current state from the directory via DAL queries. Once the form knew where the user was starting from, it could then render the correct options. For example if the user had any of the 9 services, then the options were to modify or delete the service entitlement. If the user did not have the particular service, then the option was to add the service.
What was amazing was that we could make the form update as the user clicked, so that when they chose to add a service, we could make the options available that the specific service needed, but keep them hidden until requested so that the form was not totally overwhelming to the user.
That is probably an example of over kill and we should really have kept things simple and just used basic workflows for each request case, but that is not want the client wanted, and as we all know the client is always right. Right? That discussion is left as an exercise for the reader.
Regardless, the possibilities are almost endless, and the documentation has a LOT of details on how this all works. My hope in this series was to try and summarize the basic process and get you started, so that as you find the need to add complexity, you can hit the documentation and learn that little bit that you might need, and keep moving along. Let me know if this helps any.
Support
Documentation
Learning Services
Partner Programs