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.

      See TIBCO Business Studio Modeling Guide for more information.

  • As either a SOAP service or a REST service.
  • Using either the BPM Web Service API or the BPM REST API. See TIBCO ActiveMatrix BPM Developer's Guide for more information about the APIs provided by ActiveMatrix BPM.

When you are invoking a service process from a sub-process, your service process must have a start event of type None. When you are invoking a service process as a REST or SOAP process, your service process must have a start event of type Message. If you are invoking a service process from both a sub-process and as a REST or SOAP process, your service process must have both a start event of type None and a start event of type Message. See Example 2 - Invoking a Service Process as a Sub-Process and as a Service.

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 none 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. Creating a service process this way means that you do not have to configure a web service interface. Not using a web service interface makes it easier when upgrading applications as there are restraints on upgrading applications with web service interfaces.

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.
Inbound message events and receive tasks that require correlation. Outbound message events are supported.
Event sub-processes responding to externally sourced signals/messages 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 internal 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 1 - 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.

Example 2 - Invoking a Service Process as a Sub-Process and as a Service

If you want to invoke your service process as a sub-process and as a web-service, then your service process must include both:
  • a start event of type None
  • and a start event of type Message

As above, the Fetch Registered Customer sub-process calls the following service process:

In this example, the service process has a start type of None and also a start type of message. Therefore, the service process can be invoked from the Fetch Registered Customer sub-process. It can also be consumed by another service. The WSDL file that defines the required message exchange is provided by the Update Customer start event.