This is the fifth day of my participation in Gwen Challenge

subprocesses

subprocesses

describe

• A sub-process is a node containing other nodes, gateways, events, and so on
• It is a process in itself and part of a larger process. A child process is defined completely within the parent process, so it is called an embedded child process
• There are two main scenarios for subprocesses:
  • Subprocesses can be modeled using inheritance: The subprocesses of many modeling tools can be folded to hide the internal details of the subprocesses, showing a high-level end-to-end overview of the business processes
  • A subprocess creates a new event scope: events thrown during the execution of the subprocess can be captured by the boundary events defined at the edge of the process, creating an event scope that is limited to that subprocess
• Limitations on using subprocesses:
  • A subprocess can contain only one empty start event, no other type of start event can be used, and a subpath must have at least one end node
  • Sequential flows cannot cross the boundaries of subprocesses

Graphic tag

• Subprocesses are shown as standard nodes (rounded rectangles), and the bottom process is folded, showing only the name and a plus sign, showing a high-level overview of the process:

• The bottom process is expanded, and the steps of the subprocess are displayed within the boundaries of the subprocess:

• Subprocesses are used primarily to define the scope of the corresponding event
• Example:
  • Survey software/survey referral tasks need to be executed synchronously, both tasks need to be completed at the same time, before second-line support can be resolved. Here, the scope of timers (such as nodes that need to complete in time) is limited by subprocesses:

The XML content

• Subprocesses are defined as subprocess elements. All nodes, gateways, events, etc. Are part of the subprocess and all need to be in this element

<subProcess id="subProcess">

  <startEvent id="subProcessStart" />. other Sub-Process elements ...<endEvent id="subProcessEnd" />

 </subProcess>
Copy the code

Event subflow

describe

• Event subprocesses are subprocesses that are triggered by events. Is new in BPMN 2.0
• Event subprocesses can be added to the process level or to any subprocess level
• The event used to trigger the event subflow is configured using the start event, so the event subflow does not support null-start events
• Event subprocesses can be triggered by message events, error events, signal events, timer events, or compensation events. A subscription to the start event is created when the scope (process instance or subprocess) containing the event subprocess is created. The subscription is also deleted when the scope is destroyed.
• Event subflows can be interrupted or non-interrupted
  • An interrupted subprocess cancels all processes in the current scope
  • The non-interrupt event subprocess creates a new synchronization branch
  • The interrupt event subflow is triggered only once by each active state host
  • A non-interrupt event subprocess can fire multiple times
  • Whether the subprocess is interrupted uses the start event configuration of the event subprocess
• The event subprocess cannot have any incoming and outgoing flows
  • When an event triggers an event subflow, it makes no sense to input a sequential flow
  • When the event subprocess ends, whether the current scope is ended (in the case of the interrupt event subprocess or non-interrupt, the synchronous branch generated by the subprocess ends
• Limitations of event subflows:
  • Activiti supports only interrupt event subflows
  • Activiti only supports event subflows that use error start events or message start events

Image tag

• Event subprocesses can be displayed as inline subprocesses with dashed borders

The XML content

• The XML content of the event subprocess is the same as the embedded subprocess, but the triggeredByEvent property is set to true

<subProcess id="eventSubProcess" triggeredByEvent="true">.</subProcess>
Copy the code

The instance

• An instance of an event subflow triggered by an error start event, which is placed at the process level and acts on the process instance

XML for the event subprocess:

<subProcess id="eventSubProcess" triggeredByEvent="true">
        <startEvent id="catchError">
                <errorEventDefinition errorRef="error" />
        </startEvent>
        <sequenceFlow id="flow2" sourceRef="catchError" targetRef="taskAfterErrorCatch" />
        <userTask id="taskAfterErrorCatch" name="Provide additional data" />
</subProcess>
Copy the code

Event subprocesses can also be added as inline subprocesses. If added as an inline subprocess, it is actually an alternative to boundary events

• Example:
  • In both cases, the embedded subprocess throws an error event, and in both cases the error is caught and handled using a user task

Relative to the

• Both scenarios perform the same tasks, but the way they are modeled is different:
  • Inline subprocesses are executed using the same process as the execution scope host:
    • This means that an embedded subprocess can access internal variables in its scope
    • When boundary events are used, the process executing the embedded subprocess is deleted and a process is generated to continue executing according to the sequential flow of boundary events, which means that the variables created by the embedded subprocess are no longer in effect
  • When an event subprocess is used, the event is handled entirely by the subprocess it adds.
    • When boundary events are used, the event is handled by the parent process
• These two differences can help determine whether to use boundary events (embedded subprocesses) or embedded event subprocesses (event subprocesses) to solve a particular process modeling or implementation problem

Transaction subprocess

describe

• A transaction subprocess is an embedded subprocess that can be used to put multiple processes into a single transaction
• A transaction is a logical unit that brings together individual nodes so that they can succeed or fail together
• There are three possible outcomes of a transaction:
  • The transaction succeeded without cancellation or termination due to a problem
    • If the transaction subprocess is successful, execution continues using the outgoing sequential flow
    • If the process later throws a compensation event, the successful transaction may be compensated
    • Like normal inline subprocesses, a transaction may be compensated with an intermediate compensation event after success
  • The transaction is cancelled and the process reaches the cancellation end event
    • All processes are terminated and deleted, and a single process that triggers compensation continues execution by canceling the boundary event
    • After compensation is complete, the transaction subprocess executes down using the out-order flow of the unbounded transaction
  • The transaction is terminated by a problem, an error event is thrown and not caught in the transaction subprocess(This is also applied if the error is handled by the boundary event of the transaction subprocess.)
    • Compensation will not be performed
• Transaction results in three different ways:

• Relationship between BPMN and ACID transactions: BPMN and ACID transactions should not be confused. BPMN subprocesses are not in the domain of ACID transactions
• BPMN transactions differ from technical transactions in the following ways:
  • ACID transactions are generally short-term. BPMN transactions can take hours, days, or even months to complete:
    • Consider that the nodes contained in a transaction may have user tasks, and the average human response time is longer than the application time
    • In other cases, BPMN transactions may wait for some transaction event to occur, such as to execute in some order
    • This operation typically takes longer to complete than updating a piece of data in a database or saving a piece of information to a transactional queue
  • BPMN transactions typically span multiple ACID transactions because one technical transaction cannot be maintained throughout the entire business node
  • BPMN transactions span multiple ACID transactions and therefore lose the properties of ACID:
    • For example, in the example above, assume that the hotel reservation and credit card operation are performed in a separate ACID transaction, and assume that the hotel reservation node has been successful
    • We’re in limbo because we booked a hotel but haven’t used our credit card yet
    • In an ACID transaction, there is also an intermediate unstable state in which different operations are performed sequentially
    • The difference is that this intermediate state is visible to the outside of the transaction. For example, if a reservation is made through an external reservation service, other parts using the same reservation service can see that the hotel is booked. This means that when implementing business transactions, we completely lose the isolation property (giving up isolation allows for higher concurrency for ACID transactions, is fully controlled, and the intermediate unstable state only lasts a short time)
  • BPMN business transactions also cannot be rolled back in the usual way:
    • BPMN transactions span multiple transactions, and some ACID transactions may already be committed when the BPMN transaction is canceled. This cannot be rolled back
• BPMN transactions run for a long time, lack of isolation, and rollback mechanisms need to be treated differently:
  • Perform rollback with compensation:
    • If a cancellation event is thrown by the transaction scope, the node that has successfully executed is affected and compensation is performed using a compensation handler
  • The lack of isolation is usually addressed using domain-specific solutions:
    • In the example above, a hotel room might be shown to a second customer before we confirm that the first customer has paid. While this may not be in line with business expectations, the reservation service may choose to allow some excessive reservations
  • Transactions are interrupted because of the risk, and the service must handle this:
    • If a hotel has been booked but no payment has been made (because the transaction has been interrupted), the reservation service needs to choose a policy that cancels the reservation if payment has not been made after the maximum allowed time for a hotel room to be booked
• In summary,ACID deals with the usual problems: rollbacks, isolation levels, and heuristic results that require finding domain-specific solutions to deal with when implementing business transactions
• Current limitations of BPMN transactions:
  • The BPMN specification requires the process engine to handle events according to the protocol of the underlying transaction:
    • For example, if the underlying protocol triggers a cancellation event, the transaction is canceled
• Consistency and optimized concurrency at the top of an ACID transaction:
  • BPMN transactions guarantee consistency:
    • Either all nodes succeed
    • Some nodes succeed and others succeed are compensated
    • Either way, there will be consistent results
    • To discuss some things inside Activiti, the BPMN transaction consistency model is superimposed on the process consistency model
  • The Activiti execution process is transactional and uses optimistic locking concurrently. In Activiti,BPMN error, cancel, and compensation events are built on the same ACID transaction and optimistic lock:
    • Cancelling the end event can only trigger compensation for what it actually arrived at
    • If the previous service task threw an undeclared exception
    • The effect of the compensation processor cannot be committed if the participant of the underlying ACID transaction sets the transaction to have to be rolled back.
    • When two concurrent processes reach the cancel end event
    • Compensation may be triggered twice and fail due to an optimistic lock exception
    • Note When IMPLEMENTING BPMN transactions in Activiti, the same rules apply to both normal and subprocesses
    • To ensure consistency, it is important to consider a way to implement an execution model that is optimistic transactional

Graphic tag

• The transaction subprocess is shown as an embedded subprocess, with a double line border

The XML content

• The transaction subprocess uses the transaction tag

<transaction id="myTransaction" >.</transaction>
Copy the code

The instance

Invoke activities (subprocesses)

describe

• BPMN 2.0 distinguishes between ordinary subprocesses (embedded subprocesses) and calling nodes:
  • Similarities: Both call the subprocess when the process reaches the node
  • Difference:
    • The calling node refers to a process that defines a process outside the process
    • Subprocesses are embedded in the original process definition
    • The main scenario for using invocation nodes is the need to reuse a process definition that needs to be invoked by many other process definitions
• When the process executes to the calling node, a new branch is created that is the branch of the process that reached the calling node
• This branch is used to execute the subprocess, which is created and executed by default, just like a normal process
• The parent process waits for the child process to complete before proceeding

Graphic tag

• The call node appears the same as the subprocess, but with thick borders (both collapsed and expanded). Depending on the modeling tool, the call node can also be expanded but shown as a collapsed subprocess

The XML content

<callActivity id="callCheckCreditProcess" name="Check credit" calledElement="checkCreditProcess" />
Copy the code

• The process definition of a subprocess is resolved at execution time, meaning that the subprocess can be deployed separately from the calling process

Passing variables

• Process variables can be passed to a subprocess and vice versa: when it starts, data is copied to the subprocess and back to the main process when it finishes

<callActivity id="callSubProcess" calledElement="checkCreditProcess" >
  <extensionElements>
          <activiti:in source="someVariableInMainProcess" target="nameOfVariableInSubProcess" />
          <activiti:out source="someVariableInSubProcss" target="nameOfVariableInMainProcess" />
  </extensionElements>
</callActivity>
Copy the code

The Activiti extension is used here to simplify BPMN standard element calls to dataInputAssociation and dataOutputAssociation, which are only valid when process variables are declared using the BPMN 2.0 standard way

• Expressions can also be used:

<callActivity id="callSubProcess" calledElement="checkCreditProcess" >
        <extensionElements>
          <activiti:in sourceExpression="${x+5}"" target="y" />
          <activiti:out source="${y+5}" target="z" />
        </extensionElements>
</callActivity>
Copy the code

z = y + 5 = x + 5 + 5
Copy the code

The instance

• Order processing flow chart: judge the client’s credit first and check that the credit stage is designed as a call node

• Process XML:

<startEvent id="theStart" />
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="receiveOrder" />

<manualTask id="receiveOrder" name="Receive Order" />
<sequenceFlow id="flow2" sourceRef="receiveOrder" targetRef="callCheckCreditProcess" />

<callActivity id="callCheckCreditProcess" name="Check credit" calledElement="checkCreditProcess" />
<sequenceFlow id="flow3" sourceRef="callCheckCreditProcess" targetRef="prepareAndShipTask" />

<userTask id="prepareAndShipTask" name="Prepare and Ship" />
<sequenceFlow id="flow4" sourceRef="prepareAndShipTask" targetRef="end" />

<endEvent id="end" />
Copy the code

• Child process: