---
title: "10.9 Process Instances, Unmodeled Activities, and Public Processes"
chapter: "10 Process"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "308-310"
---
> 10 Process · páginas 308-310 · [índice](../README.md)
## 10.9 Process Instances, Unmodeled Activities, and Public Processes
A **Process** can be executed or performed many times, but each time is expected to follow the steps laid out in the **Process** model. For example, the **Process** in Figure 10.1 will occur every Friday, but each *instance* is expected to perform **Task** “Receive Issue List,” then **Task** “Review Issue List,” and so on, as specified in the model. Each *instance* of a **Process** is expected to be valid for the model, but some *instances* might not, for example if the **Process** has manual **Activities**, and the performers have not had proper instruction on how to carry out the **Process**. In some applications it is useful to allow more **Activities** and **Events** to occur when a **Process** is executed or performed than are contained in the **Process** model. This enables other steps to be taken as needed without changing the **Process**. For example, *instances* of the **Process** in Figure 10.1 might execute or perform an extra **Activity** between **Task** “Receive Issue List” and **Task** “Review Issue List.” These *instances* are still valid for the **Process** model in Figure 10.1, because the *instances* still execute or perform the **Activities** in the **Process**, in the order they are modeled and under conditions specified for them. There are two ways to specify whether unmodeled **Activities** are allowed to occur in **Process** *instances*:
- If the isClosed attribute of a Process has a value of false or no value, then interactions, such as sending and receiving **Messages** and **Events**, MAY occur in an *instance* without additional flow elements in the **Process**. Unmodeled interactions can still be restricted on particular **Sequence Flow** in the **Process** (see next bullet). If the isClosed attribute of a **Process** has a value of *true*, then interactions, such as sending and receiving **Messages** and **Events**, MAY NOT occur without additional flow elements in the **Process**. This restriction overrides any unmodeled interactions allowed by **Sequence Flows** in the next bullet.
- If the isImmediate attribute of a Sequence Flow in a Process has a value of false, then other Activities and interactions not modeled in the **Process** MAY be executed or performed during the **Sequence Flow**. If the isImmediate attribute has a value of *true*, then **Activities** and interactions not modeled in the **Process** MAY NOT be executed or performed during **Sequence Flow**. In *non-executable* **Processes** (isExecutable attribute has value false, or defaults to false), **Sequence Flows** with no value for isImmediate are treated as if the
- value were *false*. In *executable* **Processes** (isExecutable attribute has value true, or defaults to true), **Sequence Flows** with no value for isImmediate are treated as if the value were *true*. *Executable* **Processes** cannot have a *false* value for the isImmediate attribute.
Restrictions on unmodeled **Activities** specified with isClosed and isImmediate apply only under executions or performances (*instances*) of the **Process** containing the restriction. These **Activities** MAY occur in *instances* of other
When a **Process** allows **Activities** to occur that the **Process** does not model, those **Activities** might appear in other **Process** models. The executions or performances (*instances*) of these other **Processes** might be valid for the original **Process**. For example, a **Process** might be defined similar to the one in Figure 10.1 that adds an extra **Activity** between **Task** “Receive Issue List” and **Task** “Review Issue List.” The **Process** in Figure 10.1 might use isClosed or isImmediate to allow other **Activities** to occur in between **Task** “Receive Issue List” and **Task** “Review Issue List.” When the **Process** is executed or performed, then *instances* of the other **Process** (the one with the extra step in between **Task** “Receive Issue List” and **Task** “Review Issue List”) will be valid for the **Process** in Figure 10.1. Modelers can declare that they intend all *instances* of one **Process** will be valid for another **Process** using the supports association between the **Processes**. During development of these **Processes**, support might not actually hold, because the association just expresses modeler intent. A common use for model support is between *private* and *public* **Processes**, see “Overview” (page 21). A *public* **Process** contains **Activities** visible to external parties, such as *Participants* in a **Collaboration**, while a *private* **Process** includes other **Activities** that are not visible to external parties. The hidden **Activities** in a *private* **Process** are not modeled in the *public* **Process**. However, it is expected that *instances* of the *private* **Process** will appear to external parties as if they could be *instances* of the *public* **Process**. This means the *private* **Process** supports the *public* **Process** (it is expected that all *instances* of the *private* **Process** will be valid for the *public* one). A **Process** that supports another, as a *private* **Process** can to a *public* **Process**, does not need to be entirely similar to the other **Process**. It is only REQUIRED that *instances* of the **Process** appear as if they could be *instance* of the other **Process**. For example Figure 10.127 shows a *public* **Process** at the top with a **Send Task** and **Receive Task**. A supporting *private* **Process** is shown at the bottom. The *private* **Process** sends and receives the same **Messages**, but using **Events** instead of **Tasks**. It also introduces **Activities** not modeled in the *public* **Process**. However all *instances* of the *private* **Process** will appear as if they could be *instances* of the *public* one, because the **Messages** are sent and received in the order REQUIRED by the public **Process**, and the *public* **Process** allows unmodeled **Activities** to occur.
*Figure 10.127 – One Process supporting to another* (p. 309)
In practice, a *public* **Process** looks like an underspecified *private* **Process**. Anything not specified in the *public* **Process** is determined by the *private* one. For example, if none of the *outgoing* **Sequence Flows** for an **Exclusive Gateway** have conditionExpressions, the *private* **Process** will determine which one of the **Activities** targeted by the **Sequence Flows** will occur. Another example is a **Timer Event** with no EventDefinition. The *private* **Process** will determine when the timer goes off.