SOA Workflow API

• Component Diagram (Cloud version)• Implementation overview• Database Components• API’s List• Use case diagram (to be included)• Error handler mechanism

Component Diagram (with SAAS option)

ImplementationOverview

• All workflow API’s exposed to clients over the network• Workflow can be initiated by client• SOA first create the task using Human task service

then create entries in custom DB tables• All task related histories can be retrieved from DB

tables itself through API’s• In case of exceptions SOA will not allow any actions to

the errored task further till the issue resolved through error handler mechanism

ImplementationOverview (Contd..)

• Process versions can be maintained, and decision can be taken on whether to terminate older version tasks or not

• Email notifications and look and feel can be changed through API itself w.r.t client’s branding

• API’s are ready for mobile app development with REST/SOAP variants

• New process can be added dynamically through API for supporting workflow for it (with additional pricing)

ImplementationOverview (Contd..)

• Process creation involves following stepsCreate process entryCreate Approval matrixCreate email template

• Similarly new users can be added through API on demand• User repository can be a custom table or any other user

repositories (AD, OID etc)• Currently email notification is supported but in future SMS

service also possible through SMS gateway • All workflow related attachments are uploaded into

SharePoint and accessed through secured links

API’s list• Below are the few of the API’s that can be used by client application

createProcess (Admin API) createProcessInstance manageUser (create/update/delete) (Admin API) manageEmailTemplate (Admin API) manageApprovalMatrix (Admin API) initiateTask getTaskList getTaskHistory updateOutcome updateVacation reAssignTask Request/Submit Info viewTaskReports (Admin API) etc

Database Components(Tables)

• Process– To store process metadata like, process id, name, error assignee etc

• ProcessInstance– To store each process transaction data like, creator, approval type, status

etc.• Map_ProcessAndApprovers

– To manage approval matrix like approver list, approval type, approval sequence, SLA etc

• USERS_MASTER– To store user list with their email, mobile etc. This can be a User repository

like OID, AD as well.• EmailCategoryTags

– To store email notification template

Database Components(Tables) contd..

• DashBoardTable– This table is used to retrieve requested users

(logged in) task list, Submitted Tasks (In Progress, Approved, Rejected,

Cancelled) Pending Tasks

• WorklistTable– This table will have the history of all approvers

interactions/action with each tasks.

Database Components(PL/SQL)

• GetDashBoardData– This SP will be called when ‘getTaskList’ API is invoked

Tables involved: DashBoardTable (for submitted/pending task list) WorklistTable (for brief approver icons)

• GetApproverHistory– This SP will be called when ‘getTaskHistory’ API is

invokedTables involved:

WorklistTable (for complete task history like, each approvers and their status etc)

Database Components(PL/SQL) contd..

• GetEmailNotitifyHdr– This SP will be called for to get email template for sending

notificationTables involved:

EmailCategoryTags (to get Approver/ Submitter email template)

• InsertUpdateWFAction– This SP will be called when following API’s invoked

updateOutcome requestMoreInfo submitInfoTables involved:

WorklistTable (to update action against actioned approver) DashBoardTable (to disable the view from dash board for actioned user) ProcessInstance (update task status in case of overall task outcome concluded)

SOA Human Task Components

Human Task API

Sample Application

Workflow Events

Dot Net client

Task History

Pending Tasks

JSON Payload

JSON Payload

JSON Payload

Email Notification

Approver Email

Tasks with attachment from SharePoint

Email Approval Validation

Approver Email