Skip to main content

Starting a Process

In tSM, the most common method to initiate a business process is by using a none start event and associating the process with a primary business entity—such as an order or a ticket. This approach ensures that when a new entity is created, the corresponding process instance starts automatically and is directly linked to that entity’s lifecycle.

Standard Approach: Entity-Linked Processes​

The most common and straightforward method to start a process in tSM is to associate a process definition as the main process of a particular business entity type. Whenever a new instance of that entity is created, the corresponding process instance is automatically started.

  • Order Example:
    Suppose you have defined a process as the main process for a certain order type (e.g., “Internet Installation Order”). When a new order of this type is created, the associated process starts automatically. The process instance is linked to the order via a businessKey, ensuring that you can see the process history and current status directly from the order’s user interface.

  • Ticket Example:
    Similarly, if a process is defined as the main process for a certain ticket type (e.g., “Support Ticket”), then every time a new ticket of that type is created, a corresponding process instance starts and is associated with that ticket’s businessKey.

This tight coupling ensures visibility and traceability: you can always view the associated process instances and their histories from the entity’s screen, making it easy to track the workflow from creation through completion.

Dynamic Process Selection​

In some cases, you might need more flexibility in selecting which process to start. tSM provides configuration options that allow dynamic choice of the process definition at runtime. For example:

  • SpEL Expressions for Ticket Types:
    Within the ticket type configuration, you can specify a Spring Expression Language (SpEL) expression to determine which process should start when a ticket is created. This expression can evaluate various attributes (e.g., ticket category, priority) and return the appropriate process definition ID or key.

  • Catalog-Based Selection for Orders:
    For orders, tSM can be configured so that the process is chosen from a catalog. The catalog might match product types, operation types, or other criteria. For example, if an order line includes a product “Internet Optical 500” and the operation is “Add,” the system can dynamically select the correct process definition that sets up the required connectivity.

Multiple Main Processes per Entity​

While the usual pattern is to have one main process per entity type, it is not a strict limitation. If needed, you can define multiple main processes for the same entity. Each main process will start upon entity creation, and all will share the same businessKey, linking them to the entity. This can be useful in complex scenarios where multiple parallel workflows need to be triggered for a single entity.

Starting Without an Owning Entity​

tip

For most scenarios, we recommend using entity-linked processes for clear visibility and traceability. Only use standalone processes when necessary, such as for scheduled tasks or external triggers.

It is possible to start a process without linking it to an entity upfront. This is less common, but useful for scheduled tasks or for processes triggered by external messages.

  • Timer Start Event:
    A timer start event can create a new process instance at a given time or interval, independent of any entity. If desired, you can assign a businessKey later in the process flow. However, until then, the process is not visible on any entity screen, making debugging more challenging.

  • Message Start Event:
    A message start event begins a process when a named message is received. Similar to the timer start event scenario, no entity association exists at the start. You must set the businessKey programmatically inside the process if necessary.

Using timer or message start events without an immediate entity association increases complexity, as you lose the built-in visibility and tracking that comes from linking the process to an entity. You need to associated it manually later in the process flow.

Start Event Types​

None Start Event​

A none start event means the trigger is unspecified in BPMN. In tSM, none start events are used for processes that begin automatically with entity creation, or are started through the API (e.g., runtimeService.startProcessInstanceByKey(...)). Subprocesses must also have none start events.

Timer Start Event​

A timer start event triggers the creation of a process instance at a specified time or according to a time cycle. For example:

This configuration starts the process 4 times, every 5 minutes, beginning on March 11, 2022, at 12:13 (UTC+01):

<startEvent id="theStart">
  <timerEventDefinition>
      <timeCycle>R4/2022-03-11T12:13+01/PT5M</timeCycle>
  </timerEventDefinition>
</startEvent>

Alternatively, starting once at a specific date/time (in GMT):

<startEvent id="theStart">
  <timerEventDefinition>
    <timeDate>2025-03-11T12:13:14Z</timeDate>
  </timerEventDefinition>
</startEvent>

Message Start Event​

warning

Though supported in tSM, message start events are less common since entity-linked starts are the norm.

A message start event initiates a process when a named message is received. This allows external triggers to start a process instance:

  • The name of the message start event must be unique across a given process definition, i.e., a process definition must not have multiple message start events with the same name. The engine throws an exception upon deployment of a process definition in case two or more message start events reference the same message or if two or more message start events reference messages with the same message name.
  • The name of the message start event must be unique across all deployed process definitions. The engine throws an exception upon deployment of a process definition in case one or more message start events reference a message with the same name as a message start event already deployed by a different process definition.
  • Process versioning: Upon deployment of a new version of a process definition, the message subscriptions of the previous version are canceled. This is also the case for message events that are not present in the new version.

Signal Start Event​

warning

Signal start events are supported by the tSM Process Engine but are not generally used in tSM.

A signal start event can be used to start a process instance using a named signal.

When deploying a process definition with one or more signal start events, the following considerations apply:

The name of the signal start event must be unique across a given process definition, i.e., a process definition must not have multiple signal start events with the same name. The engine throws an exception upon deployment of a process definition in case two or more signal start events reference the same signal or if two or more signal start events reference signals with the same signal name. Contrary to message start events, the name of the signal start event does not have to be unique across all deployed process definitions. Process versioning: Upon deployment of a new version of a process definition, the signal subscriptions of the previous version are canceled. This is also the case for signal events that are not present in the new version.

Conditional Start Event​

warning

Conditional events are supported by the tSM Process Engine but are not generally used in tSM.

A conditional start event can be used to start a process by evaluating some condition. One process can have one or more conditional start events.

If more than one conditions are fulfilled the respective number of processes will be triggered.

When deploying a process definition with conditional start events, the following considerations apply:

  • The condition of the conditional start event must be unique across a given process definition, i.e., a process definition must not have multiple conditional start events with the same condition. The engine throws an exception upon deployment of a process definition in case two or more conditional start events contain the same condition.
  • Process versioning: Upon deployment of a new version of a process definition, the conditional subscriptions of the previous version are cancelled. This is also the case for conditional events that are not present in the new version.