Introduction
This is the second article in a series of
posts with the common goal of providing customers with ideas and techniques
that can be used to simplify the use of advanced features of OIM 11g. In
Chapter One of this series, we described the components of a framework that
would allow users at all levels to configure OIM 11g features like Provisioning
and Approval Processes, Approval Routing Functions and Custom User Input Forms.
In this second article I will start talking about a reference implementation of
the components of the framework described in Chapter One.
Overview
The components that will be
covered in this article are:
·
User Input Forms
for OIM user creation and resource request.
·
Approval Flow
Design Interface
·
Approval Flow
Execution Agent Service
The above mentioned components
comprise the part of the framework that takes care of Provisioning including
the specification of approval flows that will be executed by the custom
composite application described in chapter one, which will be the approval
process for the Self Assign Roles request template which is out of the box and
doesn’t need additional dataset configuration and importing to MDS.
Foundation Components
Before delving into details
about the implementation of the higher level components, there are some
elements that we need to put in place to support the implementation of the
higher layer components. So, we will start by defining the infrastructure
elements needed as a foundation for the implementation:
·
Database Tables:
o
Multi-valued User
Profile Attributes: OIM_EXT_MV_UPATTR
o
Approval Flow
Definitions: OIM_EXT_APPR_FLOW_DEF
o
Custom User Input
Forms: OIM_EXT_CUSTOM_FORMS_DEF
·
Web Services:
o
Approval Flow
Execution Service
o
Database Persistence
Services
·
OIM Custom
Adapters
o
OIM Multi Valued
Pre-Populate Adapters
Once these components are
created, and we will discuss the structure of each one of them, then the higher
level components can be implemented. These include the following:
·
Approval Flow Design
UI
·
Custom User Input
Form Design UI
·
Custom User Input
Form Rendering and Execution engine
While the goal here is to
describe a reference implementation of the framework, it is just that, a high
level description of the architecture and the elements that need to be built
and the responsibilities of each element/component. The audience can take these
descriptions and come up with their own actual implementation. Since this is a
framework, once it is built, it can be reused and evolved over time to meet
more specialized requirements.
Foundation Components Specification
Now I will start discussing
the design and specification of the Foundation Components listed in the
previous section.
Database Tables
This section describes the
schema of the tables that will support the functionality of the provisioning
components of the framework.
Table OIM_EXT_MV_UPATTR
Description: This table stores
the values of multi-valued attributes of OIM user profiles. This table extends
the USR table to support user defined attributes as multi-valued.
Structure:
|
Name
|
Type – Length
|
Description
|
|
USR_LOGIN
|
VARCHAR(20)
|
This field contains the login id of the
user whose profile contains the multi-value attribute.
|
|
USR_LINK_KEY
|
VARCHAR (6)
|
This field links the values of an attribute to the
specific user profile.
|
|
USR_LINK_FLD_NAME
|
VARCHAR(30)
|
The name of the Field. This is the same
value as the FIELD_ID column of table OIM_EXT_CUSTOM_FORMS_DEF described
later.
|
|
USR_LINK_VALUE_ID
|
INT
|
This field contains the index of the values. This is
also part of the primary key.
|
|
USR_LINK_FLD_VALUE
|
CLOB
|
Stores individual values in a sequence of
values for the multi-value attribute.
|
|
USR_LINK_FLD_SIZE
|
INT
|
The amount of characters allowed in the field values.
|
|
USR_RO_NAME
|
VARCHAR(30)
|
The name of the Resource Object whose
process form contains a child table that holds the values for this
multi-value attribute. This field may be NULL if the multi-value attribute is
not associated to any Resource Object.
|
|
USR_RO_CHD_TABLE
|
VARCHAR(30)
|
The name of the Child Table where the attribute
values will be contained.
|
Table OIM_EXT_APPR_FLOW_DEF
Description: This table stores
the definitions of approval flows. Basically the required data for these
processes is merely the login IDs of users that should receive requests for
approval. The structure of the table supports sequential approvals, parallel
approvals and escalations.
Structure:
|
Name
|
Type – Length
|
Description
|
|
PROCESS_KEY
|
VARCHAR (6)
|
This is a unique ID for the process.
|
|
PATH_ID
|
INT
|
This field stores the sequence number of approval
routes in an approval flow.
|
|
APPROVAL_SLIP
|
VARCHAR(500)
|
The field contains either a single Login ID
or a comma separated list of login IDs which represents the list of approvers
that will receive the request in the way determined by the ROUTING_TYPE.
|
|
ROUTING_TYPE
|
VARCHAR(20)
|
The type of Routing for the request. Valid values
are: SEQUENTIAL or PARALLEL.
|
|
ESCALATION_TIME
|
VARCHAR(20)
|
This is the time it will take for the
approver to process the request before it gets escalated. The value is
formatted according to the W3C notation for durations. Example: P1D (means
after one day or no response for the task). If NO-LIMIT is specified then the
escalation policy will be set P365D (1 year).
|
|
ESCALATION_USER
|
VARCHAR(20)
|
The Login ID of the user this will be escalated to.
|
|
TERMINAL_APPROVER
|
VARCHAR(3)
|
This value indicates if this approver’s
response terminates the approval flow immediately. Legal values are ‘Yes’ and
‘No’.
|
Table OIM_EXT_CUSTOM_FORMS_DEF
Description: This table
contains the definitions of custom user input forms that are customizable via
XSL style sheets. The contents of this table will be generated through a GUI
created for this purpose.
Structure:
|
Name
|
Type – Length
|
Description
|
|
FORM_ID
|
VARCHAR (30)
|
This is a unique ID for the FORM.
|
|
FIELD_ID
|
VARCHAR(30)
|
This is a unique ID for a FORM Field.
|
|
FIELD_TYPE
|
VARCHAR(30)
|
The value of this field represents the HTML
control that will be used to input the value of the field.
|
|
FIELD_IS_MV
|
VARCHAR(3)
|
Flag that indicates whether the field is Multi-Valued
or Single Valued. Allowed values for this field are ‘Yes’ and ‘No’.
|
Web Services
In this section I describe the
functionality provided by a couple of web services part of the framework’s
implementation. Let me start by explaining the reason why web services are
included in the picture. In OIM 11g, all operations associated to Approvals are
carried out through Oracle’s SOA Suite. Some of the components that can be most
naturally included in SOA Composite applications which represent Approval
Processes in OIM 11g are Web Services. So not having Web Services would not
make any sense at all. Also, the main purpose of emphasizing this point is to
discourage the use of embedded Java in SOA composites specially when the
implementation assumes that requests may not be approved for weeks at a time; I
have come across some customers that have used OIM APIs in Embedded Java Tasks
and have experienced PERM Gen issues on the SOA Server.
Approval Flow Execution Web Service
This web service provides the
functionality of executing approval flows. Basically all it does is returning
the next approver in line for a multi-approver request flow. The web service
output includes the following:
·
Single Approver in
turn
·
List of Approvers
in a parallel flow
·
Approver for
escalated request
The nextApprover value
returned by this web service call is placed in the owner field of the human
task for the next approval. The web service also returns the status of the
approval flow to determine whether further routing must take place or the end
of the approval flow has been reached. The composite will evaluate all these
values to determine the appropriate flow.
Database Persistence Service
This web service will be
generated out of entities associated to the above mentioned database tables.
JPA entities will be created and a Session Bean will act as the session façade
for the entity beans generated out of the database tables. The persistence
service will be invoked from the various GUIs used to define Approval Flows,
Input Forms and other framework configuration elements.
OIM Custom Adapters
We have several options for
the implementation of adapters that will deal with the multi-value attributes
in a user profile. So the easiest way in my view to implement this is to have a
post-insert entity adapter that will do the following:
Extract the names of the
attributes associated to the user in question by querying the OIM_EXT_MV_UPATTR
table for the User Login Name of the user in question. The reason why we do
this search if because at a given time a user may not have all the attributes populated,
so only the attributes that have been populated are processed.
Extract the key of each custom
multi-value attribute from the user profile. The value is used to link the user
profile with the OIM_EXT_MV_UPATTR extension table containing the values for each
multi-value attribute of each user.
Extract the values of each
multi-value attribute that is populated for the user in question using the key
obtained above.
Using the tcUserOperationsIntf,
tcFormDefinitionOperationsIntf and tcFormInstanceOperationsIntf populate the
corresponding child tables potentially linked to each attribute. The
information required to call these API’s is stored in table OIM_EXT_MV_UPATTR
for each user.
Summary
I intended to present a
potential implementation of multi-value attribute support and a mechanism to
simplify the request process and potentially provide a more flexible
customization mechanism. In the next chapter of the series we will discuss the
implementation of the configuration GUI’s and the design of the customization
mechanism for the input forms based on XML/XSLT transformations.
Posts
