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 Stateful and Stateless Processes

Stateful processes maintain the state across multiple operations. They are better suited when you need the server to maintain the state across operations. For processes that involve related message exchanges between the same or different consumers, conversations can be used to maintain state across operations.

Stateless processes do not maintain state. They are better suited when you need to process higher loads of requests as each operation is executed independently. They do not require correlation or conversations between multiple operations in a process, thus allowing the server to process each operation without maintaining any state information. The client can choose to maintain the state information, if needed.

Process Maintains State Data Sharing Conversations
Stateful Processes Across multiple operations and interfaces. Data can shared by activities across operations that executing as part of the same job. Uses conversations to enable correlation.
Stateless Processes Does not maintain state. Data is not shared. No conversations.

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. For more information, see Choosing Between Process Properties, Module Properties, Shared Module Properties, and Application Properties.

Variables are used to save the state at different levels. They can be classified into process variables, scope variables, and shared variables. For more information, see Choosing Between Process Variables, Scope Variables, and Shared Variables.

Choosing Between Process Properties, Module Properties, Shared Module Properties, and Application Properties

Properties can be classified into application properties, module properties, shared 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, Shared Module and Application Properties
Property 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.
  • Private module properties cannot be viewed from the Admin UI.
  • Not visible or changeable from Administrator.
Literal or shared resource reference.
  • Literal or a shared resource reference.
  • Private module property values cannot be edited from the Admin UI.
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.
Shared Module Properties
  • Visible within the module.
  • Visible within projects that contain dependencies to the Shared Module that the Shared Module Property came from.
  • Private module properties cannot be viewed from the Admin UI.
  • Not visible or changeable from the Admin UI.
Literal or a shared resource reference.
  • Literal or a shared resource reference.
  • Private module property values cannot be edited from the Admin UI.
  • Shared Module Properties are module properties that come from a Shared Module.
  • 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.
  • Can be used for activities, process properties, shared resources, and SOAP Bindings.
Application Properties Displays all the module properties in the application. These properties are visible in Administrator. Literal.
  • 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.

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 on sharing variables, see Using Shared Variables topic and the TIBCO ActiveMatrix BusinessWorks™ 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 either 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.