diff --git a/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md b/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md index b3f31bb5f6..f263474207 100644 --- a/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md +++ b/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md @@ -63,6 +63,37 @@ Camunda 8 supports the following binding types: + + versionTag + +

Resolves to the specific version of the target resource that is annotated with the given version tag.

+ +

Caution:

+ + + diff --git a/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md b/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md index 9228ae7028..3fbf3e0bdc 100644 --- a/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md +++ b/docs/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md @@ -46,13 +46,12 @@ The `bindingType` attribute determines which version of the called decision is e - `latest`: the latest deployed version at the moment the business rule task is activated. - `deployment`: the version that was deployed together with the currently running version of the process. +- `versionTag`: the latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. To learn more about choosing binding types, see [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). :::note - If the `bindingType` attribute is not specified, `latest` is used as the default. - ::: A business rule task must define the process variable name of the decision result as @@ -105,7 +104,17 @@ to transform the variables passed to the job worker, or to customize how the var ### XML representation -A business rule task with a called decision that uses `deployment` binding: +A business rule task with a called decision that does not specify the binding type (`latest` is used implicitly): + +```xml + + + + + +``` + +A business rule task with a called decision that uses the `deployment` binding type: ```xml @@ -116,6 +125,18 @@ A business rule task with a called decision that uses `deployment` binding: ``` +A business rule task with a called decision that uses the `versionTag` binding type: + +```xml + + + + + +``` + A business rule task with a job worker implementation and a custom header: ```xml diff --git a/docs/components/modeler/bpmn/call-activities/call-activities.md b/docs/components/modeler/bpmn/call-activities/call-activities.md index 7304637fde..e316fdcce1 100644 --- a/docs/components/modeler/bpmn/call-activities/call-activities.md +++ b/docs/components/modeler/bpmn/call-activities/call-activities.md @@ -22,13 +22,12 @@ The `bindingType` attribute determines which version of the called process is in - `latest`: the latest deployed version at the moment the call activity is activated. - `deployment`: the version that was deployed together with the currently running version of the calling process. +- `versionTag`: the latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. To learn more about choosing binding types, see [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). :::note - If the `bindingType` attribute is not specified, `latest` is used as the default. - ::: ## Boundary events @@ -61,13 +60,33 @@ By disabling this attribute, variables existing at higher scopes are no longer c ### XML representation -A call activity with static process id, propagation of all child variables turned on, and `deployment` binding: +A call activity with static process id, propagation of all child variables turned on, and no explicit binding type (`latest` is used implicitly): + +```xml + + + + + +``` + +A call activity with the `deployment` binding type: + +```xml + + + + + +``` + +A call activity with the `versionTag` binding type: ```xml - + ``` diff --git a/docs/components/modeler/bpmn/user-tasks/user-tasks.md b/docs/components/modeler/bpmn/user-tasks/user-tasks.md index 9c82c79003..10013ce4d3 100644 --- a/docs/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/docs/components/modeler/bpmn/user-tasks/user-tasks.md @@ -117,19 +117,18 @@ Depending on your use case, two different types of form references can be used: 1. **Camunda Forms** provide a flexible way of linking a user task to a Camunda Form via the form ID. Forms linked this way can be deployed together with the referencing process models. To link a user task to a Camunda Form, you have to specify the ID of the Camunda Form as the `formId` attribute - of the task's `zeebe:formDefinition` extension element (see the [XML representation](#camunda-form-linked)). + of the task's `zeebe:formDefinition` extension element (see the [XML representation](#camunda-form)). The `bindingType` attribute determines which version of the linked form is used: - `latest`: the latest deployed version at the moment the user task is activated. - `deployment`: the version that was deployed together with the currently running version of the process. + - `versionTag`: the latest deployed version that is annotated with the version tag specified in the `versionTag` attribute. To learn more about choosing binding types, see [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). :::note - If the `bindingType` attribute is not specified, `latest` is used as the default. - ::: You can read more about Camunda Forms in the [Camunda Forms guide](/guides/utilizing-forms.md) or the [Camunda Forms reference](/components/modeler/forms/camunda-forms-reference.md) @@ -200,14 +199,39 @@ Zeebe user task-specific features are not available to those user tasks. #### Camunda Form -A user task with a linked Camunda Form (that uses `deployment` binding), an assignment definition, and a task schedule: +A user task with a linked Camunda Form that does not specify the binding type (`latest` is used implicitly) as well as an assignment definition and a task schedule: + +```xml + + + + + + + + +``` + +A user task with a linked Camunda Form that uses the `deployment` binding type: ```xml - - + + + +``` + +A user task with a linked Camunda Form that uses the `versionTag` binding type: + +```xml + + + diff --git a/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md b/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md index a204f0b681..eb4b848769 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/business-rule-task-linking.md @@ -4,11 +4,13 @@ title: Business rule task linking description: Use one of the following approaches to link the DMN decision to be called by a business rule task. --- -You can use one of the following approaches to link the DMN decision to be called by a [business rule task](/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md). +import PropertiesPanelImg from './img/brt_properties-panel.png' + +You can use either of the following approaches to link the DMN decision to be called by a [business rule task](/components/modeler/bpmn/business-rule-tasks/business-rule-tasks.md). ## Using the link button -1. Select a business rule task from the canvas and a link icon will appear at the bottom right. +1. Select a business rule task from the canvas. A link icon appears at the bottom right. 2. Click the link icon and choose any decision from the same project. 3. Click **Link** to complete the linking process. In the properties panel, the value **DMN decision** is chosen for the **Implementation** property, and the Decision ID of the decision you chose to link is automatically copied to the **Called decision** section. @@ -22,9 +24,12 @@ For business rule tasks that are already linked, clicking on the link icon opens ## Using the properties panel -You may also enter the Decision ID directly in the **Called decision** section in the properties panel after selecting **DMN decision** for the **Implementation**. +You can also enter the Decision ID directly in the **Called decision** section in the properties panel after selecting **DMN decision** for the **Implementation**. + +- **Binding**: You can also select a different Binding for the called decision. See [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). +- **Version tag**: If you select **version tag** for the Binding, you must enter the actual version tag to use. -![overlay](img/brt_properties-panel.png) +

called decision section in properties panel

:::info Deploying a diagram does not automatically deploy linked diagrams. Ensure you deploy linked diagrams separately. diff --git a/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md b/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md index 1b2fd0b758..1055533019 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/call-activity-linking.md @@ -4,11 +4,13 @@ title: Call activity linking description: Use one of the following approaches to link the process to be called by a call activity. --- +import PropertiesPanelImg from './img/properties-panel.png' + You can use one of the following approaches to link the process to be called by a [call activity](/components/modeler/bpmn/call-activities/call-activities.md). ## Using the link button -1. Select a call activity task from the canvas and a link button will appear at the bottom right. +1. Select a call activity task from the canvas. A link button appears at the bottom right. 2. Click on the button and choose any diagram from the same project. 3. Click the **Link** button to complete the linking process. The process ID of the diagram you chose to link is automatically copied to the **Called element** section in the properties panel. @@ -20,9 +22,12 @@ For call activities that are already linked, clicking on the link button opens a ## Using the properties panel -You may also enter the process ID directly in the **Called element** section in the properties panel. +You can also enter the process ID directly in the **Called element** section in the properties panel. + +- **Binding**: You can also select a different Binding for the called decision. See [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). +- **Version tag**: If you select **version tag** for the Binding, you must enter the actual version tag to use. -![overlay](img/properties-panel.png) +

called element section in properties panel

:::info Deploying a diagram does not automatically deploy linked diagrams. Ensure you deploy linked diagrams separately. diff --git a/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md b/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md index 2ee3f09cf6..3fea0b463b 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md @@ -6,6 +6,7 @@ description: Use one of the following approaches to link a form to a user task o import FormLinkOverlayImg from './img/utl_overlay.png'; import FormLinkOverlayLinkedImg from './img/utl_linked.png'; +import PropertiesPanelImg from './img/utl_properties-panel.png'; import IssueLinkedFormSolution01 from './img/linked_issue01.png'; import IssueLinkedFormSolution02 from './img/linked_issue02.png'; import IssueLinkedFormSolution03 from './img/linked_issue03.png'; @@ -24,12 +25,12 @@ By linking a Camunda Form to a start event, process instances can be started wit 3. Click the **Link** button to complete the linking process. In the properties panel, the value **Camunda Form (linked)** is chosen for the **Type** property, and the form ID of the form you chose to link is automatically copied to the **Form ID** section. -Linking a Camunda Form +

Linking a Camunda Form

For user tasks/start events that are already linked, clicking on the link button opens a dialog which shows a preview of the form the user task is linked to. It is possible to navigate to the linked form by clicking on it, or you can use the **Unlink** button to remove the link. -Linked Camunda Form preview +

Linked Camunda Form preview

## Using the properties panel @@ -37,14 +38,19 @@ Using the properties panel, you can connect a form to a user task/start event vi ### Camunda Form (linked) -Choosing **Camunda Form (linked)** as type and entering form ID directly yields the same result as [using the link button on the modeling canvas](#using-the-link-button). +Choosing **Camunda Form (linked)** as the type and entering the form ID directly, produces the same result as [using the link button on the modeling canvas](#using-the-link-button). -Using this type of linking is the recommended approach as it allows you to benefit from the form automatically being deployed along with the diagram. +- **Binding**: You can also select a different Binding for the linked form. See [Choosing the resource binding type](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md). +- **Version tag**: If you select **version tag** for the Binding, you must enter the actual version tag to use. + +

form section in properties panel

+ +Using a linked form is the recommended approach as it allows you to benefit from the form automatically being deployed with the diagram. This means when deploying a BPMN diagram, Web Modeler will always deploy the latest version of all linked forms along with the diagram, so you do not have to manually re-link forms or [copy & paste JSON configuration](#camunda-form-embedded) when making changes. :::danger When deploying a diagram, Web Modeler will always deploy the latest version of all linked forms along with the diagram. -This means that if you reference the same Form ID within multiple BPMN diagrams, all diagrams will always use the latest version of the form regardless of which version was used when the diagram was initially deployed. +This means that if you reference the same Form ID within multiple BPMN diagrams, all diagrams will always use the latest version of the form regardless of which version was used when the diagram was initially deployed (unless you change the [binding type for a linked form](#camunda-form-linked)). ::: :::info diff --git a/docs/components/modeler/web-modeler/advanced-modeling/img/brt_properties-panel.png b/docs/components/modeler/web-modeler/advanced-modeling/img/brt_properties-panel.png index 6e9bd586a8..88b14b9394 100644 Binary files a/docs/components/modeler/web-modeler/advanced-modeling/img/brt_properties-panel.png and b/docs/components/modeler/web-modeler/advanced-modeling/img/brt_properties-panel.png differ diff --git a/docs/components/modeler/web-modeler/advanced-modeling/img/properties-panel.png b/docs/components/modeler/web-modeler/advanced-modeling/img/properties-panel.png index f3e9080a7f..d6e95a2bcc 100644 Binary files a/docs/components/modeler/web-modeler/advanced-modeling/img/properties-panel.png and b/docs/components/modeler/web-modeler/advanced-modeling/img/properties-panel.png differ diff --git a/docs/components/modeler/web-modeler/advanced-modeling/img/utl_properties-panel.png b/docs/components/modeler/web-modeler/advanced-modeling/img/utl_properties-panel.png new file mode 100644 index 0000000000..48a42b6fd4 Binary files /dev/null and b/docs/components/modeler/web-modeler/advanced-modeling/img/utl_properties-panel.png differ diff --git a/docs/components/modeler/web-modeler/run-or-publish-your-process.md b/docs/components/modeler/web-modeler/run-or-publish-your-process.md index 41e21d90da..759a9c4345 100644 --- a/docs/components/modeler/web-modeler/run-or-publish-your-process.md +++ b/docs/components/modeler/web-modeler/run-or-publish-your-process.md @@ -41,6 +41,7 @@ To deploy, click **Deploy** in the upper right corner of the modeling screen: - Make sure your process is free of errors, otherwise it can't be deployed. Use the [problems panel to detect and fix errors](./fix-problems-in-your-diagram.md). - Make sure all dependent files are deployed first, such as DMN diagrams, forms, or called processes. You can use the [link tool](./advanced-modeling/call-activity-linking.md) to drill-down into linked resources and deploy them. + If you are using [`versionTag` binding](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md) for a linked resource, make sure it is deployed with the correct version tag. :::tip Consider using a [process application](process-applications.md) that allows you to deploy a process and all dependent files together in a single bundle. ::: diff --git a/docs/guides/migrating-from-camunda-7/adjusting-bpmn-models.md b/docs/guides/migrating-from-camunda-7/adjusting-bpmn-models.md index c2c38cd442..08c4f1b36e 100644 --- a/docs/guides/migrating-from-camunda-7/adjusting-bpmn-models.md +++ b/docs/guides/migrating-from-camunda-7/adjusting-bpmn-models.md @@ -28,6 +28,12 @@ The following attributes/elements **cannot** be migrated: - `camunda:jobPriority`: There is no way to prioritize jobs in Zeebe (yet). - `camunda:failedJobRetryTimeCycle`: You cannot yet configure the retry time cycle. Alternatively, you can [modify your code](/apis-tools/zeebe-api/gateway-service.md#input-failjobrequest) to use the `retryBackOff` timeout (in ms) for the next retry. +### Processes + +The following attribute can be migrated: + +- `camunda:versionTag` to `bpmn:extensionElements > zeebe:versionTag value` + ### Service tasks :::note @@ -116,7 +122,7 @@ The following attributes/elements can be migrated: - `camunda:formRef` to `zeebe:formDefinition formId` - `camunda:formRefBinding` to `zeebe:formDefinition bindingType` :::note - Camunda 8 only supports the `deployment` and `latest` binding types for user task forms. + Camunda 8 only supports the `latest`, `deployment`, and `versionTag` [binding types](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md) for user task forms. ::: The following attributes/elements **cannot** yet be migrated: @@ -140,12 +146,13 @@ The following attributes/elements can be migrated: - `camunda:resultVariable` to `zeebe:calledDecision resultVariable` - `camunda:decisionRefBinding` to `zeebe:calledDecision bindingType` :::note - Camunda 8 only supports the `deployment` and `latest` binding types for business rule tasks. + Camunda 8 only supports the `latest`, `deployment`, and `versionTag` [binding types](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md) for business rule tasks. ::: +- `camunda:decisionRefVersionTag` to `zeebe:calledDecision versionTag` The following attributes are **not** yet supported: -- `camunda:decisionRefVersion` and `camunda:decisionRefVersionTag` +- `camunda:decisionRefVersion` - `camunda:mapDecisionResult` (no mapping happens) - `camunda:decisionRefTenantId` @@ -160,15 +167,16 @@ Call activities are generally supported in Zeebe. The following attributes/eleme - `camunda:calledElement` to `zeebe:calledElement processId` - `camunda:calledElementBinding` to `zeebe:calledElement bindingType` :::note - Camunda 8 only supports the `deployment` and `latest` binding types for call activities. + Camunda 8 only supports the `latest`, `deployment`, and `versionTag` [binding types](/docs/components/best-practices/modeling/choosing-the-resource-binding-type.md) for call activities. ::: +- `camunda:calledElementVersionTag` to `zeebe:calledElement versionTag` - Data mapping - `camunda:in` to `zeebe:input` - `camunda:out` to `zeebe:output` The following attributes/elements **cannot** be migrated: -- `camunda:calledElementVersion` and `camunda:calledElementVersionTag` +- `camunda:calledElementVersion`: Zeebe does not support the `version` binding type. - `camunda:variableMappingClass`: You cannot execute code to do variable mapping in Zeebe. - `camunda:variableMappingDelegateExpression`: You cannot execute code to do variable mapping in Zeebe. diff --git a/docs/guides/migrating-from-camunda-7/adjusting-dmn-models.md b/docs/guides/migrating-from-camunda-7/adjusting-dmn-models.md index cfdfba9abe..edaabd029e 100644 --- a/docs/guides/migrating-from-camunda-7/adjusting-dmn-models.md +++ b/docs/guides/migrating-from-camunda-7/adjusting-dmn-models.md @@ -16,9 +16,10 @@ To evaluate Camunda 7 DMN files in Camunda 8, change the following in the XML: Web Modeler will automatically update `modeler:executionPlatform` and `modeler:executionPlatformVersion` to the correct values when you upload a DMN file. ::: +### General considerations + The following elements/attributes are **not** supported in Camunda 8: -- `Version Tag` - `History Time to Live` - You cannot select the `Expression Language`, only FEEL is supported - The property `Input Variable` is removed. In FEEL, the input value can be accessed by using `?` if needed. @@ -26,3 +27,9 @@ The following elements/attributes are **not** supported in Camunda 8: Furthermore, legacy behavior can still be executed but the following should be kept in mind: - Remove data types `integer` + `long` + `double` in favor of `number` for inputs and outputs (in FEEL, there is only a number type represented as `BigDecimal`). + +### Decisions + +The following attribute can be migrated: + +- `camunda:versionTag` to `extensionElements > zeebe:versionTag value` diff --git a/docs/guides/utilizing-forms.md b/docs/guides/utilizing-forms.md index aab2ac4fb9..419eddc11e 100644 --- a/docs/guides/utilizing-forms.md +++ b/docs/guides/utilizing-forms.md @@ -83,7 +83,7 @@ You can now monitor your instances in [Operate](../components/operate/operate-in :::info Linked Camunda Forms will automatically be deployed along with the diagram. -As linked forms are always resolved to their latest version, make sure you don't accidentally deploy a diagram. +As linked forms are resolved to their latest version (unless you change the [binding type](/components/modeler/web-modeler/advanced-modeling/form-linking.md#camunda-form-linked)), make sure you don't accidentally deploy a diagram. When deploying to a Camunda 8 cluster with a version lower than 8.4, forms linked to user tasks or none start events will be automatically embedded into the user task to guarantee backwards compatibility. Read more about the different ways to reference Camunda Forms in the [user task forms reference](/components/modeler/bpmn/user-tasks/user-tasks.md#user-task-forms).