Process Layer 

Purpose

Within the process layer, you define the process steps, the sequence in which they are executed, the roles that execute them, and how the context data of a process is passed between the process steps.

A process is designed using Guided Procedures (GP). GP is a framework for composing user-centric process flows. It offers the means to bond diverse back-end applications and services into a single business workflow. It provides role-based access to resources and guidance through the workflows at runtime, thus, helping end users to identify and complete their tasks easily.

You must distinguish between Guided Procedures and guided activities. Guided activities refer to a screen sequence that logically represents a single-user transient task flow without own context or persistence. On the other hand, Guided Procedures involves multiple user collaboration, in which each step is a transaction, and data flow across the process provided by an own process context.

Guided Procedures provides a dashboard that allows users assigned to the relevant role to monitor the entire process. The individual work items of each involved user are available in their GP inbox. Exactly one action is executed within each process step. An action is a wrapper around a callable object (user interface or service) with input and output parameters that can be used to pass data across the process context. Actions decouple process steps from services and user interfaces to allow business experts to model processes at a non technical level.

A process model for the Customer Service Care:

...

                                                  i.       Customer enters a complaint.

                                                ii.       The system creates the complaint in the background.

                                               iii.       The account manager reviews the complaint and enters a comment.

                                               iv.       An application service is called to update the complaint.

                                                 v.       The customer reviews the comment from the account manager and chooses either to accept or reject the decision by the account manager.

                                               vi.       If the customer rejects the decision, a customer comment is added to the complaint and it is returned to the account manager.

                                              vii.       Order information is updated.

Flow Logic

In Guided Procedures, the flow logic can be governed using result states and different block types (for example: sequential, parallel, conditional). Each of the three block types has a different logic for executing its actions. Result states indicate the result of the operation that the action has carried out. For example, an approval action has Approve and Reject result states. In the design time, result states can be mapped to a previous or subsequent item or used to exit the current block. This means that steps can be executed in a random order. At runtime, when the action is executed, it returns a previously defined result state. The Guided Procedures Workflow Engine redirects the logic according to the mapping. If the result states of an action are not mapped explicitly, then the default is that the next element is executed.

Data Flow

At runtime, the Guided Procedures framework stores process context data in the GP context. You can expose data to the context using an action’s output parameters and consume this data in subsequent steps by mapping their input parameters to the relevant output from the previous steps. This data flow mechanism can be used for storing and transferring simple context data. For performance reasons, we recommend that you store complex data or large amount of intermediate data in a CAF object integrated as a background step in the process.

Roles

To enable user collaboration, GP uses the concept of process roles that define which user executes a process step at runtime. At design time you can consolidate roles into groups with the same user assignments.

Callable Objects

Callable objects are the most fine-grained components in GP. You can model objects offering user interfaces (UIs) and background callable objects that represent service calls. This allows for separating UI from back-end connectivity, thereby enabling reuse and enhancement across several industries.

When modeling callable objects, some general rules apply:

·        Callable objects offering a UI must ensure data consistency by calling a check service to avoid inconsistent data being persisted.

●      If consistency checks depend on data entered in different callable objects, the corresponding actions including the update service are called within a loop block. The actions can be executed again depending on the results of the check service.

●      To avoid unnecessary process steps, you must carefully consider when to split functions into separate UIs or services. For example, if you consider splitting up a UI to make it more generic and reusable, this would result in an increased number of steps in the process. In addition, you can combine a check service with another process step to eliminate the necessity of an additional process step.

●      For complex UIs with master and detail relationships, we recommend that you use a single callable object for the UI and the update service, even though it does not comply with the rule to keep UI and business logic separate.

More Information

Designing Composite Processes with Guided Procedures