Custom Workflows in the End-User Interface

There are many cases when one wants to execute a custom workflow in the end user interface.  Workflows in Sun IDM are so flexible that they can be configured to resolve many business needs.  So implementing custom workflows and exposing them using the end user interface seems natural.  However, unless you’re careful, executing a custom workflow to be used in the end user interface can be a difficult process.

Permissions

By default, the end user interface has limited access to most of the workflows within Sun Identity Manager.  This makes sense; you wouldn’t want an end user running the Audit Log Maintenance workflow (for example) to delete all audit logs without authorization.

Using a custom workflow in the end user interface is relatively easy.  First, you must set up the permissions of the
workflow to be able to be accessed by the end user interface.  To do that add the “End User” special organization to your workflow’s member object groups.

<MemberObjectGroups>
  <ObjectRef type='ObjectGroup' id='#ID#End User' name='End User'/>
</MemberObjectGroups>

Listing Workflows

By default, there are two helper pages that list the custom workflows available in the end user interface: the requestMenu.jsp and processList.jsp pages.  The requestMenu.jsp page is available, by default, in the end user interface under the Requeste->Launch Requests tab.  The processList.jsp page is not directly linked off the end user interface but the page is available.

There’s some slight differences between the requestMenu and processList pages.  The processList page lists all workflows available for execution.  It uses a generic form that offers no customization to the layout or look and feel of the page but the page is dynamically generated.  (It takes input from the End User Tasks configuration object to define the description of the workflows, but that’s it.)

The requestMenu page lists the workflows that are defined in the EndUserRequestMenu form.  You can customize the look and feel of the page by editing the form but the list of workflows available for execution is not dynamically generated.  The list of workflows available is defined by the code in the form, which by default is hard coded to list two workflows.

Launching Workflows

Now that you know you who list the workflows available to you you need to actually launch the workflow.  You can do this using the requestLaunch.jsp or processLaunch.jsp pages.  I honestly don’t know what the difference between both pages are.  They appear to do exactly the same work so I can’t figure out why they are both there.

So, the URL you’re going to use to launch the custom workflow will be similar to one of the following:

http://yourserver:8080/idm/user/requestLaunch.jsp? id=YourWorkflowId&newView=true

http://yourserver:8080/idm/user/processLaunch.jsp? id=Your+Workflow+Name&newView=true

There are two parameters you need to provide to the requestLaunch or processLaunch page:

1. The ID or the name of the workflow you want to launch, depending on what launch form you use.
2. A special (and undocumented) newView flag which I’ll explain soon.

When a user navigates to one of those URLs the workflow is started.  The first URL parameter, ID, must be there.  That makes sense.  If you want to launch a workflow, you need to know which one to launch.  The second URL parameter, newView, is required to workaround for a really stupid bug in the interface.

The problem with omitting the newView=true parameter is best illustrated using an example use case.  The default deployment of IDM includes several sample end user workflows:

• End User Anonymous Enrollment
• End User Update My Resources
• End User Update My Roles
• End User Update Resources
• End User Update Roles

Here’s the use case:
You’re customizing the end user interface to make it easier for your end users to perform certain actions.  You’ve decided to add two links to your pages to perform two different business functions.  For the purpose of this example, I’ll use the “End User Update My Roles” and the “End User Update My Resources” workflows.  It doesn’t matter what the two workflows do, just that they are different.

In this example, I modified the end user dashboard to add the following links to the home page:

http://localhost:8080/idm/user/processLaunch.jsp? id=End+User+Update+My+Roles

http://localhost:8080/idm/user/processLaunch.jsp? id=End+User+Update+My+Resources

The cusotmized dashboard

To demonstrate the bug do the following:

• Select the link for the “End User Update My Roles” workflow to launch it.
• Note that the update my roles form is now displayed.
• Select the home button (simulating an end user who realizes he’s navigated to the wrong workflow and just wants to start over).
• Select the link for the “End User Update My Resources” workflow to launch it.
• The “update my roles” form is displayed.
• But wait, that’s the wrong workflow!  The user selected the update my resources workflow.
• Note the URL displayed in the browser’s address bar.

The wrong workflow is shown regardless of the link

<rant> This kind of a bug really gets to me.  I don’t understand how this kind of an issue made it out of Sun’s quality assurance department.  The people using the end user interface are likely not technical and it’s not hard to imagine a user easily getting themselves into this type of situation.  If the user had selected the cancel button within the form then the first workflow would terminate and the forms for the second one would be displayed properly.  The problem is when the user selects one of the tabs at the top and ignores the cancel button this bug shows it’s ugly head.  This simply leads to a poorly designed web interface.

The simple fact is the user requested a processLaunch URL with an ID of one workflow and a different workflow was started.</rant>

Anyway, rant over.  The way around it is to append the newView=true parameter to the URL.  The “newView” parameter is undocumented but it appears to create a full new view each time the workflow is started.  I would have thought that this would be the default.  If you append the newView=true parameter to then end of your workflow launch URL you should be ok launching a workflow no matter how the user navigated to the start of the workflow form.

And in a “nutshell”, that’s how you can launch custom workflows in the end user interface of Sun Identity Manager.