![]() |
Event-driven process chains allow for the representation of business processes of an organization. In doing so a concise and intuitively understandable visualization of the process is emphasized in particular. An event-driven process chain basicallly consists of process steps and events. Process steps represent work steps and events represent states or events within the process. Event-driven process chains are bipartite graphs which means that only two plan elements of different type can be linked. Thus, for instance a link between two process steps is not possible. Process steps and events are linked by the control flow. Event-driven process steps in ARCWAY Cockpit contain only a small, optimized selection of syntax elements. |

Competencies present the parts that are involved in the contained process steps. Three types of competencies are available - Business Function, Organisational Unit and Application.
![]() |
Process steps are work steps. |
![]() |
Events represent an event or a state in a process. Every process in an event-driven process chain diagram starts and ends always with an event. |
![]() |
Processes are semantically the same as process steps.
This can be recognized by the similarity of the two plan element symbols.
The process, however, additionally indicates that it is refined in
another plan.
Thus, the process Article Production could be refined
in another plan so that the process of producing the article is described in
more detail there.
|
![]() |
The storage element represents a passive component of the process chain. Processes can read information from or load information onto the storage. This allows for showing additional information about used data, supported systems or created files in the model. |
![]() |
The AND-Splitter and
AND-Connector templates indicate a parallelization in the process.
This means that the process steps behind an AND-Splitter
within the process chains can be executed simultaneously and independently of each other. |
![]() |
The templates OR-Splitter and
OR-Connector mark a case differentiation within
the process. This means that the process steps behind an
OR-Splitter within the process chains
are alternatives. It has to be said that at least one of the options has to be selected.
It is also possible, however, that several of these options are executed. |
![]() |
The templates XOR-Splitter and
XOR-Connector mark an exclusive case differentiation
in the process. This means that the process steps behind a
XOR-Splitter within the process chains are alternatives.
In opposition to the OR-Splitter and OR-Connector, however,
it is not possible that several of these options are executed. Thus, it is an exclusive or.
The XOR-Connector is the opposite operation to the
XOR-Splitter and joins the alternative chains again. |
![]() |
A plan element that contains another element graphically is also
considered to be its container in the repository. This behavior is used in the example to display the competency for a process step. The "Customer Management" is responsible for the process step "Search Customer Data" in the example. |
![]() |
A control flow creates causality relations between process steps,
processes and events. The plan element that is anchored to the arrow succeeds
the plan element that is anchored to the unmarked end of the
control flow. The process step "Search Customer Data" is the successor of the event "Customer likes to order sth." in the example. |
![]() |
A control flow that connects a process step and a storage creates
an access relation between those two plan elements. In this case the
arrows of the control flow decide on the reading direction. The storage "Order Item" is read by the process step "Collect Customer Order" in the example. |
Related Topics:
Extended drawing support for event-driven process chains