Process Design Considerations

In process-driven design, the business processes or integration flows are first realized and captured. Service contracts might be applicable in a process-centric application, especially for batch or EAI-type automation scenarios. This topic describes some important factors to be considered when using a process-driven approach.

Choosing Between Properties and Variables

Properties are used to save configuration data at different levels. They can be classified into application properties, module properties, and process properties.

Variables are used to save the state at different levels. They can be classified into process variables, scope variables, and shared variables.

Choosing Between Process Properties, Module Properties, and Application Properties

Properties can be classified into application properties, module properties, and process properties. Properties follow the layered configuration model where configuration is pushed from top to the bottom as seen in the illustration:

Properties defined in the inner layer can reference a property defined at the parent layer. For example, a process property can reference a module property instead of providing a literal value. Public properties are visible to the encapsulating layers.

Choosing the right level ensures an easier to maintain list of properties in your application and keeps the number of properties at the application level to a minimum.
Comparing Process, Module, and Application Properties
Scope/Visibility Datatype Values Additional Information
Process Properties Visible within a process. Literal or shared resource reference. Literal, shared resource reference, or a module property reference. Literal values cannot be modified at the module or application level.
Module Properties
  • Visible within the module.
  • Not visible or changeable from Administrator.
Literal or shared resource reference.
  • Literal or a shared resource reference.
  • The DateTime module property must be specified in the format: yyyy-MM-dd'T'HH:mm:ssXXX. For example, 2001-07-04T12:08:56-07:00
  • Cannot be assigned to an activity directly. You need to reference a module property from a process property, and then reference the process property from the activity.
  • Any value for a private module property defined in the profile is ignored.
Application Properties Displays all the module properties in the application. These properties are visible in Administrator.
  • Literal.
  • Profiles can be used to provide a new set of values for the application.
  • Overrides module properties, thus enabling you to use different values for the same module.
  • Cannot add new properties at application level.

Choosing Between Process Variables, Scope Variables, and Shared Variables

A process variable saves the state at the process level and a scope variable saves the state within the scope.

Variables defined within a scope are visible only within the scope. If the scope variable name is the same as a process variable name, then the scope variable takes precedence over the process variable within the scope.

Shared variables are used to save the state. There are two types of shared variables:
  • Module shared variable - saves the state at a module level.
  • Job shared variable - saves the state for the duration of a job.
For more information see Shared Variables in the Concepts guide

Handling Exceptions

Errors can occur when executing a process. The potential runtime errors in your process can be handled in one of the following ways:

  • Catch Specific: Used to catch a specific kind of fault at activity, scope, or process levels.
  • Catch All: Used to catch all error or faults thrown at the selected level.
Note: You can add an error transition to an activity or a group to specify the transition to take in case of an error.