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.
Service processes 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.
The deployment target you choose depends on whether you are invoking your service processes from business or pageflow processes.
- 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.
- As a REST service. Using the TIBCO BPM Enterprise REST API. See the TIBCO® BPM Enterprise Developer's Guide for more information about the APIs provided by TIBCO BPM Enterprise.
When you are invoking a service process from a sub-process, your service process must have a start event of type Start Request Event. When you are invoking a service process as a REST process, your service process must have a start event of type Start Request Event. If you are invoking a service process from both a sub-process and as a REST process, your service process must have both a start event of type Start Request Event and a start event of type Start Request Event. See Example - Calling a Service Process From a Sub-Process.
If your service process is only going to be invoked as a REST service, it is more efficient to create your service process with a start type of Start Request Event and select the pageflow engine as the deployment target. This is because a service process deployed into pageflow run-time is already invokable using a REST service.
| Activity Type | Description |
|---|---|
| Incoming request event | An incoming request event may be waiting to be triggered for an arbitrary period of time. |
| Signal event handlers | A signal event handler event may be waiting to be triggered for an arbitrary period of time. |
| User tasks | No direct user interaction with a service process is 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 Start Request Event. 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.