® ibm software group © ibm corporation itim 4.6 - common lifecycle operation modifications
TRANSCRIPT
IBM Software Group
Agenda
Introductions
Basic overview of Lifecycle Operations and Entitlement Workflows
Overview of the Workflow Designer and components
Scenarios
Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.
IBM Software Group
Introductions
Fon KwokUS: ITIM L2 Support Engineeremail: [email protected]: 714-438-5112
IBM Software Group
Basic Overview of Lifecycle Operations and Entitlement Workflows
Similarities: Approvals, RFI’s, WorkOrders. These nodes are available in all operations.
Scripting (data manipulation, etc).
Modifying the behavior of ITIM (doesn’t require writing custom Java code).
Differences: Lifecycle Operations: any action on Accounts and Person objects
Entitlement Workflows: only for Add/Modify on Account objects.
Lifecycle Operations: effective after saved, and profile cache is refreshed.
Entitlement Workflows: only effective, after added to a Provisioning Policy, and only effects those Accounts that are associated with that Policy.
“Subprocess”, can only be called in an Entitlement Workflow.
Only Lifecycle Operations can be used with a Lifecycle Rule.
IBM Software Group
Overview of the Workflow Designer and components
Workflow Designer is a Java Applet that is used to configure the Lifecycle Operations and Entitlement Workflows.
Components: Nodes:
Approval: requires approval/rejection from participant RFI: requires information from participant Operation: calls an existing Operation (Person>Modify from Account>Add). Loop: loops until conditions are met Extension: performs a single action (modifyAccount, suspendPerson, etc). Script: JavaScript Work Order: sends notification to a participant, and can create a To-Do Item. Subprocess (only available in Entitlement Workflows): Calls an Entitlement
Workflow, from another Entitlement Workflow. Transitions:
The connectors between nodes. Are used to route the request through the Operation/Workflow. Can contain JavaScript.
IBM Software Group
Overview of the Workflow Designer and components (cont.)
Data
Input Parameters: data that enters into the workflow/operation, and is used to perform the function. (Static)
Output Parameters: Only supported in Entitlement Workflows. The resulting data of the workflow.
Relevant Data: global variable data within the Workflow/Operation. Can be used to pass data from one activity to the next. JavaScript can be used to retrieve/modify/set Relevant Data.
Accessed by clicking the “Properties” button in the Workflow Designer
The default Input/Output Params and Relevant Data, will differ between Entities, Operations, Workflows.
IBM Software Group
JavaScript methods
JavaScript methods used in the scenarios: x.get(); retrieves the object
x.getProperty(‘attributeName’); retrieves the attribute value
x.setProperty(‘attributeName’,value); sets an attribute value
x.set(y); pushes the object back into the workflow for later use
process.requestorType; returns the type of requestor (system, user)
process.getRootRequesterName(); name of the requestor for root request
PersonSearch().searchByFilter(profile,filter,scope); searches for (and returns) a person object.
IBM Software Group
Overview of the Scenarios:
Case 1: Sponsor lookup during BPPerson dataload.
Case 2: Dynamically change Service data, while processing requests.
Case 3: Update Person object with Account data.
Case 4: Dynamically change account data during requests.
Case 5: Prevent the ITIM System from deleting accounts.
IBM Software Group
Scenario 1: Sponsor lookup during BPPerson dataload.
The Sponsor (erSponsor) attribute on BPPerson objects, behaves similar to the Supervisor attribute on Person objects. This attribute contains a DN that points to another BPPerson object.
Previously a bug existed where ITIM does not handle the lookup of erSponsor’s value during datafeed, as it does erSupervisor’s. (NOTE: this has been fixed in ITIM 4.6 IF10 APAR IY80890)
Previously, in order to get the erSponsor value loaded successfully, you would have to pass a valid DN for this attribute in the feed. For Person objects, you can use a common name or an attribute/value pair.
In this scenario, we use a Script node to perform the same type of lookup for the erSponsor, as ITIM would normally do for the erSupervisor attribute.
This scenario will show how to modify the ITIM Operations to workaround bugs/limitations.
IBM Software Group
Sponsor Lookup Script
In this script the following occurs:
Check for the requestor type (ie is this a system generated request or a manual user request?). Specifically not U (which means that a user is triggering an event. We want it to be looking for datafeed processes)
Get the Person entity
Get the Person’s Sponsor value (which is a filter such as “employeenumber=55555”)
Search for the Sponsor’s DN using that filter value.
Return the new Sponsor DN in the Sponsor attribute
IBM Software Group
End Result for Scenario 1
Run the datafeed again with user Tom Jones
The script finds the corresponding sponsor value.
IBM Software Group
Scenario 2: Dynamically change Service data, while processing requests.
Some Services contain parameters to help limit the management scope of that service on the remote platform. Normally, a separate service for each scope would have to be created, in ITIM.
This scenario will show how to dynamically modify Service parameters, at runtime, in order to limit/expand the management scope of the Service on the remote platform.
Most commonly used with AD and RACF Service types. AD: Base Point, Domain ID/PWD.
RACF: RACF ID….
IBM Software Group
Set Basepoint Script
The script will do the following:
Get the Account owner (Person)
Get the Service entity
Get the owner’s title
Check if the title is a Contractor, and if so, set a new basepoint
IBM Software Group
End Result for Scenario 2
Add a new AD account for a Person who’s title is Contractor
The new AD account will be created in the “Contractors” container
IBM Software Group
Scenario 3: Update Person object with Account data.
In most Customer environments, Person data needs to be updated with information that was not available during the DataFeed.
Example: Most Person data is loaded into ITIM without a valid email address. The email address is usually created when the Person’s email account is provisioned (via ITIM).
This scenario will show how to update a Person object with a valid email address, once the Person has been provisioned an email account (ADAccount).
This can be used to update the Person object with virtually any Account data (example: erUid -> erAliases).
IBM Software Group
Update Person Email Script
This script does the following:
Get the Account entity
Get the Account owner (Person)
Get the Account’s mail property
Populate this into the owner’s mail property
IBM Software Group
End Result for Scenario 3
A new AD account is created for a Person. This account contains a new email address
The email address is now populated in the Person object under the “Communications Information” tab
IBM Software Group
Scenario 4: Dynamically change account data during requests.
This scenario will show how to dynamically modify account data, during a request, based on the request data.
Quite a few customers have requested that ITIM expire account passwords, whenever Help Desk/Admins/etc. reset passwords for a user. But if the owner of the account resets their account password, the password should not be expired.
Based on the requester of changePassword, the Operation will either cause the account’s password to be expired….or will leave the password active.
IBM Software Group
Check Requestor Script
The script does the following:
Get the Account entity
Gets the owner of the Account (Person entity)
Gets the Person’s cn
Sets the Person relevant data object
Gets the Account’s service name
Sets the Account relevant data object
Gets the process’s requestor name
Compare it to the Person’s cn, and set the isOwner flag accordingly.
IBM Software Group
Transition Node
If the person requesting the AD password change is the owner, then go to the “End” of workflow.
IBM Software Group
Transition Node
If the person requesting the AD password change is not the owner, then go to the change password node.
IBM Software Group
End Result for Scenario 4
Logged in as “ITIM Manager”, we change the AD password for Chuck Wilson
Check the Chuck Wilson account in Active Directory, and you will see that the “User must change password at next logon” is enabled.
IBM Software Group
Scenario 5: Prevent the ITIM System from deleting accounts.
In order to keep accounts compliant with the ITIM Policies, the Policy Enforcement Action must be set to “Correct”.
The risk of this configuration, is that ITIM will deprovision accounts that are found to be “not allowed”.
Many customers do NOT want ITIM to deprovision accounts, unless specifically requests by a user/admin (non-system).
Customers could replace the ‘deleteAccount’ extension (in the ‘delete’ Operation), with a ‘suspendAccount’ extension….but this would prevent even manual delete requests from deprovisioning accounts.
This scenario shows how to configure the ‘delete’ Operation to allow manual delete requests, but prevent the ITIM System from automatically deleting accounts.
IBM Software Group
Check Requestor ID script
This script checks the requestor type. If it is System (S), then set the String relevant data object accordingly (this will be processed by the Transition node)
IBM Software Group
Transition Node If the requestor is the System, then go to the “End” of workflow.
If the requestor is an ITIM user, then go to the Delete account node
IBM Software Group
End Result for Scenario 5
The Person object “Chuck Wilson” belongs to the “AD Users” organization role. This allows him to have an AD account.
We remove Chuck from this organization role.
ITIM normally deletes the account (based on Correct Noncompliance). However, the workflow will find that the requestor was System, and will leave the account under Chuck Wilson as “Not Allowed”
IBM Software Group
Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.
In order to help determine the cause of problems in Workflows/Operations, Scripting can be added that make use of the new JavaScript method added in ITIM 4.6, called Enrole.log().
In previous versions of ITIM, ‘return’ statements would have to be used, or custom fesiextensions would have to be written, in order to return debug data at different points in the Workflow.
Usage: Enrole.log(“Component”,”Message/Data”);
Example: To retrieve and print the title attribute value to the msg.log:
var person = person.get();var title = person.getProperty(‘title’)[0];Enrole.log(“TEST”,”TITLE: “ + title);
IBM Software Group
Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.(cont.)
The msg.log would show something like the following:
<Message Id="CTGIMO023E" Severity="ERROR"><Time Millis="1130457513906"> 2005.10.27 16:58:33.906-07:00</Time> <Server Format="IP">gumfudgin.ITIMlab.local</Server> <ProductId>CTGIM</ProductId><Component>TEST</Component><ProductInstance>server1</ProductInstance><LogText><![CDATA[CTGIMO023E The following definition error occurred. Error: TITLE: Contractor ]]></LogText><Source FileName="com.ibm.itim.fesiextensions.Enrole" Method="Enrole.log"/><TranslationInfo Type="JAVA" Catalog="tmsMessages" MsgKey="standardException.userDefinedError"><Param><![CDATA[TITLE: Contractor]]></Param></TranslationInfo></Message>
The Component value, that was entered in the Enrole.log() statement, can be used to locate the debug output from the scripts.
The msg.log (and trace.log) is located in c:\Program Files\ibm\tivoli\common\CTGIM\logs\
IBM Software Group
Conclusion
In many customer environments, there are business requirements that ITIM cannot perform in a default installation.
We can modify the default ITIM Lifecycle Operations to fulfill these requirements.
Custom external coding is not always necessary.