diff --git a/docs/documentation/installation/database-schema.md b/docs/documentation/installation/database-schema.md index 5ec2cfbb..67fed9c1 100644 --- a/docs/documentation/installation/database-schema.md +++ b/docs/documentation/installation/database-schema.md @@ -22,7 +22,7 @@ Operaton supports the following ways of installing the database schema: * Use the provided SQL scripts with the tools related to your database for a fully manual installation and update. A manual procedure allows you to fully control the SQL statements that are executed on your database instance and to adjust those statements to your needs if necessary. :::note[Isolation level] -READ COMMITED is the required isolation level for database systems to run Operaton with. +READ COMMITTED is the required isolation level for database systems to run Operaton with. You may have to change the default setting on your database when installing Operaton. For more information see the documentation on [isolation levels](../user-guide/process-engine/database/database-configuration.md#isolation-level-configuration). ::: @@ -131,7 +131,7 @@ Liquibase provides additional commands to preview all changes applied by command #### Migrate to Liquibase Liquibase provides workflows to update databases that were not set up using Liquibase from the very beginning. -For such a scenario to work, you need to populate a tracking table that represents the current state of your database with regards to the changelog file you want to update against. +For such a scenario to work, you need to populate a tracking table that represents the current state of your database with regard to the changelog file you want to update against. In other words, you need to let Liquibase know which parts of the changelog your database already contains. Perform the following steps to migrate your manual installation to Liquibase: @@ -171,4 +171,4 @@ If you need to apply multiple minor versions, you MUST execute the database alte ### Patch level update -Patch level updates will be delivered once applicable patches are issued, since no such updates have been needed so far. \ No newline at end of file +Patch level updates will be delivered once applicable patches are issued, since no such updates have been needed so far. diff --git a/docs/documentation/installation/full/tomcat/configuration.md b/docs/documentation/installation/full/tomcat/configuration.md index 3184a3a5..cd630eae 100644 --- a/docs/documentation/installation/full/tomcat/configuration.md +++ b/docs/documentation/installation/full/tomcat/configuration.md @@ -11,7 +11,7 @@ This page explains how to configure the full distribution for Tomcat Application ### LDAP -In order to setup LDAP for the Tomcat distribution, you have to perform the following steps: +In order to set up LDAP for the Tomcat distribution, you have to perform the following steps: ### Add the LDAP Library @@ -82,9 +82,9 @@ See our user guide for complete documentation on the [LDAP Identity Provider Plu ### HAL Resource Caching -If you use LDAP as Indentity Provider, you should consider [activating caching](../../../reference/rest/overview/hal.md#caching-of-hal-relations) of -Users and Groups in the Operaton webapplication. In order to activate this, add the following -configuration to the `web.xml` file of Operaton webapplication +If you use LDAP as Identity Provider, you should consider [activating caching](../../../reference/rest/overview/hal.md#caching-of-hal-relations) of +Users and Groups in the Operaton web application. In order to activate this, add the following +configuration to the `web.xml` file of Operaton web application (`operaton-webapp-tomcat-$PLATFORM_VERSION.war/WEB-INF/web.xml`): ```xml @@ -241,8 +241,8 @@ Please also see the detailed overview about the [Cookie Security](../../../webap ### Security-related HTTP headers in Webapps -To customize the configuration of security-related HTTP headers in the web applications its deployment descriptor needs -to be adjusted. You can find it under `WEB-INF/web.xml`. +To customize the configuration of security-related HTTP headers in the web applications, adjust each web application's +deployment descriptor. You can find it under `WEB-INF/web.xml`. Please watch out for the following section: ```xml @@ -284,4 +284,4 @@ You can change the default behavior by adding configuration parameters to the se ``` Please also see the detailed overview about the -[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure). \ No newline at end of file +[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure). diff --git a/docs/documentation/installation/full/wildfly/configuration.md b/docs/documentation/installation/full/wildfly/configuration.md index 081bb15d..83f7980f 100644 --- a/docs/documentation/installation/full/wildfly/configuration.md +++ b/docs/documentation/installation/full/wildfly/configuration.md @@ -12,7 +12,7 @@ This page explains how to configure the full distribution for the WildFly applic ### LDAP -In order to setup LDAP for the WildFly Application Server distribution, you have to perform the following steps: +In order to set up LDAP for the WildFly Application Server distribution, you have to perform the following steps: ### Adjust the Process Engine Configuration @@ -197,4 +197,4 @@ You can change the default behavior by adding configuration parameters to the se ``` Please also see the detailed overview about the -[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure). \ No newline at end of file +[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure). diff --git a/docs/documentation/introduction/architecture.md b/docs/documentation/introduction/architecture.md index f608613a..8cce17dc 100644 --- a/docs/documentation/introduction/architecture.md +++ b/docs/documentation/introduction/architecture.md @@ -8,7 +8,7 @@ sidebar_position: 30 Operaton is a Java-based framework. The main components are written in Java and we have a general focus on providing Java developers with the tools they need for designing, implementing and running business processes and workflows on the JVM. Nevertheless, we also want to make the process engine technology available to non-Java developers. This is why Operaton also provides a REST API which allows you to build applications connecting to a remote process engine. -Operaton can be used both as a standalone process engine server or embedded inside custom Java applications. The embeddability requirement is at the heart of many architectural decisions within Operaton. For instance, we work hard to make the process engine component a lightweight component with as little dependencies on [third-party libraries](./third-party-libraries/index.md) as possible. Furthermore, the embeddability motivates programming model choices such as the capabilities of the process engine to participate in Spring Managed or JTA [transactions and the threading model](../user-guide/process-engine/transactions-in-processes.md). +Operaton can be used both as a standalone process engine server or embedded inside custom Java applications. The embeddability requirement is at the heart of many architectural decisions within Operaton. For instance, we work hard to make the process engine component a lightweight component with as few dependencies on [third-party libraries](./third-party-libraries/index.md) as possible. Furthermore, the embeddability motivates programming model choices such as the capabilities of the process engine to participate in Spring Managed or JTA [transactions and the threading model](../user-guide/process-engine/transactions-in-processes.md). ## Process Engine Architecture @@ -64,10 +64,10 @@ The individual process engine instances do not maintain session state across tra Operaton doesn't provide load-balancing capabilities or session replication capabilities out of the box. The load-balancing function would need to be provided by a third-party system, and session replication would need to be provided by the host application server. -In a clustered setup, if users are going to login to the web applications, an extra step will need to be taken to ensure that users aren't asked to login multiple times. Two options exist: +In a clustered setup, if users are going to log in to the web applications, an extra step will need to be taken to ensure that users aren't asked to log in multiple times. Two options exist: 1. "Sticky sessions" could be configured and enabled within your load balancing solution. This would ensure that all requests from a given user are directed to the same instance over a configurable period of time. -2. Session sharing can be enabled in your application server such that the application server instances share session state. This would allow users to connect to multiple instances in the cluster without being asked to login multiple times. +2. Session sharing can be enabled in your application server such that the application server instances share session state. This would allow users to connect to multiple instances in the cluster without being asked to log in multiple times. If neither of the above approaches are implemented in a cluster setup, connections to multiple nodes - intentionally or via a load-balancing solution - will result in multiple login requests. @@ -76,7 +76,7 @@ If neither of the above approaches are implemented in a cluster setup, connectio The process engine [job executor](../user-guide/process-engine/the-job-executor.md) is also clustered and runs on each node. This way, there is no single point of failure as far as the process engine is concerned. The job executor can run in both [homogeneous and heterogeneous clusters](../user-guide/process-engine/the-job-executor.md#cluster-setups). :::note[Time zones] -The are some limitations on [time zone usage in a cluster](../user-guide/process-engine/time-zones.md#cluster-setup). +There are some limitations on [time zone usage in a cluster](../user-guide/process-engine/time-zones.md#cluster-setup). ::: diff --git a/docs/documentation/reference/bpmn20/events/bpmn/event-conditional.bpmn b/docs/documentation/reference/bpmn20/events/bpmn/event-conditional.bpmn index 6e64c468..372522ef 100644 --- a/docs/documentation/reference/bpmn20/events/bpmn/event-conditional.bpmn +++ b/docs/documentation/reference/bpmn20/events/bpmn/event-conditional.bpmn @@ -2,7 +2,7 @@ - + SequenceFlow_1wjobn4 diff --git a/docs/documentation/reference/bpmn20/events/bpmn/event-message-throwing.bpmn b/docs/documentation/reference/bpmn20/events/bpmn/event-message-throwing.bpmn index 33154794..0fb62bf7 100644 --- a/docs/documentation/reference/bpmn20/events/bpmn/event-message-throwing.bpmn +++ b/docs/documentation/reference/bpmn20/events/bpmn/event-message-throwing.bpmn @@ -49,7 +49,7 @@ SequenceFlow_5 - + @@ -170,4 +170,4 @@ - \ No newline at end of file + diff --git a/docs/documentation/reference/bpmn20/events/bpmn/event-message.bpmn b/docs/documentation/reference/bpmn20/events/bpmn/event-message.bpmn index 34bb0a9d..8c06a8bf 100644 --- a/docs/documentation/reference/bpmn20/events/bpmn/event-message.bpmn +++ b/docs/documentation/reference/bpmn20/events/bpmn/event-message.bpmn @@ -21,7 +21,7 @@ SequenceFlow_5 - + SequenceFlow_5 SequenceFlow_6 @@ -113,4 +113,4 @@ - \ No newline at end of file + diff --git a/docs/documentation/reference/bpmn20/events/message-events.md b/docs/documentation/reference/bpmn20/events/message-events.md index 3b3c8a67..895783fc 100644 --- a/docs/documentation/reference/bpmn20/events/message-events.md +++ b/docs/documentation/reference/bpmn20/events/message-events.md @@ -146,7 +146,7 @@ List results = runtimeService .correlateAllWithResult(); ``` -In this case the matching execution will be selected based on variables existing in it's scope (ignoring all parent scopes). +In this case, the matching execution will be selected based on variables existing in its scope (ignoring all parent scopes). In case of successful correlation, the correlated or newly created process instance is updated with the variables from the `processVariables` map. @@ -292,12 +292,12 @@ The following example shows different message events in a process model: ``` -Instead of the message intermediate catching event you might want to think about a Receive Task instead, which can serve similar purposes but is able to be used in combination with boundary events. In combination with the message intermediate catching event you might want to use an Event-based Gateway. +Instead of the message intermediate catching event, you might want to use a Receive Task, which can serve similar purposes and can be used in combination with boundary events. In combination with the message intermediate catching event, you might want to use an Event-based Gateway. ## Message Boundary Event -Boundary events are catching events that are attached to an activity. This means that while the activity is running, the message boundary event is listening for named message. When this is caught, two things might happen, depending on the configuration of the boundary event: +Boundary events are catching events that are attached to an activity. This means that while the activity is running, the message boundary event is listening for a named message. When this is caught, two things might happen, depending on the configuration of the boundary event: * Interrupting boundary event: The activity is interrupted and the sequence flow going out of the event is followed. * Non-interrupting boundary event: One token stays in the activity and an additional token is created which follows the sequence flow going out of the event. diff --git a/docs/documentation/reference/bpmn20/subprocesses/transaction-subprocess.md b/docs/documentation/reference/bpmn20/subprocesses/transaction-subprocess.md index bf919847..f070c6a9 100644 --- a/docs/documentation/reference/bpmn20/subprocesses/transaction-subprocess.md +++ b/docs/documentation/reference/bpmn20/subprocesses/transaction-subprocess.md @@ -42,7 +42,7 @@ It is important not to confuse the BPMN transaction subprocess with technical (A A BPMN transaction differs from a technical transaction in the following ways: -* While an ACID transaction is typically short lived, a BPMN transaction may take hours, days or even months to complete. (Consider a case where one of the activities grouped by a transaction is a usertask; typically, people have longer response times than applications. Or, in another situation, a BPMN transaction might wait for some business event to occur, like the fact that a particular order has been fulfilled.) Such operations usually take considerably longer to complete than updating a record in a database or storing a message using a transactional queue. +* While an ACID transaction is typically short lived, a BPMN transaction may take hours, days or even months to complete. (Consider a case where one of the activities grouped by a transaction is a user task; typically, people have longer response times than applications. Or, in another situation, a BPMN transaction might wait for some business event to occur, like the fact that a particular order has been fulfilled.) Such operations usually take considerably longer to complete than updating a record in a database or storing a message using a transactional queue. * Because it is impossible to scope a technical transaction to the duration of a business activity, a BPMN transaction typically spans multiple ACID transactions. @@ -63,7 +63,7 @@ To sum it up: while ACID transactions offer a generic solution to such problems The BPMN specification requires that the process engine reacts to events issued by the underlying transaction protocol and, in case a transaction is canceled, if a cancel event occurs, in the underlying protocol. As an embeddable engine, the Operaton engine currently does not support this. (For some ramifications of this, see the paragraph on consistency below.) ::: -Consistency on top of ACID transactions and optimistic concurrency: A BPMN transaction guarantees consistency in the sense that either all activities compete successfully, or, if some activity cannot be performed, the effects of all other successful activities are compensated. So either way, we end up in a consistent state. However, it is important to recognize that in Operaton, the consistency model for BPMN transactions is superposed on top of the consistency model for process execution. The Operaton engine executes processes in a transactional way. Concurrency is addressed using optimistic locking. In the engine BPMN error, cancel and compensation events are built on top of the same ACID transactions and optimistic locking. For example, a cancel end event can only trigger compensation if it is actually reached. It is not reached if some undeclared exception is thrown by a service task before. The effects of a compensation handler can not be committed if some other participant in the underlying ACID transaction sets the transaction to the state rollback-only. Also, when two concurrent executions reach a cancel end event, compensation might be triggered twice and fail with an optimistic locking exception. All of this is to say that when implementing BPMN transactions in the core engine, the same set of rules apply as when implementing "ordinary" processes and subprocesses. So, to effectively guarantee consistency, it is important to implement processes in a way that takes the optimistic, transactional execution model into consideration. For further information, see the documentation on [optimistic locking](../../../user-guide/process-engine/transactions-in-processes.md#optimistic-locking). +Consistency on top of ACID transactions and optimistic concurrency: A BPMN transaction guarantees consistency in the sense that either all activities complete successfully, or, if some activity cannot be performed, the effects of all other successful activities are compensated. So either way, we end up in a consistent state. However, it is important to recognize that in Operaton, the consistency model for BPMN transactions is superposed on top of the consistency model for process execution. The Operaton engine executes processes in a transactional way. Concurrency is addressed using optimistic locking. In the engine BPMN error, cancel and compensation events are built on top of the same ACID transactions and optimistic locking. For example, a cancel end event can only trigger compensation if it is actually reached. It is not reached if some undeclared exception is thrown by a service task before. The effects of a compensation handler cannot be committed if some other participant in the underlying ACID transaction sets the transaction to the state rollback-only. Also, when two concurrent executions reach a cancel end event, compensation might be triggered twice and fail with an optimistic locking exception. All of this is to say that when implementing BPMN transactions in the core engine, the same set of rules apply as when implementing "ordinary" processes and subprocesses. So, to effectively guarantee consistency, it is important to implement processes in a way that takes the optimistic, transactional execution model into consideration. For further information, see the documentation on [optimistic locking](../../../user-guide/process-engine/transactions-in-processes.md#optimistic-locking). ## Operaton Extensions diff --git a/docs/documentation/reference/bpmn20/tasks/script-task.md b/docs/documentation/reference/bpmn20/tasks/script-task.md index 25eae336..d061bfef 100644 --- a/docs/documentation/reference/bpmn20/tasks/script-task.md +++ b/docs/documentation/reference/bpmn20/tasks/script-task.md @@ -27,7 +27,7 @@ A Script Task is defined by specifying the script and the scriptFormat. ``` The value of the scriptFormat attribute must be a name that is compatible with JSR-223 (Scripting -for the Java Platform). If you want to use a (JSR-223 compatible) scripting engine, you need to to +for the Java Platform). If you want to use a (JSR-223 compatible) scripting engine, you need to add the corresponding jar to the classpath and use the appropriate name. The script source code has to be added as the text content of the `script` child element. @@ -71,7 +71,7 @@ It's also possible to set process variables in a script. Variables can be set by ### Enabling auto-storing of Script Variables -By setting the property `autoStoreScriptVariables` to `true` in the process engine configuration, the process engine will automatically store all _global_ script variables as process variables. This was the default behavior in Operaton.0 and 7.1 but it only reliably works for the Groovy scripting language (see the [Set autoStoreScriptVariables][autostore-variables] section of the [Migration Guide](../../../update/index.md) for more information). +By setting the property `autoStoreScriptVariables` to `true` in the process engine configuration, the process engine will automatically store all _global_ script variables as process variables. This was the default behavior in Camunda 7.0 and 7.1 but it only reliably works for the Groovy scripting language (see the [Set autoStoreScriptVariables][autostore-variables] section of the [Migration Guide](../../../update/index.md) for more information). To use this feature, you have to diff --git a/docs/documentation/reference/bpmn20/tasks/user-task.md b/docs/documentation/reference/bpmn20/tasks/user-task.md index 6e0f25f4..eb832bfc 100644 --- a/docs/documentation/reference/bpmn20/tasks/user-task.md +++ b/docs/documentation/reference/bpmn20/tasks/user-task.md @@ -166,7 +166,7 @@ This is exactly the same as using a potentialOwner construct as defined above. N ### Assignment based on Data and Service Logic -In the above examples, constant values such as `kermit` or `management` are used. But what if the exact name of an assignee or a candidate group is not known at design time? And what if the assignee is not a constant value but depends on data such as _"The person who started the process"_? Maybe the assigment logic is also more complex and needs to access an external data source such as LDAP to implement a lookup such as _"The manager of the employee who started the process"_. +In the above examples, constant values such as `kermit` or `management` are used. But what if the exact name of an assignee or a candidate group is not known at design time? And what if the assignee is not a constant value but depends on data such as _"The person who started the process"_? Maybe the assignment logic is also more complex and needs to access an external data source such as LDAP to implement a lookup such as _"The manager of the employee who started the process"_. Such things can be implemented using assignment expressions or task listeners. @@ -307,7 +307,7 @@ The error message and variables are optional. They can provide additional inform See the documentation for [Catching Escalation Events](../events/escalation-events.md#catching-escalation-events). -Reporting an escalation during user task execution can be achieved via `TaskService#handleEscalation`. The user task should be active to do so. The `escalationCode` is compulsory to invoke the escalation, this code identifies a predefined escalation. If the given `escalationCode` does not exist an Process Engine Exception will be thrown. See the following example: +Reporting an escalation during user task execution can be achieved via `TaskService#handleEscalation`. The user task should be active to do so. The `escalationCode` is compulsory to invoke the escalation, this code identifies a predefined escalation. If the given `escalationCode` does not exist, a Process Engine Exception will be thrown. See the following example: ```java taskService.handleEscalation( @@ -321,7 +321,7 @@ The variables are optional. They will be passed to the execution if the escalati ## Completion -Complete is part of the [task lifecycle](../../../webapps/tasklist/task-lifecycle.md) operation along with create, set candidate, assign, etc. (allow available via Java API). Complete a task by passing variables, optionally the process variables can be retrieved:: +Completing a task is part of the [task lifecycle](../../../webapps/tasklist/task-lifecycle.md), along with create, set candidate, assign, etc. (also available via Java API). Complete a task by passing variables; optionally, the process variables can be retrieved: ```java taskService.complete(taskId, variables); diff --git a/docs/documentation/reference/cmmn11/concepts/entry-exit-criteria.md b/docs/documentation/reference/cmmn11/concepts/entry-exit-criteria.md index cd88c726..f0a2d5b6 100644 --- a/docs/documentation/reference/cmmn11/concepts/entry-exit-criteria.md +++ b/docs/documentation/reference/cmmn11/concepts/entry-exit-criteria.md @@ -33,7 +33,7 @@ Similar changes in the state of a case instance may be driven by events occurrin - + ``` Similarly, `PlanItem_HumanTask_1` with an exit criterion looks as follows: diff --git a/docs/documentation/reference/cmmn11/concepts/lifecycle.md b/docs/documentation/reference/cmmn11/concepts/lifecycle.md index 91035d42..06693a34 100644 --- a/docs/documentation/reference/cmmn11/concepts/lifecycle.md +++ b/docs/documentation/reference/cmmn11/concepts/lifecycle.md @@ -87,7 +87,7 @@ States: completed - The transition complete automatically triggers when all plan items contained in the case plan model are completed, terminated, or disabled. With automatic completion enabled, only required plan items have to reach theses states. Furthermore, it is possible to manually complete a case instance via the CaseService API if it has no active tasks or stages and all required plan items are either completed, terminated, or disabled. + The transition complete automatically triggers when all plan items contained in the case plan model are completed, terminated, or disabled. With automatic completion enabled, only required plan items have to reach these states. Furthermore, it is possible to manually complete a case instance via the CaseService API if it has no active tasks or stages and all required plan items are either completed, terminated, or disabled. @@ -134,7 +134,7 @@ States: enabled - A task or stage becomes enabled as soon as any of its entry criteria is fulfilled. If this is given when a the task/stage becomes available, it immediately becomes enabled or, depending on its manual activation rule, active. + A task or stage becomes enabled as soon as any of its entry criteria is fulfilled. If this is given when the task/stage becomes available, it immediately becomes enabled or, depending on its manual activation rule, active. @@ -150,7 +150,7 @@ States: active - When a task or stage becomes active, its actual work is performed. For a stage, all contained plan items are instantiated. For a task, its actual work is issued, e.g., for a human task, a task instance is created and needs to be worked on by a user. In order for a task or stage to become active, at least one entry criterion has to be fulfilled. Activation can either be performed manually by a human worker using the CaseService API if the manualActivation rule is specified or automatically if not manualActivation rule is specified. + When a task or stage becomes active, its actual work is performed. For a stage, all contained plan items are instantiated. For a task, its actual work is issued, e.g., for a human task, a task instance is created and needs to be worked on by a user. In order for a task or stage to become active, at least one entry criterion has to be fulfilled. Activation can either be performed manually by a human worker using the CaseService API if the manualActivation rule is specified or automatically if no manualActivation rule is specified. @@ -158,7 +158,7 @@ States: completed - The complete transition triggers for a task when its actual work is done. For a stage, this transition triggers when all contained tasks/stages are either completed, terminated, or disabled. With automatic completion enabled, only required plan items have to reach theses states. A task/stage in state completed is removed from the runtime database. + The complete transition triggers for a task when its actual work is done. For a stage, this transition triggers when all contained tasks/stages are either completed, terminated, or disabled. With automatic completion enabled, only required plan items have to reach these states. A task/stage in state completed is removed from the runtime database. diff --git a/docs/documentation/reference/cmmn11/concepts/plan-items.md b/docs/documentation/reference/cmmn11/concepts/plan-items.md index 836a0180..8cc2430e 100644 --- a/docs/documentation/reference/cmmn11/concepts/plan-items.md +++ b/docs/documentation/reference/cmmn11/concepts/plan-items.md @@ -25,7 +25,7 @@ As an example, consider the following fragment of a case definition: - + ``` This model contains one plan item definition, namely the `humanTask` element. This definition is referenced by two plan items, `PlanItem_HumanTask_1` and `PlanItem_HumanTask_2`. When a new case of this model is created, there will be two human task instances, one for each plan item. The plan item definition is the single point at which the human task is configured. Thus, the assignee specification by the attribute `operaton:assignee="kermit"` is valid for both plan items. diff --git a/docs/documentation/reference/cmmn11/markers/repetition-rule.md b/docs/documentation/reference/cmmn11/markers/repetition-rule.md index a037d6fa..017e59d7 100644 --- a/docs/documentation/reference/cmmn11/markers/repetition-rule.md +++ b/docs/documentation/reference/cmmn11/markers/repetition-rule.md @@ -82,7 +82,7 @@ The corresponding XML representation could look like this: - + ``` This case contains a human task *A*. Task *A* has a repetition rule indicating that the task is repeatable as long as the variable `score` is less than `50`. @@ -122,10 +122,10 @@ The transition in which the repetition rule is evaluated can be changed by an Op - + ``` -This means that the repetition rule is evaluated in the transition `disable`. So, whenever an instance of the defined human task gets disabled, the repetition rule is evaluated and if this rule evaluates to `true`, a new instance is created. As a consequence, the repetition rule is not evaluated when an instance transitions in state `COMPLETED` anymore. +This means that the repetition rule is evaluated in the transition `disable`. So, whenever an instance of the defined human task gets disabled, the repetition rule is evaluated and if this rule evaluates to `true`, a new instance is created. As a consequence, the repetition rule is not evaluated when an instance transitions in state `COMPLETED` anymore. ## Repetition triggered by entry criteria @@ -172,7 +172,7 @@ The corresponding XML representation could look like this: - + ``` This case contains two human tasks *A* and *B* that are connected by a sentry. Task *B* gets `ENABLED` if any conditions are fulfilled and task *A* gets `ENABLED` if an instance of `B` completes. Furthermore both tasks are repeatable as long as the variable `score` is less than `50`. diff --git a/docs/documentation/reference/cmmn11/milestone.md b/docs/documentation/reference/cmmn11/milestone.md index 5235b037..8344a904 100644 --- a/docs/documentation/reference/cmmn11/milestone.md +++ b/docs/documentation/reference/cmmn11/milestone.md @@ -41,10 +41,10 @@ When referenced in a case plan, a milestone gets completed as soon as its entry - + ``` -In this case, the milestone will complete as soon as as the human task completes. +In this case, the milestone will complete as soon as the human task completes. A milestone cannot have exit criteria. diff --git a/docs/documentation/reference/cmmn11/sentry.md b/docs/documentation/reference/cmmn11/sentry.md index 2dcbcd6f..9b6eaa32 100644 --- a/docs/documentation/reference/cmmn11/sentry.md +++ b/docs/documentation/reference/cmmn11/sentry.md @@ -10,7 +10,7 @@ menu: --- -A *sentry* captures the occurrence of a certain event occurring or a condition being fulfilled within a case. Sentries are used as [entry and exit criteria](../cmmn11/concepts/entry-exit-criteria.md). Note that the black and white diamonds represent the criteria. A sentry itself has no graphical representation. +A *sentry* captures the occurrence of a certain event or a condition being fulfilled within a case. Sentries are used as [entry and exit criteria](../cmmn11/concepts/entry-exit-criteria.md). Note that the black and white diamonds represent the criteria. A sentry itself has no graphical representation. @@ -56,11 +56,11 @@ OnParts are defined on lifecycle transitions for plan items or case file items. ``` -A `planItemOnPart` must always reference a plan item by the attribute `sourceRef`. This plan item must be contained by the same stage the sentry is defined in. The child element `standardEvent` can the identifier of any lifecycle transition from that plan item's lifecycle and that is supported by the Operaton engine. Note that different plan item definitions define different lifecycles. For details on valid lifecycle transitions, see the [Lifecycles](../cmmn11/concepts/lifecycle.md) section. +A `planItemOnPart` must always reference a plan item by the attribute `sourceRef`. This plan item must be contained by the same stage the sentry is defined in. The child element `standardEvent` can be the identifier of any lifecycle transition from that plan item's lifecycle and that is supported by the Operaton engine. Note that different plan item definitions define different lifecycles. For details on valid lifecycle transitions, see the [Lifecycles](../cmmn11/concepts/lifecycle.md) section. -As an alternative to `sourceRef`, the CMMN specification allows to define an attribute `sentryRef` responsible for referencing another sentry such that the onPart is fulfilled when the plan item that sentry references performs the *exit* state transition. This attribute is currently not supported by the Operaton engine. +As an alternative to `sourceRef`, the CMMN specification defines an attribute `sentryRef` responsible for referencing another sentry such that the onPart is fulfilled when the plan item that sentry references performs the *exit* state transition. This attribute is currently not supported by the Operaton engine. -Note that it is possible to have any number of OnParts which allows to combine multiple events. All OnParts must be fulfilled for a sentry to occur, i.e., specifying multiple OnParts is a conjunction of multiple events. An OnPart is fulfilled as soon as the element it is defined on performs the specified lifecycle transition. It is irrelevant whether this element performs any other subsequent lifecycle transitions. +Note that it is possible to have any number of OnParts, which lets you combine multiple events. All OnParts must be fulfilled for a sentry to occur, i.e., specifying multiple OnParts is a conjunction of multiple events. An OnPart is fulfilled as soon as the element it is defined on performs the specified lifecycle transition. It is irrelevant whether this element performs any other subsequent lifecycle transitions. ## IfPart @@ -85,7 +85,7 @@ In addition to variable names, the identifier `caseExecution` can be used to acc ``` -The CMMN specification allows to reference a case file item by the sentry attribute `contextRef`. This attribute is not supported by the Operaton engine and therefore ignored. +The CMMN specification lets you reference a case file item by the sentry attribute `contextRef`. This attribute is not supported by the Operaton engine and therefore ignored. The engine evaluates IfParts at every lifecycle transition of a plan item contained in the sentry's stage. That means, if an IfPart is not satisfied immediately when all OnParts have occurred, the sentry may still occur at any later lifecycle transition. @@ -110,19 +110,19 @@ In the above example, sentry is evaluated when the `create` event on the variabl ## VariableOnPart Evaluation -Variable event that occurs in the scope of the execution triggers the sentry with variableOnParts in the following conditions: +A variable event that occurs in the scope of the execution triggers the sentry with variableOnParts under the following conditions: -* `variableName` and `variableEvent` defined in the variableOnPart of the sentry matches the occurred variable event and the associated variable name. -* There exists no variable of the same name in the ancestory path of the sentry between the execution scope of the sentry and the execution scope of the variable event occurrence (the scope of the variable definition) +* `variableName` and `variableEvent` defined in the variableOnPart of the sentry match the variable event that occurred and the associated variable name. +* No variable of the same name exists in the ancestry path of the sentry between the execution scope of the sentry and the execution scope of the variable event occurrence (the scope of the variable definition). Consider the below example in which there are two human tasks. `HumanTask1` is defined inside the case model and the `HumanTask_2` is defined inside the stage. -Each human task is attached with a entry criterion sentry and both the sentries are evaluated when the update event for the variable `foo` occurs. +Each human task is attached to an entry criterion sentry and both sentries are evaluated when the update event for the variable `foo` occurs. ![Example img](/img/documentation/reference/cmmn11/variableOnPart.png) Scenario 1: -When a variable `foo` is set and updated in the scope of the case model, then both the sentries are evaluated and results in the transition of `HumanTask1` and `HumanTask_2` from available state to enabled state. +When a variable `foo` is set and updated in the scope of the case model, then both sentries are evaluated and result in the transition of `HumanTask1` and `HumanTask_2` from available state to enabled state. Scenario 2: @@ -138,4 +138,4 @@ Sentries allow a flexible definition of event occurrences and data-based conditi * A valid sentry must have at least one of the sentry parts (OnPart or IfPart or VariableOnPart). * A sentry without OnParts is fulfilled when the IfPart evaluates to `true` and all the VariableOnParts have occurred. * A sentry without an IfPart is fulfilled when all OnParts and all the VariableOnParts have occurred. -* A sentry without variableOnPart is fullfilled when all the OnParts and IfPart are fulfilled. \ No newline at end of file +* A sentry without a VariableOnPart is fulfilled when all the OnParts and the IfPart are fulfilled. diff --git a/docs/documentation/reference/cmmn11/tasks/case-task.md b/docs/documentation/reference/cmmn11/tasks/case-task.md index 17a6d9c0..9c322b58 100644 --- a/docs/documentation/reference/cmmn11/tasks/case-task.md +++ b/docs/documentation/reference/cmmn11/tasks/case-task.md @@ -80,12 +80,12 @@ Note that the tenant id of the calling case instance is not taken into account i In some situations it may be useful to override this default behavior and specify the tenant id explicitly. -The `operaton:caseTenantId` attribute allows to explicitly specify a tenant id: +The `operaton:caseTenantId` attribute lets you explicitly specify a tenant id: ```xml - + ``` If the tenant id is not known at design time, an expression can be used as well: @@ -106,7 +106,7 @@ An expression also allows using the tenant id of the calling case instance inste ## Exchange Variables -The Operaton custom extensions elements `in` and `out` allow to exchange variables between the case task (in a case instance) and the case instance that it creates: `in` elements of a case task map variables of the calling case to input variables of the launched case instance and `out` mappings of a case task map output variables of the called case instance to variables of the calling case, e.g.,: +The Operaton custom extension elements `in` and `out` let you exchange variables between the case task (in a case instance) and the case instance that it creates: `in` elements of a case task map variables of the calling case to input variables of the launched case instance and `out` mappings of a case task map output variables of the called case instance to variables of the calling case, e.g.,: ```xml @@ -145,7 +145,7 @@ Furthermore, the case task can be configured to pass all variables to the called ``` -Note: The variables keeps their names. +Note: The variables keep their names. It is possible, at runtime, to decide which variables are mapped into the called case instance. This can be declared with the `local` attribute on the `operaton:in` element as follows: diff --git a/docs/documentation/reference/cmmn11/tasks/decision-task.md b/docs/documentation/reference/cmmn11/tasks/decision-task.md index 32254fd5..31af8097 100644 --- a/docs/documentation/reference/cmmn11/tasks/decision-task.md +++ b/docs/documentation/reference/cmmn11/tasks/decision-task.md @@ -85,7 +85,7 @@ Note that the tenant id of the calling case instance is not taken into account i In some situations it may be useful to override this default behavior and specify the tenant id explicitly. -The `operaton:decisionTenantId` attribute allows to explicitly specify a tenant id: +The `operaton:decisionTenantId` attribute lets you explicitly specify a tenant id: ```xml -[DMN 1.3]: ../../dmn/index.md +[DMN 1.3]: ../../dmn/index.md diff --git a/docs/documentation/reference/cmmn11/tasks/human-task.md b/docs/documentation/reference/cmmn11/tasks/human-task.md index 387d835a..28cfa811 100644 --- a/docs/documentation/reference/cmmn11/tasks/human-task.md +++ b/docs/documentation/reference/cmmn11/tasks/human-task.md @@ -66,7 +66,7 @@ task.getDescription(); Each task has a field indicating the due date of that task. The Query API can be used to query for tasks that are due on, before or after a certain date. -There is an extension attribute that allows to specify an expression in a task definition to set the initial due date of a task when it is created. The expression should always resolve to a `java.util.Date`, `java.util.String` ([ISO8601](http://en.wikipedia.org/wiki/ISO_8601) formatted) or `null`. When using ISO8601 formatted Strings, you may either specify an exact point in time or a time period relative to the time the task is created. +There is an extension attribute that lets you specify an expression in a task definition to set the initial due date of a task when it is created. The expression should always resolve to a `java.util.Date`, `java.util.String` ([ISO8601](http://en.wikipedia.org/wiki/ISO_8601) formatted) or `null`. When using ISO8601 formatted Strings, you may either specify an exact point in time or a time period relative to the time the task is created. ```xml diff --git a/docs/documentation/reference/cmmn11/tasks/process-task.md b/docs/documentation/reference/cmmn11/tasks/process-task.md index eed73444..6f7f50b3 100644 --- a/docs/documentation/reference/cmmn11/tasks/process-task.md +++ b/docs/documentation/reference/cmmn11/tasks/process-task.md @@ -79,7 +79,7 @@ Note that the tenant id of the calling case instance is not taken into account i In some situations it may be useful to override this default behavior and specify the tenant id explicitly. -The `operaton:processTenantId` attribute allows to explicitly specify a tenant id: +The `operaton:processTenantId` attribute lets you explicitly specify a tenant id: ```xml @@ -182,7 +182,7 @@ The following example shows how the business key of the calling case instance ca ``` -If the business key of the called process instance should be different than the business key of the calling case instance, it is possible to use an expression that, for example, references a variable: +If the business key of the called process instance should be different from the business key of the calling case instance, it is possible to use an expression that, for example, references a variable: ```xml diff --git a/docs/documentation/reference/connect/extending-connect.md b/docs/documentation/reference/connect/extending-connect.md index 11ac144a..3407b41b 100644 --- a/docs/documentation/reference/connect/extending-connect.md +++ b/docs/documentation/reference/connect/extending-connect.md @@ -15,8 +15,8 @@ menu: The connectors available to Connect may not always suit your needs. Sometimes, it is necessary to provide configuration. -To configure a connector detected by Spin, the SPI -`org.operaton.connect.spi.ConnectorConfigurator` can be implemented. A +To configure a connector detected by Connect, the SPI +`org.operaton.connect.spi.ConnectorConfigurator` can be implemented. A configurator specifies which classes it can configure. Connect discovers a configurator by employing Java's service loader mechanism and will then provide it with all connectors that match the specified class (or are a subclass @@ -27,8 +27,8 @@ that the connector uses. To provide a custom configurator, you have to * Provide a custom implementation of `org.operaton.connect.spi.ConnectorConfigurator` -* Add the configurator's fully qualified classname to a file named `META-INF/services/org.operaton.connect.spi.ConnectorConfigurator` -* Ensure that the artifact containing the configurator is reachable from Connect's classloader +* Add the configurator's fully qualified class name to a file named `META-INF/services/org.operaton.connect.spi.ConnectorConfigurator` +* Ensure that the artifact containing the configurator is reachable from Connect's class loader ## Custom Connector @@ -36,17 +36,17 @@ To provide a custom configurator, you have to A connector is an implementation of the interface `org.operaton.connect.spi.Connector`. An implementation of this interface can be registered by implementing the SPI `org.operaton.connect.spi.ConnectorProvider`. -Connect uses the Java platform's service loader mechanism to lookup provider +Connect uses the Java platform's service loader mechanism to look up provider implementations at runtime. To provide a custom connector, you have to * Provide a custom implementation of `org.operaton.connect.spi.Connector` * Provide a custom implementation of `org.operaton.connect.spi.ConnectorProvider` -* Add the provider's fully qualified classname to a file named `META-INF/services/org.operaton.connect.spi.ConnectorProvider` -* Ensure that the artifact containing the provider is reachable from Connect's classloader +* Add the provider's fully qualified class name to a file named `META-INF/services/org.operaton.connect.spi.ConnectorProvider` +* Ensure that the artifact containing the provider is reachable from Connect's class loader If you now call `org.operaton.connect.Connectors.getAvailableConnectors()`, then the custom connector is returned along with the built-in connectors. Furthermore, `org.operaton.connect.Connectors.getConnector(String connectorId)` -can be used to explicity retrieve the connector by a specific provider. +can be used to explicitly retrieve the connector by ID. diff --git a/docs/documentation/reference/deployment-descriptors/tags/job-executor.md b/docs/documentation/reference/deployment-descriptors/tags/job-executor.md index 48704bb6..73cb098d 100644 --- a/docs/documentation/reference/deployment-descriptors/tags/job-executor.md +++ b/docs/documentation/reference/deployment-descriptors/tags/job-executor.md @@ -80,7 +80,7 @@ The following example shows a job executor XML snippet: <job-acquisition> false - Specifies the fully qualified classname of the job executor. + Specifies the fully qualified class name of the job executor.

Attributes: None. diff --git a/docs/documentation/reference/deployment-descriptors/tags/process-archive.md b/docs/documentation/reference/deployment-descriptors/tags/process-archive.md index 762d44aa..1b357792 100644 --- a/docs/documentation/reference/deployment-descriptors/tags/process-archive.md +++ b/docs/documentation/reference/deployment-descriptors/tags/process-archive.md @@ -204,7 +204,7 @@ The following is a list of all supported configuration properties.

Note:

-

It is not advised to use this setting when process elements are bound against resources of the same deployment. A binding is required when resources like a process definition from a call activity or an external script are referenced (see the BPMN implementation reference). For example, if a call activity uses the binding deployment and a certain process definition key, whether the process can be resolved depends on if it was deployed. Thus, it is recommended to use the binding latest or version when activating this setting.

+

It is not advised to use this setting when process elements are bound against resources of the same deployment. A binding is required when resources like a process definition from a call activity or an external script are referenced (see the BPMN implementation reference). For example, if a call activity uses the binding deployment and a certain process definition key, whether the process can be resolved depends on whether it was deployed. Thus, it is recommended to use the binding latest or version when activating this setting.

@@ -255,12 +255,12 @@ The following is a list of all supported configuration properties. additionalResourceSuffixes comma-separated list - Specifies a list of additional suffixes which are considered as deployment resource if the + Specifies a list of additional suffixes that are considered deployment resources if the isScanForProcessDefinitions property is set to true. It can be used - to deploy additional resources beside process and case definitions, for example to add a + to deploy additional resources besides process and case definitions, for example to add a script to the deployment and reference it as an external source (see the documentation about script source for more information). To specify multiple suffixes, a comma is - used as seperator, i.e., py,groovy,rb. + used as separator, i.e., py,groovy,rb. diff --git a/docs/documentation/reference/deployment-descriptors/tags/process-engine.mdx b/docs/documentation/reference/deployment-descriptors/tags/process-engine.mdx index d03db0f9..bfc012fa 100644 --- a/docs/documentation/reference/deployment-descriptors/tags/process-engine.mdx +++ b/docs/documentation/reference/deployment-descriptors/tags/process-engine.mdx @@ -881,7 +881,7 @@ The following is a list with the most commonly used process engine configuration Read more about it in the User Guide.

- Note: To gain the full feature set of the Webapps, and not suffer any UX degradation due to unavailable data, the queryMaxResultsLimit must be set to 2000. If you use Optimize it is recommended to set the value to 10 000, so the import of the data to Optimize works out of the box.

+ Note: To gain the full feature set of the Webapps, and not suffer any UX degradation due to unavailable data, the queryMaxResultsLimit must be set to 2000.

The default value is 231-1. diff --git a/docs/documentation/reference/dmn/custom-extensions/operaton-attributes.md b/docs/documentation/reference/dmn/custom-extensions/operaton-attributes.md index 982c7fc2..8b3531f6 100644 --- a/docs/documentation/reference/dmn/custom-extensions/operaton-attributes.md +++ b/docs/documentation/reference/dmn/custom-extensions/operaton-attributes.md @@ -12,7 +12,7 @@ menu: aliases: [reference/dmn/custom-extensions/operaton-attributes/] --- -The following attributes are extension attributes for the `camunda` namespace `http://operaton.org/schema/1.0/dmn`. +The following attributes are extension attributes for the `operaton` namespace `http://operaton.org/schema/1.0/dmn`. ## historyTimeToLive diff --git a/docs/documentation/reference/dmn/decision-table/hit-policy.md b/docs/documentation/reference/dmn/decision-table/hit-policy.md index b9898b63..9cce2f6a 100644 --- a/docs/documentation/reference/dmn/decision-table/hit-policy.md +++ b/docs/documentation/reference/dmn/decision-table/hit-policy.md @@ -92,9 +92,9 @@ is violated. See the following example: ![Example img](/img/documentation/reference/dmn/decision-table/hit-policy-any.png)Hit Policy Any" class="no-lightbox -This is a decision table for the leave application. If the applier +This is a decision table for the leave application. If the applicant has no vacation days left or is currently in the probation period, the application will be refused. -Otherwise the application is applied. +Otherwise the application is approved. ### First Hit Policy @@ -176,7 +176,7 @@ the Operaton DMN engine: #### SUM aggregator The SUM aggregator sums up all outputs from the satisfied rules. ![Example img](/img/documentation/reference/dmn/decision-table/hit-policy-collect-sum.png)Hit Policy Collect SUM" class="no-lightbox -The showed decision table can be used to sum up the salary bonus for an employee. For example, the employee has been working in the company for +The shown decision table can be used to sum up the salary bonus for an employee. For example, the employee has been working in the company for 3.5 years. So the first, second and third rule will match and the result of the decision table is 600, since the output is summed up. #### MIN aggregator @@ -192,12 +192,12 @@ The MAX aggregator can be used to return the largest output value of all satisfi ![Example img](/img/documentation/reference/dmn/decision-table/hit-policy-collect-max.png)Hit Policy Collect MAX" class="no-lightbox This decision table represents the decision for the amount of pocket money for a child. -Depending of the age, the amount grows. For example, an input of 9 will satisfy the first and second rules. -The output of the second rule is larger then the output of the first rule, so the output +Depending on the age, the amount grows. For example, an input of 9 will satisfy the first and second rules. +The output of the second rule is larger than the output of the first rule, so the output will be 5. A child at the age of 9 will get 5 as pocket money. #### COUNT aggregator -The COUNT aggregator can be use to return the count of satisfied rules. +The COUNT aggregator can be used to return the count of satisfied rules. ![Example img](/img/documentation/reference/dmn/decision-table/hit-policy-collect-count.png)Hit Policy Collect COUNT" class="no-lightbox diff --git a/docs/documentation/reference/dmn/decision-table/input.md b/docs/documentation/reference/dmn/decision-table/input.md index cfcecbe4..57155460 100644 --- a/docs/documentation/reference/dmn/decision-table/input.md +++ b/docs/documentation/reference/dmn/decision-table/input.md @@ -150,7 +150,7 @@ The name of the variable can be specified by the `operaton:inputVariable` name is `cellInput`. To use the attribute you have to define the Operaton DMN namespace -`xmlns:operaton="http://operaton.org/schema/1.0/dmn` in the XML. +`xmlns:operaton="http://operaton.org/schema/1.0/dmn"` in the XML. ```xml @@ -39,9 +39,9 @@ We thus need to fetch the variable programmatically: ``` -## Creating a new Serialized Java Object +## Creating a New Serialized Java Object -In case the variable does not yet exist (for instance in a Start Form), you have to create the variable and specify the necessary meta data in order for the process engine to correctly handle the variable as Java Object. +In case the variable does not yet exist (for instance in a Start Form), you have to create the variable and specify the necessary metadata in order for the process engine to correctly handle the variable as a Java object. ```html