Category Archives: Uncategorized

IToken

bpmn-server / IToken

Interface: IToken

Implemented by

Table of contents

Properties

Methods

Properties

id

id: any

Defined in

interfaces/engine.ts:10


type

type: any

Defined in

interfaces/engine.ts:11


execution

execution: IExecution

Defined in

interfaces/engine.ts:12


dataPath

dataPath: string

Defined in

interfaces/engine.ts:13


startNodeId

startNodeId: any

Defined in

interfaces/engine.ts:14


parentToken

Optional parentToken: IToken

Defined in

interfaces/engine.ts:15


originItem

originItem: IItem

Defined in

interfaces/engine.ts:17


path

path: IItem[]

Defined in

interfaces/engine.ts:18


loop

loop: any

Defined in

interfaces/engine.ts:19


currentNode

currentNode: any

Defined in

interfaces/engine.ts:20


processId

processId: any

Defined in

interfaces/engine.ts:21


status

status: TOKEN_STATUS

Defined in

interfaces/engine.ts:22


data

data: any

Defined in

interfaces/engine.ts:23


currentItem

currentItem: IItem

Defined in

interfaces/engine.ts:24


lastItem

lastItem: IItem

Defined in

interfaces/engine.ts:25


firstItem

firstItem: Item

Defined in

interfaces/engine.ts:26


childrenTokens

childrenTokens: Token[]

Defined in

interfaces/engine.ts:27

Methods

save

save(): Object

Returns

Object

Name Type
id any
type any
status TOKEN_STATUS
dataPath string
loopId any
parentToken any
originItem any
startNodeId any
currentNode any

Defined in

interfaces/engine.ts:29


resume

resume(): void

Returns

void

Defined in

interfaces/engine.ts:40


stop

stop(): void

Returns

void

Defined in

interfaces/engine.ts:41


processError

processError(): any

Returns

any

Defined in

interfaces/engine.ts:42


restored

restored(): void

Returns

void

Defined in

interfaces/engine.ts:43


getChildrenTokens

getChildrenTokens(): any[]

Returns

any[]

Defined in

interfaces/engine.ts:44


preExecute

preExecute(): Promise<boolean>

Returns

Promise<boolean>

Defined in

interfaces/engine.ts:45


preNext

preNext(): Promise<boolean>

Returns

Promise<boolean>

Defined in

interfaces/engine.ts:46


execute

execute(inputData): Promise<any>

this is the primary exectuion method for a token

Parameters

Name Type
inputData any

Returns

Promise<any>

Defined in

interfaces/engine.ts:50


appendData

appendData(inputData, item): void

Parameters

Name Type
inputData any
item IItem

Returns

void

Defined in

interfaces/engine.ts:51


terminate

terminate(): void

is called by Gateways to cancel current token

Returns

void

Defined in

interfaces/engine.ts:56


signal

signal(data): Promise<any>

Parameters

Name Type
data any

Returns

Promise<any>

Defined in

interfaces/engine.ts:57


getFullPath

getFullPath(fullPath?): Item[]

Parameters

Name Type
fullPath? any

Returns

Item[]

Defined in

interfaces/engine.ts:58


end

end(): Promise<void>

Returns

Promise<void>

Defined in

interfaces/engine.ts:59


goNext

goNext(): Promise<void>

Returns

Promise<void>

Defined in

interfaces/engine.ts:60


getSubProcessToken

getSubProcessToken(): IToken

Returns

IToken

Defined in

interfaces/engine.ts:61


log

log(...msg): void

Parameters

Name Type
...msg any

Returns

void

Defined in

interfaces/engine.ts:62


info

info(...msg): void

Parameters

Name Type
...msg any

Returns

void

Defined in

interfaces/engine.ts:63


error

error(msg): void

Parameters

Name Type
msg any

Returns

void

Defined in

interfaces/engine.ts:64

Decision Modeling Notation

Decision Modeling Notation

  1. Introduction

  1. Overview

DMN Decision Table:

  1. Using Decision Table inside Business Processes

Business Rules can be embedded in BPMN Processes using Business Rules Task as above. The results of the decision will determine the actions to be taken further in the process.

  1. Part of Model validation

Rules can respond to business events, providing validation the business objects without programming.

Multiple Rules Set can be attached to Business Object Events

  1. Rule structure:

  1. Decision Table:

Rule Id

Input Entries; can be one of the following

Numeric value;

String Constant; “Winter”

Expression;  < 8

  1.         Output Entries

Numeric value;

String Constant; “Wine and Cheese”

Expression;

Annotation (optional)

Priority (optional)

  1. Expression Limitations in Decision Tables:

Decision Table Rules should be treated as a stand-alone logic, in other words should not refer to any values or variable outside the input value provided.

Therefore, Input Expression cannot refer to any variable , Output Expression can only refer to input variables.

If there are requirements for more complex rules, the following options should be considered:

1. Prepare values before the Rules, for example if Rules refer to Age, you should calculate Age from Date of Birth prior to running the Rule and have the Age as a variable instead of Date of Birth.

2. Chain DT, by having one DT compute one result to be used in another DT

 

Implementation Details:

Decision Table is node in the process

Input and Result Variables are same as process variables (see variable mapping)

Gets executed as a step

Matched Rule(s) are recorded in the Case Item Status

Can be a separate process on its own and called as sub-process by various processes passing data

  1. Matching Rules and producing results

Single hit policies for single output decision tables are:

1. Unique: no overlap is possible and all rules are disjoint. Only a single rule can be matched. This is the default.

2. Any: there may be overlap, but all of the matching rules show equal output entries for each output, so any match can be used. If the output entries are non-equal, the hit policy is incorrect and the result is undefined.

3. Priority: multiple rules can match, with different output entries. This policy returns the matching rule with the highest output priority. Output priorities are specified in the ordered list of output values, in decreasing order of priority. Note that priorities are independent from rule sequence.

4. First: multiple (overlapping) rules can match, with different output entries. The first hit by rule order is returned (and evaluation can halt). This is still a common usage, because it resolves inconsistencies by forcing the first hit. However, first hit tables are not considered good practice because they do not offer a clear overview of the decision logic. It is important to distinguish this type of table from others because the meaning depends on the order of the rules. The last rule is often the catch-remainder. Because of this order, the table is hard to validate manually and therefore has to be used with care.

A multiple hit table may return output entries from multiple rules. The result will be a list of rule outputs or a simple function of the outputs. Multiple hit policies for single output decision tables can be:

5. Output order: returns all hits in decreasing output priority order. Output priorities are specified in the ordered list of output values in decreasing order of priority.

6. Rule order: returns all hits in rule order. Note: the meaning may depend on the sequence of the rules.

7. Collect: returns all hits in arbitrary order. An operator (‘+’, ‘’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries. Collect operators are: a) + (sum): the result of the decision table is the sum of all the distinct outputs. b) < (min): the result of the decision table is the smallest value of all the outputs. c) > (max): the result of the decision table is the largest value of all the outputs. d) # (count): the result of the decision table is the number of distinct outputs. Other policies, such as more complex manipulations on the outputs, can be performed by post-processing the output list (outside the decision table).

  1. OmniWorkflow Implementation of DMN

  1. Defining Decision Tables

  1. Defining Decision Table Using DMN Diagram:

  1. Defining Decision Table using Google Docs

  1. Process Design

Once the Process is run: the Case would have the result values of the decision table:

Sample DT

Sample Test Scenario for DT using Behat:


Sample Test Scenarios and Analysis:

Detailed Logging:

From Google Docs

Testing Processes using BDD

Testing Processes Using BDD

Using Behat to define test scenario

Integrated into Omni-Flow

Sample Output

Sample Report for Buy Used Car:

As seen above, Omni-Flow provides various functions allowing designer to right test scenario in simple plain English.

At end of every Scenario Omni-Flow generates a full report to describe the Case state.

Demonstrating the flow of the process as well as the Case data

Below is the actual test for this example:

# features/Buy Used Car.feature
Feature: Buy Used Car
Testing Buy Car
Scenario: Buy Used Car
Given I am logged in as an “User” Role
Then I should find a process named “Buy Used Car”
When I Start Process “Buy Used Car”
Then I find a Task named “Buy Used Car.Buy Car” with Status “Started” for this Case
When I execute this Task with Data:
|NeedsRepairs| NeedsCleaning | _complete |
|Yes|Yes|on|
Then the Case has the values:
|NeedsRepairs| NeedsCleaning |
|Yes|Yes|
Then I find a Task named “Buy Used Car.Repair Car” with Status “Started” for this Case
When I execute this Task with Data:
| _complete |
| on|
Then I find a Task named “Buy Used Car.Clean Car” with Status “Started” for this Case
When I execute this Task with Data:
| _complete |
| on |
Then I find a Task named “Buy Used Car.Drive Car” with Status “Started” for this Case
When I execute this Task with Data:
|  |
|  |
Then I find a Task named “Buy Used Car.Drive Car” with Status “Updated” for this Case
When I execute this Task with Data:
| _complete |
| on |
Scenario: Buy Used Car Just cleaning
Given I am logged in as an “User” Role
#  Then I Reset Case Data
Then I should find a process named “Buy Used Car”
When I Start Process “Buy Used Car”
Then I find a Task named “Buy Used Car.Buy Car” with Status “Started” for this Case
When I execute this Task with Data:
|NeedsRepairs| NeedsCleaning | _complete |
|No | Yes | on|
Then the Case has the values:
|NeedsRepairs| NeedsCleaning |
|No | Yes |
Then I find a Task named “Buy Used Car.Clean Car” with Status “Started” for this Case
When I execute this Task with Data:
| _complete |
| on |

Also a log file is generated for any further debugging purposes.

Here is some of the syntax available for use:


I am logged in as an “” Role
I am logged in as User “” and “” Role
I am logged in as User “”
my Role is “”
I am in a directory “”
I have a file named “”
I expect an error message “”
I Start Process “”
start process named “”
I Import a process named “”
I run “”
I should get:
I find a Case where:
I should find a process named “”
I Reset Case Data
I Reset All Data
I should not find a process named “”
I find any Task named “” with Status “”
I find a Task named “” with Status “” for this Case
I find a Task named “” with Status “”
I execute this Task
I execute this Task with Data:
this Task has a status of “”
I send Message “”
I execute Event “” for Process “”
I execute Event “” for this Case
the Case has the values:
I get an output of:
I execute the script for this Case: