1. Human Workflow Concepts
Amanjit Johal 1 1 1

2. THIS PROGRAM IS INTENDED TO PROVIDE INFORMATION SHARING ONLY AND IS NOT A COMMITMENT TO DELIVER ANY MATERIAL, CODE, OR FUNCTIONALITY BEYOND WHAT IS LICENSED AND/OR SHIPPED UNDER ANY LICENSE AGREEMENT BETWEEN ORACLE AND COMPANY. ANY SOFTWARE UNDER THIS AGREEMENT IS SUBJECT TO CHANGE AT ANY TIME AND, ACCORDINGLY, SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. THE DEVELOPMENT, RELEASE, AND TIMING OF ANY FEATURES OR FUNCTIONALITY FOR ORACLE’S PRODUCTS REMAINS AT THE SOLE DISCRETION OF ORACLE.

3. Human Workflow Concepts
Architecture
Human Tasks
Human Task Services
Stages
Stage Participants
Rules
AMX
Approval Groups
Approval Process
PIM Use Case
Definition
Approval 3 3

4. Architecture 4

5. Human Tasks (Workflow)
Enable human interactions with the business processes.
Contain the routing and the assignment information
The routing is constructed using stages &participants.
Carry deadlines, escalations, notification messages etc required for the timely task completion.
Business analyst would be able to modify these policies.
The payload to a human task can be simple types, complex types entity attributes (SDOs)
Human task instances are accessible to the user via worklist and Human task query services.
Have ability to notify the user based on intermediate events like assignment, completion, reassignment etc. 5

6. Human Task Services
The human workflow service handles requests based on task and rules metadata. It consists of the following set of core services:
Task service - Responsible for creating and managing tasks in the dehydration store
Task query service - Retrieves tasks for the web-based worklist application
User metadata service – Responsible for managing metadata specific to individual users and groups.
Task metadata service – Responsible for retrieving metadata information related to a task.
Identity service - Responsible for authentication and authorization of users and groups.
Notification service – Delivers notifications with the specified content to the specified user through any of the communication channels.
Assignment manager - responsible for routing, escalation, and reassignment of tasks

7. Stage
It’s a building block of the Human workflow. Every Human task should have at least one stage.
Complex approvals can be achieved by defining mutiple parallel and sequential stages.
Can be skipped based functional requirements(We use skip participant explained later.)
Stage instances are defined on collections , which are references to the task message attributes like payload attributes, entity attributes.
PIM uses tow collections, Header and Line which are used to define header Stages(non repeating) and Line Stages (repeating to create parallel instances for each element) respectively 7 7

8. Stage Participants Participants are assignment blocks of a stage.
Participants can be individuals groups or derived using List builders like Approval groups, HCM Hierarchies etc.
Participants can be derived:
Hard assigning to any of the above types.
Based on Oracle Business Rules to evaluate using any of the above list builder.
Based on payload values.
PIM approvals are Oracle Business rules based and we recommend using approval groups.
Allow capability of calculating outcomes based on various voting regimes like single , minimum number, % based etc.
Participants can be ignored from the 8 8

9. Rules Use OBR framework.
Rules dictionary contains various functions, constants, variables called fact types.
A rule is a combination of conditions and actions.
The conditions are defined using facts type, functions
The actions are used to return approval lists based on various list builder functions available in the rules dictionary
The rules can be used to derive , substitute or modify assignees.
The application attributes are exposed via SDOs as fact types.
Flex artifacts which are generated on the ADF server in the Fusion MDS need to be synced to the SOA MDS and rules. This is achieved by running a composite program called UpdateSOAMDS which is deployed on the SOA server during provisioning. 9 9

10. AMX : Approval Management
Approval Management Service (AMX) is the successor product to:
E-Business Suite Approvals Management Engine (AME) and
PeopleSoft Approval Workflow Engine (AWE).
AMX enables you to define complex task routing slips for human workflow by taking into account business documents and associated rules to determine the approval hierarchy for a work item.
Additionally, AMX lets you define multi-stage approvals with associated list builders based on supervisor or position hierarchies.
You define the approval task in the Oracle Jdeveloper’s Human Task Editor, and associate the task with a BPEL process.
Attributes derived from ADF view object in transactional applications
The ability to retrieve approvers using various list builders like Approval Groups, HR hierarchies etc.
The ability to define rules for controlling approval lists and hierarchy configurations

11. Approval Groups Collection of individuals, other Approval groups.
Can be static as well as dynamic.
Dynamic groups can be created based on custom logic by implementing a Class with method getMembers(Task task) from interface oracle.bpel.services.workflow.task.IDynamicApprovalGroup.
All approval group members are notified at the same time.
Managed by the Business Analyst UI using the BPM UI. 11 11

12. Approval Process A BPEL to orchestrate the approval functionality.
The orchestration includes
pre approval activities
Human task for getting the approval from users
post approval activities like object status changes.
Human task is an asynchronous, BPEL flow is dehydrated / passivated at this point.
Call back from the Human task would activate the process and start the flow from the point of dehydration.
Outcome Switch activity for the task response
Various outcomes used for various post out come activities. 12

13. Human Workflow Usage in Fusion PIM
Sending notifications of various types i.e
FYI for Statuses like Scheduled, Completed
Request Comment For Open Statuses and specific comment request action
Definition To do notification for NIR Definition status
Assignees of Definition Steps are derived based on Item Class Setup
Approval notifications for Approval and Interim Approval statuses.
Assignees are derived using Approval groups based on Rules(AMX)
Demo Link

14. PIM Use Case: New Item Request
Items created via import/services/ADF UI may require Definition/Approval or both.
These items are added to an NIR for the definition and Approval
NIR life-cycle follows
Draft → Open(Request Comment) → Definition(Definition Workflow) → Approval (Approval Workflow)→ Completed (FYI).
Open Workflow can be skipped using setup configuration.
Definition can be skipped if the intention is only to get an approval. 14 14

15. PIM Use Case: New Item Request contd..
Each Status is associated to a particular form of Workflow. Which is built using the BPEL orchestration, Human Task, and services.
Definition is based on predefined set of steps, their assignees, entities which they are required to define. This metadata is maintained at Item Class.
NIR Approval is based approval rules defined in OBR.

16. Definition Setup
NIR required flag allows the user to control the item to always be created via an NIR Process in the master orgs
Definition Setup:
Steps allow to defined the sequence of definition.
Step people are the assignees required to define various item attributions
Associated entity types represent the various types of attribution classifications of the item like Oper. attrs, Effs, structure types etc
Associated entity allows association of specific attributions of the above type being used. Eg. Operational attributes like Manufacturing , Inventory etc.
This setup can be inherited from the parent to child Item classes 16 16

17. Definition : Item Class Inheritance
Flat Panel TVs
NIR Setup
Step10 : MRP Planners : Opr Attr: Mfg, General Planning Designers: Opr Attrs: Physical Attributes EFF : Physical Specs
Step20 Financial Analysers: Opr Attrs : Costing, Purchasing
LCDs
Step10 : Mfg Planners : Opr Attr: Mfg, General Planning Designers: Opr Attrs: Physical Attributes EFF : Physical Specs, Service LCD Tech Group: EFF Liquid Crystal specs
Step20 …..
Step30 …..
3D LEDs
Step10 : , MRP Planners : Opr Attr: Mfg, General Planning, WIP Designers: Opr Attrs: Physical Attributes EFF : Physical Specs LED Tech Group: EFF: LED source specs, 3D Specs.
Step25 …… 17 17

18. Definition : New Item Request Object
LCD TVS
3D LED TV
NIR Setup
NIR Definition Setup
Steps
Steps…
NIR Definition Workflow Metadata
New Items
LCD-46-BL LCD TVS LED-46-SL D LED TVS
Step10 : MRP Planners : Opr Attr: Mfg, General Planning (LCD-46-BL240, LED-46-SL240) Designers: Opr Attrs: Physical Attributes (LCD-46-BL240, LED-46-SL240) EFF : Physical Specs (LCD-46-BL240, LED-46-SL240) Tech Group: EFF: Liquid Crystal specs (LCD-46-BL240) EFF: LED source specs, 3D Specs. (, LED-46-SL240)
NIR Workflow
Open Request Information
Definition Request Definition
Approval Rules Based Approval
Completed FYI
Step20 Financial Analysers: Opr Attrs : Costing, Purchasing
Step 25…
Step 30
Demo Link 18 18

19. Approval Setup Metadata
PIM uses rules to create approval lists.
The preferred list builder for PIM is approval groups as they do not depend on any hierarchy rather group of experts on a domain/subject. But there is no restriction on using any of the hierarchies.
The following attrs are exposed to SOA for writing rules:
Change Header(NIR)
Change Lines
Item Basic ,Opr attrs, EFFs
The attributes are exposed via the SDOs created by the NIR web services.
After new effs are generated in the fusion MDS a sycn program is run to sync them to the fusion SOA MDS. 19 19

20. PIM NIR Approval Workflow Design
Human Task: Approval Task
Rules(OBR)
PIM ADF BC Service
Collections
Rules Dictionary
ChangeObjectApproval(NIR/CO Header Attrs)
Header
Facts
1 :*
Line
NewItemLineApproval/ RevisedItemLineApproval
1 :1
Line Parallel Stage 1
Participant
LineRuleSet1
Item Object: Primary, Operational Attributes
Line Parallel Stage1:
Participant
LineRuleSet2
Line Serial Stage
Participant1
1 :0 to *
LineRuleSet3
EFF Attributes
NewItemHeaderRuleSet
NewItemRequestHeaderStage:
Participant1 20 20

21. Sample Line level rules
If NewItemLine.Item.CurrentPhaseCode == “Design”
then Approval required from “ItemDesignApprovalGroup”
If NewItemLine.Item.itemtype == “Finished Goods” And NewItemLine.Item.CurrentPhaseCode == “Design”
then Approval required from
“ItemDesignApprovalGroup”
Demo Link 21 21

22. Q & A 22 22 22

23. <Insert Picture Here>
Thank You 23 23 23

24. 25 25 25