Hello World – OIM11g Approval Workflow

Introduction

An under the hood inspection of what happens when we have approval workflows in OIM 11g.

The intended audience for this experiment is experienced OIM 9.x developers who are learning OIM 11.x.

The Setup

I am using

Component	Version
Operating System	Windows 2003 R2 (Enterprise x64 Edition)
Application Server	Weblogic 10.3.5
Database Server	Oracle 11gR2
OIM	11.1.1.5.0

Code 

Hello World Scenarios

Create User via Self Request

Let us say I want a new user, but I will not create it using the direct form. I’ll try this via a self request.

 

The default approval flow for OIM is

Template Approval > Request Approval > Operational Approval

OIM11g does not have any approver assigned to this template, but has xelsysadm as default approver for Request Approval and Operational Approval.

I approved the first level Request Approval and here is what I get.

Let us approve the next level.

I gave an effective date for the request, so the request is waiting for effective date to be reached.

I created one more request with no effective date and followed the same procedure and here is what I got at the end of it – a new user!

Create User via Self Request (Semi Approved)

In the last scenario we saw two levels of approval for the Create User process. I now want only one level of approval. There is no template level approval. We can suppress either Request Level Approval or Operational Level Approval. I suppressed the Request Level approval. A rule was created, which is something like this:

Now if I raise a request to create a user, the request directly moves on the operation level approval.

MyApp (Custom Resource) – Self Request

I did not have any connector installed in my system, so I created a dummy resource for this purpose. Here is what I did

Create Resource Object

Create Process Definition

Create a Requester Role

Create a request template

User Setup

Give a user the requester role

Request the resource

Enough of configuration, I need my resource quick!

Request Level Approval

The request has no approval process defined, so it went to the default request level approver. Let us approve that.

Operation Level Approval

Request Level approval is done but we still need the operation level approval.

The request is now approved!

I got the resource provisioned!

MyApp (Custom Resource) – Object/Resource Forms

In the older OIM 9.x series to create forms, we could just go to the form designer and create some forms. Once they were associated with the resource object we were all set. It was all graphical and easy to learn. With the new OIM11.x it has become a jungle of terms with so much to digest, that by the time I actually get to the work, I’ll forget where I am. So here I’ll try to add one by one small features and then see how it works here.

One Field with No Mapping to Process Form

According to the documentation, I need an xml file to declare the form fields. Here is what I created

Let us try to do a self request for MyApp

Cool! Now I can see my new form field.

Simple Pre-populate

It would be so much better if the user login could be populated automatically. Let us write a plug-in to do that.

Here is a simple code for that.

You can see some simple System.out.println statements in the code above. I added them to see what is getting passed around. Not necessary, but let us see what do we see in logs when we create a new request.

My new request gets the user login automatically now!

User Only and Approver Only Fields

The metadata documentation mentions some fields to be approver only and some fields to be user only fields. Let us see what that means

Here is the xml I created

Requester View

When I do a self request here is what I get as a requester

If I go ahead and submit the request, I can see this

Approver View

What does the approver see?

I can see the approver only field here! I’ll deny the request and let us see what the requester gets.

Too bad he can’t see the approveronlyfield!

Lookups and IT Resources

Most forms will have lookups and/or IT Resources to select from. Let us see how we can do that here

Creating a Lookup, a IT Resource Type and IT Resource

The metadata XML

Here is the XML I used

So I have one lookup and one IT Resource field, which shows up like this when I do a self request

However, if you see the xml file I had to use AttributeReference instead of Attribute. I first tried using Attribute tag, but it didn’t work. I changed it to AttributeReference and thus had to refer to something in the parent form, which I created like this:

So now we have the IT Resource field and Lookup field. I’ll fill some data and submit the request

I’ll approve the request and then let us see how it shows up in My Resource.

So I have the resource, but the data doesn’t seem to have passed through. The auto-save is off for this process. Let us turn that on and see the result again with another request.

It worked! Now I have the IT Resource and Lookup data being passed through to the user and the resource is provisioned too, awesome!

Child Data

Till now we have mapped only the parent data to the process forms. Let us map some child data from request to process form’s child data.

Here is the XML I used:

Here is what I gave while creating the request:

 After approving the request, we get the big bang in our child table!

 

Dependent Fields

In an old project, we had a requirement where we wanted two fields to show up on the form field. The requirement was to have field2 have values based on field1’s selection. At that time OIM 9.1 was the latest version out, and I had no idea how to get that working in OIM. But with this new version of OIM it is possible. Let us see how we can do that.

The two fields that we have in our case are Country and State. So if I select India, the state list should have Indian states only. I added these two fields in the process form and here is how it looks now:

The XML file that I created has two new attributes to map to these two attributes.

      <AttributeReference name="Country" attr-ref="Parent Field Country"

            type="String" widget="lookup" lookup-code="Lookup.MyApp.Country"

            length="100" available-in-bulk="false" />

      <AttributeReference name="State" attr-ref="Parent Field State"

            type="String" length="100" widget="lookup-query" available-in-bulk="false">

            <lookupQuery

                  lookup-query="select lkv_encoded as State from lkv where lku_key = ( select lku_key from lku where LKU_TYPE_STRING_KEY = 'Lookup.MyApp.State' ) and lkv_decoded = '$Form Data.Country'"               

                  display-field="State" save-field="State" />

      </AttributeReference>

Once I upload this in OIM, and I do a self request here is what I get when I do a self request:

So we have the two fields showing up at the top right. Let me fill the Country to USA and see the State field values.

It worked! The query that I wrote in the XML allows me to refer to form data. Now I can have dependent fields in the request workflow.

Conclusion

The new approval workflow has three levels of approval, which being Template, Request and Operation in that order. Template level is optional by default, but the other two have XELSYSADM as the default approver. To suppress these we need create policies. However the older way of doing things was simpler and it would have been so much nicer if they had integrated it with the design console instead of using a XML based configuration.