Custom Business Logic
The Hitachi ID Identity Manager workflow engine externalizes business logic into plugin programs, which are typically implemented as short scripts responsible for very specific functions. Business logic may be executed in-process, using a built-in scripting language (PSLANG) or out-of-process, using any programming language (Python, C, C++, Java, Perl, VB, etc.).
Examples of workflow business logic include:
- Limiting which users can make change requests at all.
- Limiting which user profiles a given requester can see (e.g., a manager can see his subordinates, but should the subordinates be able to see the manager's profile?).
- Limiting the resources that a given requester can make changes to (e.g., some users may be able to change their LDAP profile, but perhaps not their mainframe or ERP access rights).
- Limiting the operations that a given requester can initiate (e.g., create a new user, terminate existing accounts, modify attributes or group memberships, etc.).
- Validating user profile attributes entered through the UI -- for example, ensuring that things like department codes are legitimate, and that the value of one form input is consistent with another.
- Auto-setting user profile attributes -- for example login IDs, e-mail addresses, file- and mail-server locations and directory OUs.
- Routing completed requests to appropriate authorizers, such as a requester's manager, resource owners, etc.
In practice, it is more efficient to manage this sort of business logic using a small number of self-contained scripts, than to embed code snippets into hundreds of graphical or table-driven workflow objects.
Custom Logic Survives Version Upgrades
All customization and configuration is accomplished using a combination of settings enabled through the administrative web GUI, plugin programs and exit programs, all of which are separate from the core Identity Manager binaries and M4 user interface definition files.
This separation between core product capabilities and customer modifications has the two big benefits:
- Customizations are safe, in the sense that they cannot break core product capabilities or logic.
- Customizations survive upgrades, since they are clearly separated from the core product (compare to ASP or JSP applications, where customizations are intermingled with core product code).