Service Process Modeling
A service process is a stateless, high performance process that is not audited or persistent. Service processes run in-memory and so they should be of short duration and have a single function. For example, retrieving information from a database.
Service processes should be free of side effects. In other words, they should not change anything outside the scope of the process itself, like updating mission critical data. This is because service processes are not transactional and therefore, there is no provision to roll back changes if a task fails.
When modeling a service process, you must specify a deployment target. You can deploy service processes to either:
- the process engine
- the pageflow engine
The deployment target you choose depends on whether you are invoking your service processes from business or pageflow processes.
You can invoke a service process from the following process types:
- As a sub-process (either static or dynamic) from all process types. You can invoke a service process from a sub-process in the following process types:
- business process; when the service process has process deployment target selected.
- pageflow process; when the service process has pageflow deployment target selected.
- service process; when, at the minimum, the invoked service has the same deployment targets selected.
- business service; when the service process has process deployment target selected.
- case action process; when the service process has either the process or pageflow deployment target selected.
For more information, see TIBCO Business Studio - BPM Edition Modeling Guide.
- As a REST service.
- Using the BPM REST API.
When you are invoking a service process from a sub-process, your service process must have a start event of type None.
As service processes should be of short duration and have only one function, the following activity types are not supported in service processes.
| Activity Type | Description |
|---|---|
| User tasks | No direct user interaction with a service process is supported. |
| Manual ad-hoc activities | No direct user interaction with a service process is supported. |
| Event sub-processes responding to externally sourced API calls and inter-process signals. | This could result in unacceptably long pauses and, as service processes can be invoked from both pageflows and business services, this feature is disabled for service processes. Event sub-processes for local process signals are supported. |
| Attached Sub-process calls to non-service process types. | Service processes can only synchronously invoke other service processes. (They must have the same deployment targets set). However, they can invoke conventional stateful business processes in asynchronous-detached mode. |
| Non-boundary timers | Timers that pause rather than monitor the execution of a thread of a service process are not supported. |
A service process is stored under the Processes branch of the Project Explorer alongside business and pageflow processes.
Example - Calling a Service Process from a Sub-Process
This example shows how to model a business process that invokes a service process from a sub-process:
In this example, a Find Case Reference script task finds the customer's case reference. The Fetch Registered Customer sub-process calls the following service process:
The Fetch Registered Customer sub-process invokes a service process. To enable your service process to be called from a sub-process, the service process must have a start type of none. The script task in the service process retrieves the customer details for the supplied customer case reference. The Show Registered Customer user task displays the details of the registered customer.