Processes

Processes capture and describe the flow of business information in an enterprise between different data sources and destinations.

Processes comprise of activities that accomplish tasks. The flow of data between activities in a process is represented using transitions, conditions, and mappings. TIBCO Business Studio™ for BusinessWorks™ provides design palettes containing activities and transitions that can be used to develop business processes.

Parent Process

A process can call another process, or a subprocess. The process that is making the call is referred to as a caller process or a parent process.

Subprocess

A subprocess can be called by a parent process, or another subprocess. In the case where a subprocess is calling another subprocess, the subprocess that is making the call is the parent process. The called process is referred to as a subprocess or a child process.

There are two types of subprocesses: direct or service.

• A direct subprocess is non-WSDL-based. This means you do not need to use a WSDL to define subprocess details. Instead, you can set input and output information on the Start and End activities in the subprocess interface.

• A service subprocess requires a WSDL to define subprocess details, and can be configured to use SOAP or REST binding.

There are two ways a subprocess can be called: inline or non-inline.

• An inline subprocess is part of the same job as the parent process, which means they share the same engine thread. A non-inline, or a spawned, subprocess is a separate job, which means it can use a separate engine thread. For example, when a service subprocess invokes a process using the Invoke activity, the process executes on the same thread if a reply is involved.
  Note: If the parent process of a direct inline subprocess is faulted, the subprocess is cancelled as well. Inline direct subprocesses are sensitive to all state changes of the parent process, for example, suspend, resume, or cancel.
• Non-inline subprocesses execute on a separate, engine thread.
  Note: If the parent process of an inline, or a non-inline, service subprocess is faulted, the subprocess is cancelled as well. Service subprocesses, similar to inline direct subprocesesses, are sensitive to any state changes the parent process undergoes.

Component Process

The execution of a process is triggered by various events. Often the business logic that is designed to react to a particular event is spread across multiple processes. One of the processes is special and it reacts to the original event and triggers the execution of the other processes. This special process is referred to as the component process or main process. A component process is responsible for initiating the job at run time.

A component process is designed to react to various events and these events are triggered by Process Starters, Signal-Ins, and Bindings.

Stateful Process

A process that relies on the ActiveMatrix BusinessWorks™ engine to maintain its state across invocations is called a stateful process. As the engine maintains its state, a stateful process does not require an external persistence store.

Stateless Process

A process that does not require the ActiveMatrix BusinessWorks engine to maintain its state across invocations is called a stateless process. If needed, a developer can design a stateless process to manually maintain the process state by using an external persistence store.

Process Services

A process can provide services to other processes. A process service exposes the operations provided by the process and is implemented using a WSDL or a JSON file. When the process is implemented by a component, the process services are exposed as component services, which then need to be configured using bindings.

Process References

A process can consume services provided by other processes or by external service providers. A process reference exposes the operations consumed by the process and is implemented using a WSDL or a JSON file. A process reference can be configured to invoke a process or an external service.

When the process is implemented by a component, the process references that are not configured to call a process or an external service through a binding are exposed as component references, which then need to be configured using bindings.

Activator Process

An activator process is a special process that can be used to perform pre-processing and post-processing tasks when the application is started and stopped respectively. The activator process contains a process service with two operations: OnStartup and OnShutDown.

The OnStartup operation is called when an application is started, but before executing any other processes in the application. The OnStartup operation can be used to implement any pre-processing tasks that must be performed for the application before the regular processing starts. For example, the OnStartup operation can be used to check if the database tables required by an application exist, and create them if they do not exist. If this process instance faults due to an unhandled exception, the application does not start.

The OnShutDown operation is called when an application is stopped, but after stopping and completing all other processes in the application. The OnShutDown operation can be used to implement any post-processing tasks that must be performed for the application after the regular processing is complete. For example, the OnShutDown operation can be used to send an email to administrators notifying them that the application is being stopped.

The activator process can only be configured for an application module. There can be only one activator process for an application module. However, the activator process can invoke one or more sub-processes.

Note: The activator process in ActiveMatrix BusinessWorks 6.x provides the same functionality as that of the OnStart and OnShutDown activities in ActiveMatrix BusinessWorks 5.x.

For information on how to create an activator process, see Creating an Activator Process in the TIBCO ActiveMatrix BusinessWorks™ Application Development guide.

A simple business process can be developed by adding activities in sequence, and the connecting the activities using transitions with or without conditions. Developing a complex business process typically involves developing a component process and one or more subprocesses. Use of subprocesses makes the complex business process easier to understand and debug. At runtime, the in-line subprocesses do not create a new job, but are executed on the job created by their calling process.