Simple Process Modeler (Technology Preview)

Stardust provides support for a business object-centric view on Process Data.

• Core Model
• Business Objects
• Wrapper Processes
• Process Descriptors
• Process Model
• Process Topology

Core Model

To work in the Model & Go perspective, a core model and its elements must be defined in the Business Process Modeler. A core model should define:

• Business Objects
• Participants
• Applications
• Sub-processes / Process Interfaces
• Wrapper Processes

Model & Go! retrieves elements from all models in the model repository, therefore these elements can be distributed between multiple models.

Business Objects

A Business Object is not mandatory to create Process Definitions in the Process & Go!, but without it your Process Models can contain only the following:

• User Tasks with a Simple Panel interface
• E-mail Response Services
• Activity Groups

To work with service task, you need to have a business object and business object compatible application or process interface available.

Wrapper Processes

Simple Process Definitions can leverage wrapper processes defined in the core model, which the editor would invoke. Wrappers would apply "by name" data mapping logic. For the "by name" mapping we would create a Data Mapping from Data X to Parameter X - assuming that the types are consistent (e.g. BusinessDate or StartDate). The "by type" mapping would just find a parameter of type Fund and try to find the only Process Data with that type - provided that there is only one.

Process Descriptors

A descriptor is auto-created for each of the Business Object primitive marked as "Indexed."

Process Model

Each Simple Process is in fact a Process Definition and appears in the Business Process Modeler perspective. Simple Process models created in Model & Go! should not be modified in the Business Process Modeler.

Process Topology

Simple process models are mapped to strictly block-structured process topologies. This specifically implies absence of any loop constructs. Simple Processes have tabular structure. There is a sequence of rows, each of which may contain one to many cells.

How this maps to process definitions is potentially best explained by starting at the cell level and working inside out.

• Each cell is mapped to a combination of:
  • a leading XOR split gateway
  • a terminating XOR join gateway
  • an activity (the actual implementation of the activity, be it a manual task, a service call or a sub-process invocation)
  • transition flow that leads from the split gateway into the activity into the join gateway (the "happy path")
    • this is the "happy path", leading to activity execution
    • this is potentially guarded by the Activities condition (defaults to true)
  • an "otherwise" transition that leads from the split gateway to the join gateway
    • this is the shortcut path for skipping the activity if the guarding condition evaluates to false
• A row containing a single cell maps to the representation of the cell (two XOR gateways plus an activity)
• A row containing multiple cells is mapped to a combination of:
  • a leading AND split gateway
  • a terminating AND join gateway
  • for each contained cell
    • the representation of the cell (two XOR gateways plus an activity)
    • a transition that leads from the AND split gateway into the cell's leading XOR split gateway
    • a transition that leads from the cells terminating XOR join gateway into the AND join gateway
  • Adjacent rows are connected by exactly one transition, leading from the predecessor row's join gateway to the successor row's split gateway
    • depending on the row type (one cell or multiple) the leading / terminating gateway might either be an XOR or AND
    • in any case, there is exactly one leading and one terminating gateway, per row

This mapping ensures that:

• rows are executed in strict sequence
• each row is only completed if all contained cells are completed (or skipped, depending on condition evaluation)