Defining the Flows (Magic xpi 4.5)

The business process should now break down into executable flows. Each flow can represent a sub-process or a group of activities. A flow is comprised of a set of steps and their logic that control the order of the steps' execution, called flow orchestration.

A flow is the physical and executable level of the business process.

One or more flows can represent a single business process.

The flow includes the business logic of each process including error management and security issues.

Flow Set Up

It is highly advisable to try and create flexible and dynamic flows that are easier to administrate. For example, when you need to invoke some linear steps, create a loop rather than manage one long process.

Use of Variables

Magic xpi lets you define variables that can be used in flows. These variables are used to manage flow logic and to move data from one component to another. They are also useful when conditioning steps within a flow.

Magic xpi supports the following variable types:

• Flow variables: Variables that are defined per flow and enable management of flow logic and data transfer across the flow components. Each flow can have a separate list of flow variables, based on its internal activities. Scenarios for using flow variables include:

• • Storing data for further manipulation in the next flow steps.

  • Creating a business decision and different routes based on a variable’s value.

  • Invoking an error flow if the flow variable did not meet an expected value.

• Context/Model variables: Variables that are related to a context (thread). Context variables are created when a new context (flow) is started, and will be valid as long as the context is alive (even if it spans several flows to conclude its activity). A special set of context variables are the predefined variables: UserString, UserCode, UserBlob, UserXML. These variables are used as default variables defined in components, and can be changed to any user-defined variable of the same type. There are two exceptions to this:

• • A component XML interface is always based on UserXML.

  • All messaging triggers use the UserBlob for message content.

Scenarios for using context variables include:

• • Manipulate data using the Data Mapper that was invoked from a previous flow using the Call Flow option in the Destination.

  • Use a sub-process to validate data, based on data that was received in the main process.

• Global variables: These variables are available to all flows in the same project and share the same memory address. Changes made to a global variable in any flow effect all other flows. Scenarios for using global variables include:

• • Initializing global variables with values saved in environment variables (logical names) at the beginning of your project.

  • Using global variables instead of environment variables throughout the project for better performance.

• Business process variables: These variables are available to all flows in the same business process. Changes made to a business process variable in any flow effect all other flows in the same business process.

• Environment variables: These variables are used for defining the external IT environment properties inside a Magic xpi project. Environment variables allow smoother portability of projects between environments.

Magic xpi achieves portability by translating the environment variables at runtime, according to the translations entered in the Environment Variables Repository. Although the Environment Variables translation can be changed at runtime, they are mostly used as constants. Use environment variables explicitly only when dynamic behavior is required and expressions cannot be used.