human workflow concepts - oracle · human workflow concepts ... o based on oracle business rules to...

24
<Insert Picture Here> Human Workflow Concepts Amanjit Johal

Upload: hanga

Post on 23-Jul-2018

246 views

Category:

Documents


0 download

TRANSCRIPT

<Insert Picture Here> <Insert Picture Here> <Insert Picture Here>

Human Workflow Concepts

Amanjit Johal

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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.

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

Human Workflow Concepts

• Architecture

• Human Tasks

• Human Task Services

• Stages

• Stage Participants

• Rules

• AMX

• Approval Groups

• Approval Process

• PIM Use Case

• Definition

• Approval

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

Architecture

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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.

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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:

o Hard assigning to any of the above types.

o Based on Oracle Business Rules to evaluate using any of the above list builder.

o 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

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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.

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

• Approval Management Service (AMX) is the successor product to:

o E-Business Suite Approvals Management Engine (AME) and

o 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 Human Task Editor of Oracle JDeveloper, and associate the task with a BPEL process.

• When the fusion started there was a distinction how the approval and the non approval tasks were designed. AMX was used for the approval tasks, but later all the above concepts were then enabled for other non approval human tasks.

AMX : Approval Management

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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 IDynamicApprovalGroup.

• All approval group members are notified at the same time.

• Managed by the Business Analyst UI using the BPM UI.

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

Approval Process

• A BPEL to orchestrate the approval functionality.

• The orchestration includes

o pre approval activities

o Human task for getting the approval from users

o 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.

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

Human Workflow Usage in Fusion PIM

• Sending notifications of various types i.e

o FYI for Statuses like Scheduled, Completed

o Request Comment For Open Statuses and specific comment request action

o Definition To do notification for NIR Definition status

o Assignees of Definition Steps are derived based on Item Class Setup

o Approval notifications for Approval and Interim Approval statuses.

o Assignees are derived using Approval groups based on Rules(AMX)

Demo Link

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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.

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

• 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.

PIM Use Case: New Item Request contd..

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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

NIR Setup

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

NIR Setup

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.

Step20 …..

Step25 ……

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

Definition : New Item Request Object

LCD TVS

NIR Setup

Steps

3D LED TV

NIR Definition Setup

Steps…

New Items

LCD-46-BL240 LCD TVS LED-46-SL240 3D LED TVS

NIR Definition Workflow Metadata

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)

Step20

Financial Analysers: Opr Attrs : Costing, Purchasing

Step 25…

Step 30

NIR Workflow

Open Request Information

Definition Request Definition

Approval Rules Based Approval

Completed FYI

Demo Link

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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.

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

PIM NIR Approval Workflow Design

PIM ADF BC Service

Item Object: Primary,

Operational Attributes

Human Task: Approval Task

NewItemRequestHeaderStage:

Line Parallel

Stage 1

Participant

Participant1

EFF Attributes

Rules(OBR)

ApprovalRuleSet

ChangeApprovalSampleRul

eSet

Collections

New Item Line Object

1 :*

1 :1

New Item Request Object

Header

Line

1 :0 to *

Line Parallel

Stage1:

Participant

Line Serial

Stage

Participant1

ParallelApprovalRuleSet

SerialApprovalRule

Rules Dictionary

Facts

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

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

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

Q & A

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract

<Insert Picture Here>

Thank You

CONFIDENTIAL: All capabilities and dates are for planning purposes only and may not be used in any contract