Back

Workflow Modeling

Workflows defines the processes by which content is modified. The are managed by editiing YAML documents in the workflows directory.

A workflow is composed of a name, which identifies the workflow, a set of states, which define the valid states that the content is allowed to be in, and a set of actions, which transition content from one state to another.

The JellyBeanWorkflow is shown below:

name: JellyBeanWorkflow

states:
  - name: InBag
  - name: InHand
  - name: InMouth

actions:

  - name: PutInBag
    entryPoint: true
    nextState: InBag
    hooks:
     - name: AddToSearch 
       index: bagindex
    allowedGroups:
     - Friends
     - Family

  - name: Take
    nextState: InHand
    sourceStates:
     - InBag
    hooks:
     - name: RemoveFromSearch
       index: bagindex

  - name: Eat
    nextState: InMouth
    sourceStates:
      - InHand

This workflow has three states: InBag, InHand and InMouth. There are three actions which can be used to move content through the workflow: PutInBag, Take and Eat.

The PutInBag action is marked as an entryPoint. This means that new content can be created using that action. Any action can be marked as an entryPoint.

Each action has a single nextState field. This is the state that the content will be in after the action is performed.

Each action can optionally have a list of sourceStates. This is a list of states that the content may be in for that action to be performed. If not defined, the action can be performed while the content is in any state. So, in the above example, a jelly bean can be moved from InHand to InMouth using the take action, and may moved from the InMouth state to the InBag state via the PutInBag action, but cannot be moved directly from InMouth to InHand.

A workflow action can have a set of allowedGroups. These are groups that can execute that action. In the above example, only members of either the Friends or Family groups can execute the PutInBag action. If not present, no group restrictions will be placed on the action.

Action Hooks

ActionHooks allow business actions to be attached to workflows.

These should have a name which identifies the hook to be executed, and a config, which will vary depending on the hook.

actions:

  - name: PutInBag
    entryPoint: true
    nextState: InBag
    #use hooks to let friends have beans as well
    hooks:
     - name: Assign
       config:
        group: friends
     - name: SetPermissions
       config:
        group: 
          read: true
          write: true

Built In Hooks

Assign

This assigns the content to a user and/or group by setting the assignedUser and assignedGroup fields.

- name: Assign
  config:
    group: friends
    user: joe

SetPermissions

This sets the permissions of the content.

Permissions can be set for the owner, assignee, other (anyone else) or a set of groups

- name: SetPermissions
  config:
    owner:
      read: true
      write: true
    assignee:
      read: true
      write: true
    other:
      read: true
      write: false
    group:
      friends:
        read: true
        write: false

AddToSearch

Adds the content to a search index. The search index can be specified in the index parameter. If not specified, it will be added to an index called “default”.

- name: AddToSearch
  config:
    index: myindex

RemoveFromSearch

Removes the content from a search index. The search index can be specified in the index parameter. If not specified, it will be removed from an index called “default”.

- name: RemoveFromSearch
  config:
    index: myindex

Order of Hook execution

The order of hook execution will be the order declared in the YAML definition. This can have an impact if the hook changes any values in the content.

Changing Content Values in ActionHooks

ActionHooks may change content values, if they wish. This opens up the potential of side effects between different hooks that may want to work on the same values.

Back