diff --git a/docs/documentation/reference/deployment-descriptors/tags/process-engine.md b/docs/documentation/reference/deployment-descriptors/tags/process-engine.md index df1df48..257dbc3 100644 --- a/docs/documentation/reference/deployment-descriptors/tags/process-engine.md +++ b/docs/documentation/reference/deployment-descriptors/tags/process-engine.md @@ -95,11 +95,11 @@ The following example shows an XML snippet which can be placed in both [processe
Text Content: - The fully qualified classname of the Process Engine Configuration class to be used for this process engine. The class must be a subclass of ProcessEngineConfigurationImpl. + The fully qualified classname of the Process Engine Configuration class to be used for this process engine. The class must be a subclass of ProcessEngineConfigurationImpl.
Default Value: - StandaloneProcessEngineConfiguration + StandaloneProcessEngineConfiguration
Example:
@@ -215,7 +215,7 @@ The following example shows an XML snippet which can be placed in both [processe
Text Content: - The fully qualified classname of a process engine plugin. Must be an implementation of ProcessEnginePlugin + The fully qualified classname of a process engine plugin. Must be an implementation of ProcessEnginePlugin
@@ -504,7 +504,7 @@ The following is a list with the most commonly used process engine configuration used as the Metrics Reporter identifier.hostnameProvider
to an instance of that class.
disableBuiltinExceptionCodeProvider
Default value is false
.
customExceptionCodeProvider
ExceptionCodeProvider
ExceptionCodeProvider
diff --git a/docs/documentation/user-guide/cdi-java-ee-integration/the-cdi-event-bridge.md b/docs/documentation/user-guide/cdi-java-ee-integration/the-cdi-event-bridge.md
index f6274d3..98c28ae 100644
--- a/docs/documentation/user-guide/cdi-java-ee-integration/the-cdi-event-bridge.md
+++ b/docs/documentation/user-guide/cdi-java-ee-integration/the-cdi-event-bridge.md
@@ -131,7 +131,7 @@ If the listener is invoked after the transaction has completed, the `DelegateTas
# The CDI Event Bridge in a process application
To use the CDI Event Bridge in combination with a multi application deployment and the shared process engine, the
-CdiEventListener needs to be added as a
+CdiEventListener needs to be added as a
[Process Application Execution Event Listener](../../user-guide/process-applications/process-application-event-listeners.md).
Example configuration for [Servlet Process Application](../../user-guide/process-applications/the-process-application-class.md#the-servletprocessapplication):
diff --git a/docs/documentation/user-guide/dmn-engine/data-types.md b/docs/documentation/user-guide/dmn-engine/data-types.md
index 0db5219..219c9b8 100644
--- a/docs/documentation/user-guide/dmn-engine/data-types.md
+++ b/docs/documentation/user-guide/dmn-engine/data-types.md
@@ -142,7 +142,7 @@ types. For example, you can add a new type for time or change the
transformation to support a different date format or localized boolean
constants.
-To do this, implement a new [DmnDataTypeTransformer](org/operaton/bpm/dmn/engine/impl/spi/type/DmnDataTypeTransformer.html). The transformation is processed in the `transform()` method and returns a typed value. If it cannot successfully transform a value, it must throw an `IllegalArgumentException`.
+To do this, implement a new [DmnDataTypeTransformer](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/impl/spi/type/DmnDataTypeTransformer.html). The transformation is processed in the `transform()` method and returns a typed value. If it cannot successfully transform a value, it must throw an `IllegalArgumentException`.
```java
public class CustomDataTypeTransformer implements DmnDataTypeTransformer {
diff --git a/docs/documentation/user-guide/dmn-engine/embed.md b/docs/documentation/user-guide/dmn-engine/embed.md
index a8bf948..65bc32a 100644
--- a/docs/documentation/user-guide/dmn-engine/embed.md
+++ b/docs/documentation/user-guide/dmn-engine/embed.md
@@ -50,7 +50,7 @@ This section gives more insights of embedded DMN engine configuration. In case y
## Decision Table Evaluation Listeners
-The DMN engine configuration allows you add a custom decision table [evaluation listener](org/operaton/bpm/dmn/engine/delegate/DmnDecisionTableEvaluationListener.html).
+The DMN engine configuration allows you add a custom decision table [evaluation listener](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/delegate/DmnDecisionTableEvaluationListener.html).
A decision table evaluation listener is notified after a decision table has been evaluated. It receives an evaluation event which contains the result of the evaluation. You can decide if the listener should be notified before or after the default listeners.
```java
@@ -71,7 +71,7 @@ configuration.getCustomPostDecisionTableEvaluationListeners()
```
A specialized evaluation listener is the
-[metric collector](org/operaton/bpm/dmn/engine/spi/DmnEngineMetricCollector.html)
+[metric collector](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/spi/DmnEngineMetricCollector.html)
, which records the number of executed decision elements. This metric can be used to monitor the workload of a decision engine.
```java
@@ -87,7 +87,7 @@ configuration.setEngineMetricCollector(metricCollector);
```
## Decision Evaluation Listeners
-The DMN engine configuration allows you add a custom [decision evaluation listener](org/operaton/bpm/dmn/engine/delegate/DmnDecisionEvaluationListener.html). A decision evaluation listener is
+The DMN engine configuration allows you add a custom [decision evaluation listener](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/delegate/DmnDecisionEvaluationListener.html). A decision evaluation listener is
notified after a decision with all the required decisions has been evaluated. It receives an evaluation event
which contains the result of the evaluation. You can decide if the
listener should be notified before or after the default listeners.
@@ -117,16 +117,16 @@ Please be aware that these APIs are **not** part of the [public API](../../intro
:::
-The [default DMN engine configuration](org/operaton/bpm/dmn/engine/impl/DefaultDmnEngineConfiguration.html)
+The [default DMN engine configuration](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/impl/DefaultDmnEngineConfiguration.html)
has further customization and extension points.
## Customize DMN Transformation
-It is possible to customize the transformation of DMN by providing a [DMN transformer](org/operaton/bpm/dmn/engine/impl/spi/transform/DmnTransformer.html) or configuring the [default one](org/operaton/bpm/dmn/engine/impl/transform/DefaultDmnTransformer.html).
+It is possible to customize the transformation of DMN by providing a [DMN transformer](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/impl/spi/transform/DmnTransformer.html) or configuring the [default one](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/impl/transform/DefaultDmnTransformer.html).
### Register DMN Transform Listeners
-The simplest customization is to provide a [transform listener](org/operaton/bpm/dmn/engine/impl/spi/transform/DmnTransformListener.html). The Listener is notified after a DMN element is
+The simplest customization is to provide a [transform listener](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/impl/spi/transform/DmnTransformListener.html). The Listener is notified after a DMN element is
transformed. The listener can modify the transformed object.
```java
@@ -146,11 +146,11 @@ configuration.getTransformer()
### Register DMN Element Transform Handler
While the transform listener allows modifying of the transformed objects, it does not support instantiating custom subclasses.
-This can be achieved using a custom [transform handler](org/operaton/bpm/dmn/engine/impl/spi/transform/DmnElementTransformHandler.html).
+This can be achieved using a custom [transform handler](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/dmn/engine/impl/spi/transform/DmnElementTransformHandler.html).
A transform handler is registered for a given [DMN model API] type like a `DecisionTable`.
-First, implement a transform handler which can transform a [decision table](org/operaton/bpm/model/dmn/instance/DecisionTable.html).
+First, implement a transform handler which can transform a [decision table](https://operaton.github.io/operaton/javadoc/operaton/1.0/org/operaton/bpm/model/dmn/instance/DecisionTable.html).
```java
public class MyDecisionTableHandler extends DmnElementTransformHandler
- execution
+ DelegateExecution
DelegateExecution
Available in a BPMN execution context like a service task, execution listener or sequence
flow.
@@ -272,17 +272,17 @@ evaluating expressions:
- task
+ DelegateTask
DelegateTask
Available in a task context like a task listener.
- externalTask
+ ExternalTask
ExternalTask
Available during an external task context activity (e.g. in operaton:errorEventDefinition expressions).
- caseExecution
+ DelegateCaseExecution
DelegateCaseExecution
Available in a CMMN execution context.
diff --git a/docs/documentation/user-guide/process-engine/external-tasks.md b/docs/documentation/user-guide/process-engine/external-tasks.md
index 29b3ec2..ad2573b 100644
--- a/docs/documentation/user-guide/process-engine/external-tasks.md
+++ b/docs/documentation/user-guide/process-engine/external-tasks.md
@@ -65,7 +65,7 @@ In addition, other *service-task-like* elements such as send tasks, business rul
### Error Event Definitions
-External tasks allow for the definition of error events that throw a specified BPMN error. This can be done by adding a [operaton:errorEventDefinition](../../reference/bpmn20/custom-extensions/extension-elements.md#erroreventdefinition) extension element to the task's definition. Compared to the `bpmn:errorEventDefinition`, the `operaton:errorEventDefinition` elements accept an additional `expression` attribute which supports any JUEL expression. Within the expression, you have access to the ExternalTaskEntity object via the key `externalTask` which provides getter methods
+External tasks allow for the definition of error events that throw a specified BPMN error. This can be done by adding a [operaton:errorEventDefinition](../../reference/bpmn20/custom-extensions/extension-elements.md#erroreventdefinition) extension element to the task's definition. Compared to the `bpmn:errorEventDefinition`, the `operaton:errorEventDefinition` elements accept an additional `expression` attribute which supports any JUEL expression. Within the expression, you have access to the ExternalTaskEntity object via the key `externalTask` which provides getter methods
for `errorMessage`, `errorDetails`, `workerId`, `retries` and more.
The expression is evaluated on invocations of `ExternalTaskService#complete` and
diff --git a/docs/documentation/user-guide/process-engine/history/custom-implementation.md b/docs/documentation/user-guide/process-engine/history/custom-implementation.md
index 8f95bb6..0fff927 100644
--- a/docs/documentation/user-guide/process-engine/history/custom-implementation.md
+++ b/docs/documentation/user-guide/process-engine/history/custom-implementation.md
@@ -24,7 +24,7 @@ Once the event has reached the History Event Handler, it can be processed and st
Exchanging the History Event Handler with a custom implementation allows users to plug in a custom History Backend. To do so, two main steps are required:
-* Provide a custom implementation of the HistoryEventHandler interface.
+* Provide a custom implementation of the HistoryEventHandler interface.
* Wire the custom implementation in the process engine configuration.
:::note[Composite History Handling]
diff --git a/docs/documentation/user-guide/process-engine/history/history-configuration.md b/docs/documentation/user-guide/process-engine/history/history-configuration.md
index 9a6ae6f..90c9a92 100644
--- a/docs/documentation/user-guide/process-engine/history/history-configuration.md
+++ b/docs/documentation/user-guide/process-engine/history/history-configuration.md
@@ -36,7 +36,7 @@ The history level controls the amount of data the process engine provides via th
* Historic External Task Log CREATED, DELETED, FAILED, SUCCESSFUL: fired as an external task has been created, deleted or an external task execution has been reported to fail or succeed.
* `AUTO`: The level `auto` is useful if you are planning to run multiple engines on the same database. In that case, all engines have to use the same history level. Instead of manually keeping your configurations in sync, use the level `auto` and the engine determines the level already configured in the database automatically. If none is found, the default value `audit` is used. Keep in mind: If you are planning to use custom history levels, you have to register the custom levels for every configuration, otherwise an exception is thrown.
-If you need to customize the amount of history events logged, you can provide a custom implementation HistoryEventProducer and wire it in the process engine configuration.
+If you need to customize the amount of history events logged, you can provide a custom implementation HistoryEventProducer and wire it in the process engine configuration.
In case of specific needs, you can also create a [custom history level](../history/custom-implementation.md#implement-a-custom-history-level).
diff --git a/docs/documentation/user-guide/process-engine/history/user-operation-log.md b/docs/documentation/user-guide/process-engine/history/user-operation-log.md
index e231b34..fddb812 100644
--- a/docs/documentation/user-guide/process-engine/history/user-operation-log.md
+++ b/docs/documentation/user-guide/process-engine/history/user-operation-log.md
@@ -29,9 +29,9 @@ The log consists of *operations* and *entries*. An operation corresponds to one
A user operation log entry has the following properties:
* **Operation ID**: A generated id that uniquely identifies a performed operation. Multiple log entries that are part of one operation reference the same operation ID.
-* **Operation Type**: The name of the performed operation. Available operation types are listed in the interface org.operaton.bpm.engine.history.UserOperationLogEntry. Note that one operation can consist of multiple types, for example a cascading API operation is one user operation, but is split into multiple types of operations.
-* **Entity Type**: An identifier of the type of the entity that was addressed by the operation. Available entity types are listed in the class org.operaton.bpm.engine.EntityTypes. Like the operation type, one operation may address more than one type of entity.
-* **Category**: The name of the category the operation is associated with. Available categories are listed in the interface org.operaton.bpm.engine.history.UserOperationLogEntry. For example, all task related runtime operations like claiming and completing tasks fall into the category .
+* **Operation Type**: The name of the performed operation. Available operation types are listed in the interface org.operaton.bpm.engine.history.UserOperationLogEntry. Note that one operation can consist of multiple types, for example a cascading API operation is one user operation, but is split into multiple types of operations.
+* **Entity Type**: An identifier of the type of the entity that was addressed by the operation. Available entity types are listed in the class org.operaton.bpm.engine.EntityTypes. Like the operation type, one operation may address more than one type of entity.
+* **Category**: The name of the category the operation is associated with. Available categories are listed in the interface org.operaton.bpm.engine.history.UserOperationLogEntry. For example, all task related runtime operations like claiming and completing tasks fall into the category .
* **Annotation**: An arbitrary text annotation set by a user for auditing reasons. Multiple log entries that belong to an operation have the same annotation.
* **Entity IDs**: A job log entry contains the entity IDs that serve to identify the entities addressed by the operation. For example, an operation log entry on a task contains the id of the task as well as the id of the process instance the task belongs to. As a second example, a log entry for suspending all process instances of a process definition does not contain individual process instance IDs but only the process definition ID.
* **User ID**: The ID of the user who performed the operation.
diff --git a/docs/documentation/user-guide/process-engine/identity-service.md b/docs/documentation/user-guide/process-engine/identity-service.md
index 446649a..07dc280 100644
--- a/docs/documentation/user-guide/process-engine/identity-service.md
+++ b/docs/documentation/user-guide/process-engine/identity-service.md
@@ -32,8 +32,8 @@ Operaton distinguishes between read-only and writable user repositories. A read-
To provide a custom identity provider implementation, the following interfaces can be implemented:
-* org.operaton.bpm.engine.impl.identity.ReadOnlyIdentityProvider
-* org.operaton.bpm.engine.impl.identity.WritableIdentityProvider
+* org.operaton.bpm.engine.impl.identity.ReadOnlyIdentityProvider
+* org.operaton.bpm.engine.impl.identity.WritableIdentityProvider
# Custom Whitelist for User, Group and Tenant IDs
diff --git a/docs/documentation/user-guide/process-engine/incidents.md b/docs/documentation/user-guide/process-engine/incidents.md
index d478fc0..7228693 100644
--- a/docs/documentation/user-guide/process-engine/incidents.md
+++ b/docs/documentation/user-guide/process-engine/incidents.md
@@ -120,4 +120,4 @@ All additional incident handlers will be added as sub handlers to the `Composite
By default, the main handler is `DefaultIncidentHandler`. To override the main handler, create a `CompositeIncidentHandler` with your own main `IncidentHandler` and initialize the incident handlers in the engine configuration before setting up the engine.
See javadoc for more details
-Composite Incident Handler.
\ No newline at end of file
+Composite Incident Handler.
\ No newline at end of file
diff --git a/docs/documentation/user-guide/process-engine/metrics.md b/docs/documentation/user-guide/process-engine/metrics.md
index a5f9f7b..3a1becb 100644
--- a/docs/documentation/user-guide/process-engine/metrics.md
+++ b/docs/documentation/user-guide/process-engine/metrics.md
@@ -14,7 +14,7 @@ The process engine reports runtime metrics to the database that can help draw co
# Built-in Metrics
-The following table describes the built-in metrics. The identifiers of all built-in metrics are available as constants of the class org.operaton.bpm.engine.management.Metrics.
+The following table describes the built-in metrics. The identifiers of all built-in metrics are available as constants of the class org.operaton.bpm.engine.management.Metrics.
@@ -119,7 +119,7 @@ The following table describes the built-in metrics. The identifiers of all built
# Querying
-Metrics can be queried by making a MetricsQuery offered by the `ManagementService`. For example, the following query retrieves the number of all executed activity instances throughout the entire history of reporting:
+Metrics can be queried by making a MetricsQuery offered by the `ManagementService`. For example, the following query retrieves the number of all executed activity instances throughout the entire history of reporting:
```java
long numCompletedActivityInstances = managementService
@@ -172,12 +172,12 @@ Metrics are reported with an identifier of the reporting party. This identifier
reports to individual engine instances when making a metrics query. For example in a cluster, load
metrics can be related to individual cluster nodes. By default the process engine generates a
reporter id as `
diff --git a/docs/documentation/user-guide/quarkus-integration/deployments.md b/docs/documentation/user-guide/quarkus-integration/deployments.md
index c493483..dcf0c4d 100644
--- a/docs/documentation/user-guide/quarkus-integration/deployments.md
+++ b/docs/documentation/user-guide/quarkus-integration/deployments.md
@@ -13,7 +13,7 @@ menu:
This section documents how to perform process engine deployments with a Quarkus application containing an embedded
process engine. The documentation assumes some familiarity with [Quarkus CDI support][quarkus-cdi] and the Operaton
-DeploymentBuilder API.
+DeploymentBuilder API.
The Operaton Engine Quarkus Extension only supports programmatic deployments. A user can observe for the
`OperatonEngineStartupEvent` CDI event. The `OperatonEngineStartupEvent` signals that a process engine has been
diff --git a/docs/documentation/user-guide/runtime-container-integration/bpm-platform-services.md b/docs/documentation/user-guide/runtime-container-integration/bpm-platform-services.md
index 17b4361..829c347 100644
--- a/docs/documentation/user-guide/runtime-container-integration/bpm-platform-services.md
+++ b/docs/documentation/user-guide/runtime-container-integration/bpm-platform-services.md
@@ -15,12 +15,12 @@ To inspect the current state of configured process engines and deployed process
# ProcessEngineService
-The ProcessEngineService can be accessed by calling `BpmPlatform.getProcessEngineService()`. It offers access to the default process engine, as well as any process engine by its name as specified in the process engine configuration. It returns `ProcessEngine` objects from which any services for a specific engine can be accessed.
+The ProcessEngineService can be accessed by calling `BpmPlatform.getProcessEngineService()`. It offers access to the default process engine, as well as any process engine by its name as specified in the process engine configuration. It returns `ProcessEngine` objects from which any services for a specific engine can be accessed.
# ProcessApplicationService
-The ProcessApplicationService is accessible via `BpmPlatform.getProcessApplicationService()`. It provides details on the process application deployments made on the application server it is running on. That means that it does not provide a global view across all nodes in a cluster.
+The ProcessApplicationService is accessible via `BpmPlatform.getProcessApplicationService()`. It provides details on the process application deployments made on the application server it is running on. That means that it does not provide a global view across all nodes in a cluster.
Given a process application name, a `ProcessApplicationInfo` object can be retrieved that contains details on the deployments made by this process application. These correspond to the process archives declared in [processes.xml](../process-applications/the-processes-xml-deployment-descriptor.md).
diff --git a/docs/documentation/user-guide/spring-boot-integration/spring-security.md b/docs/documentation/user-guide/spring-boot-integration/spring-security.md
index c330441..76587e6 100644
--- a/docs/documentation/user-guide/spring-boot-integration/spring-security.md
+++ b/docs/documentation/user-guide/spring-boot-integration/spring-security.md
@@ -47,14 +47,14 @@ registration in the application properties (`spring.security.oauth2.client.regis
Configuration activates if there is OAuth2 client registration configured. This class configures the Spring
Security filter chain to secure the Operaton Webapps.
-Spring auto configuration class: OperatonSpringSecurityOAuth2AutoConfiguration
+Spring auto configuration class: OperatonSpringSecurityOAuth2AutoConfiguration
## Spring Security Disabled Auto Configuration
Configuration activates if there is **no** OAuth2 client registration configured. This class configures the Spring
Security filter chain to a permit all mode.
-Spring auto configuration class: OperatonBpmSpringSecurityDisableAutoConfiguration
+Spring auto configuration class: OperatonBpmSpringSecurityDisableAutoConfiguration
# OAuth2 Client Registration
@@ -103,7 +103,7 @@ to grant administrator authorizations for a particular OAuth2 user or group.
# OAuth2 Identity Provider
Additionally to the OAuth2 login, Operaton also provides support to use groups from OAuth2.
-This is achieved with a custom [identity service](../process-engine/identity-service.md), called OAuth2IdentityProvider.
+This is achieved with a custom [identity service](../process-engine/identity-service.md), called OAuth2IdentityProvider.
This is a read-only identity provider that configures user's groups from the [Spring Security's granted authorities][Authorities].
This identity provider also supports the default Operaton Database Identity Service as a fallback for authentications for the REST API.
diff --git a/docs/documentation/user-guide/spring-framework-integration/configuration.md b/docs/documentation/user-guide/spring-framework-integration/configuration.md
index d1cd1d4..32eafdd 100644
--- a/docs/documentation/user-guide/spring-framework-integration/configuration.md
+++ b/docs/documentation/user-guide/spring-framework-integration/configuration.md
@@ -32,7 +32,7 @@ The ProcessEngine can be configured as a regular Spring bean. The starting point
```
-Note that the processEngineConfiguration bean uses the SpringProcessEngineConfiguration class.
+Note that the processEngineConfiguration bean uses the SpringProcessEngineConfiguration class.
# Configure a Container-Managed Process Engine as a Spring Bean
diff --git a/docs/documentation/user-guide/spring-framework-integration/testing.md b/docs/documentation/user-guide/spring-framework-integration/testing.md
index d6efc6c..dd3c67c 100644
--- a/docs/documentation/user-guide/spring-framework-integration/testing.md
+++ b/docs/documentation/user-guide/spring-framework-integration/testing.md
@@ -43,7 +43,7 @@ public class MyBusinessProcessTest {
}
```
-Note that for this to work, you need to define a ProcessEngineRule bean in the Spring configuration (which is injected by auto-wiring in the example above).
+Note that for this to work, you need to define a ProcessEngineRule bean in the Spring configuration (which is injected by auto-wiring in the example above).
```xml
idGenerator
- An instance of StrongUuidGeneratoris used.
+ An instance of StrongUuidGeneratoris used.
StrongUuidGenerator