Appendix B. Approval Management
With the evolution of business processes and compliance, companies are emphasising on documents and approvals. Many applications use Approval Management Extension (AMX) for approvals. With Oracle BPM AMX, you can define approval rules based on your business processes and decisions, such as whether to route documents to approvers in series or parallel and whether approvals should be based on employee supervisory hierarchy, position hierarchy, job levels, or Approval Groups. The approval tasks are defined in Oracle JDeveloper's Human Task editor and approvals are managed in BPM Worklist applications or BPM Workspace applications. You used BPM Workspace in this book and will be using the same application for AMX too.
Introduction
The following are the key elements that are involved in understanding and setting up approval routing rules:
Approval Request Task: Business processes need human intervention such as you have used in the SalesToContract process in this book. The document Approval Request Task lets you send approval requests to approvers, enabling them to make decisions and thus advance the process:
Task Configuration: You need to configure event-driven and data-driven configuration for the document approval task before submitting documents for approval.
Stage: Stages let you organize your approval routing rules into logical groupings, and each stage is associated with a collection. A collection contains a set of attributes at a specific purchasing document level, such as header, lines, and so on, which can be used to author routing rules.
Participant: You can add or edit task participants inside stages. Participants are assigned based on routing patterns, such as single, parallel, serial, and FYI.
Rule: Approval rules, within a participant, are composed of rule name, condition, list builder and its attributes, response type, and auto action. The rule name will identify the approval rule:
Condition will indicate when the approval rule will be applied. A condition is defined based on the attributes seeded in a collection. Once the condition is satisfied, List Builder will identify the type of users needed to approve or receive notification.
List Builder: There are many list builders supported, such as Approval Group, job level, position, supervisory, and resource. Each list builder has a set of properties that defines it. Response Type indicates if the participants are required to approve the task. If not, they are FYI participants.
Auto action: specifies if the list builder will automatically act on tasks. The auto action value specifies the outcome to be set, such as approve or reject.
Your business requirement is to generate approvers list dynamically. They have a basic business fulfillment to be taken care of, based on the industry type, and then as per business defined logics, a list of approvers will be generated. The business needs to incorporate the following logic to derive approvers dynamically:
If Industry IS 'Sales' Then Approvers are - Salesbusinessanalyst1 and Salesbusinessanalyst2 If Industry IS 'IT' Then Approvers are - ITbusinessanalyst1 and ITbusinessanalyst2 Else Approvers are - businessanalyst and businessanalystmanager
To generate a list dynamically, the process needs to interact with the enterprise database. The enterprise database would have a procedure defined to take care of logic and to return approvers list. To fulfill the business requirement, you have to follow the ensuing steps:
Modify approval task you would modify business analyst review task to build list using business rule
Implementing dynamic approval mechanism
You have defined user hierarchy in the Defining assignments—powerment, and business alignment. What make management chain participant section in Chapter 5, Human Workflow in BPM Process. Ensure that following users are created in security realm in Oracle SOA or are available in your identity management solution:
Salesbusinessanalyst1
Salesbusinessanalyst2
itbusinessanalyst1
itbusinessanalyst2
businessanalyst
businessanalystmanager
