From 4134da24c900d641aaba765a6302a846168a96dd Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Fri, 6 Dec 2024 12:53:24 -0500 Subject: [PATCH 01/10] intro changes for smooth migration zeebe user tasks next --- .../camunda-api-rest-overview.md | 2 +- .../03-task-application-architecture.md | 4 +- .../java-client/zeebe-process-test.md | 2 +- .../migrate-to-zeebe-user-tasks.md | 39 ++++++++++--------- .../specifications/search-tasks.api.mdx | 2 +- .../modeler/bpmn/user-tasks/user-tasks.md | 39 +++++++++++-------- .../advanced-modeling/form-linking.md | 4 ++ 7 files changed, 51 insertions(+), 41 deletions(-) diff --git a/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md b/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md index a1274d6933..c640d87693 100644 --- a/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md +++ b/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md @@ -1,7 +1,7 @@ --- id: camunda-api-rest-overview title: "Overview" -description: "Interact with Camunda 8 clusters. Activate jobs and run user task state operations for Zeebe user tasks." +description: "Interact with Camunda 8 clusters. Activate jobs and run user task state operations for Camunda user tasks." --- The Camunda 8 REST API is a REST API designed to interact with a Camunda 8 cluster. diff --git a/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md b/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md index 50dfb21ef1..0a3a621a83 100644 --- a/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md +++ b/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md @@ -6,10 +6,10 @@ description: "Understand and decide on the architecture of your task application A typical task application architecture consists of a task application frontend, a backend-for-frontend, and one or more data sources or services that contain business data relevant for the application users to perform their work. The backend implements Camunda Zeebe and Tasklist clients to retrieve and interact with tasks via Camunda APIs. For historical process instance data, Operate is also required. -Depending on the user task implementation type (job-based vs Zeebe user task) you use in your processes, you need to run either the Tasklist or Zeebe client to run operations on task. Task, form, and variable retrieval happens via the Tasklist API. Learn more about the differences of the task implementation types in the [migration guide for Zeebe user tasks](/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks.md). +Depending on the user task implementation type (Job worker-based vs Camunda user task) you use in your processes, you need to run either the Tasklist or Zeebe client to run operations on task. Task, form, and variable retrieval happens via the API. Learn more about the differences of the task implementation types in the [migration guide for Camunda user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). :::tip -Starting a completely new project? Use only Zeebe user tasks to simplify your implementation. +Starting a new project? Use Camunda user tasks to simplify your implementation. ::: Click on any element of this diagram to jump to the documentation page for the respective component: diff --git a/docs/apis-tools/java-client/zeebe-process-test.md b/docs/apis-tools/java-client/zeebe-process-test.md index b64f69ef24..f5775fc749 100644 --- a/docs/apis-tools/java-client/zeebe-process-test.md +++ b/docs/apis-tools/java-client/zeebe-process-test.md @@ -8,7 +8,7 @@ processes. It will start a lightweight in-memory Zeebe engine and provide you wi verify your process behaves as expected. :::note -As of 8.5.0, Zeebe Process Test does not support the new REST API and related features (e.g. Zeebe user tasks). +As of 8.5.0, Zeebe Process Test does not support the new REST API and related features (e.g. Camunda user tasks). ::: ## Prerequisites diff --git a/docs/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks.md b/docs/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks.md index b4f17bacb4..40a39a836f 100644 --- a/docs/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks.md +++ b/docs/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks.md @@ -1,7 +1,7 @@ --- id: migrate-to-zeebe-user-tasks -title: Migrate to Zeebe user tasks -description: "Learn how to migrate job worker-based user tasks to Zeebe-based tasks." +title: Migrate to Camunda user tasks +description: "Learn how to migrate job worker-based user tasks to Camunda user tasks." --- import DocCardList from '@theme/DocCardList'; @@ -15,8 +15,9 @@ import styles from "./assets/css/cleanImages.module.css"; import APIArchitectureImg from './assets/img/api-architecture.png'; import ZeebeTaskSelectionImg from './assets/img/zeebe-user-task-selection.png'; -Camunda 8.5 introduces a new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type: Zeebe user tasks. -Zeebe user tasks have several benefits, including: +Camunda 8.5 introduced a new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type: Camunda user task. + +Camunda user tasks have several benefits, compared to Job worked-based user tasks. It includes: - Running directly on the automation engine for high performance. - Removing dependencies and round trips to Tasklist. @@ -30,7 +31,7 @@ In this guide, you will learn: ## Decide on your migration path -Zeebe user tasks require migration of the user tasks in both your diagrams and the task API. +Camunda user tasks require migration of the user tasks in both your diagrams and the task API. With this in mind, you can migrate at your own pace. If you should migrate now or later, and what is required to migrate depends on your current setup and future plans. @@ -47,7 +48,7 @@ Use the following decision helper questionnaire to figure out what's right for y ### Task type differences -Learn the differences between both task types and make an informed decision, and understand the new capabilities of Zeebe user tasks. Refer to this table for important high-level differences of the two task types: +Learn the differences between both task types and make an informed decision, and understand the new capabilities of Camunda user tasks. Refer to this table for important high-level differences of the two task types: @@ -57,7 +58,7 @@ Learn the differences between both task types and make an informed decision, and Existing implementation @@ -91,7 +92,7 @@ Learn the differences between both task types and make an informed decision, and @@ -175,7 +176,7 @@ We recommend you migrate process-by-process, allowing you to thoroughly test the 3. Check if the task has an embedded form. - If a form is embedded, [transform it into a linked form](/components/modeler/bpmn/user-tasks/user-tasks.md#camunda-form-linked) before you change the task type implementation. Press `Ctrl+Z` or `⌘+Z` to undo if you accidentally removed your embedded form. 4. Open the **Implementation** section in the properties panel. -5. Click the **Type** dropdown and select **Zeebe user task**. The linked form or external form reference will be preserved. +5. Click the **Type** dropdown and select **Camunda user task**. The linked form or external form reference will be preserved. Task Type Selection @@ -184,7 +185,7 @@ Repeat these steps for all user tasks in the process. Then, deploy the process t ## Use the new Zeebe Task API :::note -The Tasklist REST API is not deprecated, and you still need it for queries on both task types. +The Tasklist REST API is deprecated and will be deleted with the 8.9 release. ::: Operations on Zeebe user tasks which modify the task state have to be performed using the new Zeebe REST API. However, queries and adjacent operations still require the Tasklist REST API. The following table provides a breakdown of which operations are supported in which API, and for which user tasks. @@ -198,42 +199,42 @@ Operations on Zeebe user tasks which modify the task state have to be performed - + - + - + - + - + - + - + - +
-
Zeebe user tasks
+
Camunda user tasks
Recommended for new projects
Partially
Queries, GET tasks, forms, variables - ℹ Currently, you must use Zeebe and Tasklist APIs to use Zeebe user tasks + ℹ Currently, you must use Zeebe and Tasklist APIs to use Camunda user tasks
Query tasks ✔ All types← Use Tasklist API✔ Camunda user tasks
Get task ✔ All types← Use Tasklist API✔ Camunda user tasks
Retrieve task variables ✔ All types← Use Tasklist API✔ Camunda user tasks
Get task form ✔ All types← Use Tasklist API✔ Camunda user tasks
Change task assignment ✔ Job worker-based tasks✔ Zeebe tasks✔ Camunda user tasks
Complete task ✔ Job worker-based tasks✔ Zeebe tasks✔ Camunda user tasks
Update task -✔ Zeebe tasks✔ Camunda user tasks
Safe and retrieve draft variables ✔ All types← Use Tasklist API✔ Camunda user tasks
@@ -385,4 +386,4 @@ If your task application does not work properly after migration, check the follo - **The endpoints return specific error messages when you run them on the wrong task type**: Ensure to call the right endpoint for the right task type, c.f. above [table](#use-the-new-zeebe-task-api). - **Forms do not appear**: Ensure you have extracted embedded forms, if any, and [transformed them into linked forms](/components/modeler/bpmn/user-tasks/user-tasks.md#camunda-form-linked), before you change the task type implementation. -- **Task update operation does not work**: The update operation is only available to Zeebe user tasks. +- **Task update operation does not work**: The update operation is only available to Camunda user tasks. diff --git a/docs/apis-tools/tasklist-api-rest/specifications/search-tasks.api.mdx b/docs/apis-tools/tasklist-api-rest/specifications/search-tasks.api.mdx index b4d862e180..202c730ae1 100644 --- a/docs/apis-tools/tasklist-api-rest/specifications/search-tasks.api.mdx +++ b/docs/apis-tools/tasklist-api-rest/specifications/search-tasks.api.mdx @@ -55,7 +55,7 @@ An array used to specify a list of variable names that should be included in the
  • Array [
  • ]
    • priority object
    -Rules to filter out tasks by their priority. Applicable only for Zeebe user tasks. +Rules to filter out tasks by their priority. Applicable only for Camunda user tasks.
    diff --git a/docs/components/modeler/bpmn/user-tasks/user-tasks.md b/docs/components/modeler/bpmn/user-tasks/user-tasks.md index 5212b2a3b2..da348b7143 100644 --- a/docs/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/docs/components/modeler/bpmn/user-tasks/user-tasks.md @@ -12,19 +12,21 @@ When the user task instance is completed, the process instance continues. ![user-task](assets/user-task.png) -:::info -Camunda 8 also supports the implementation of user tasks with a [service task](/components/modeler/bpmn/service-tasks/service-tasks.md)-like behavior. -Refer to the [job worker implementation](#job-worker-implementation) section below. -Version 8.4 and below are limited to the job worker implementation. -::: +## User task implementation types -## Define a user task +A default user task implementation type is the **Camunda user task** with the `zeebe:userTask` extension element. +It is the recommended implementation type that is introduced on Camunda version 8.6. -A user task is marked as a **Zeebe user task** by the `zeebe:userTask` extension element. Without the `zeebe:userTask` extension element, the user task behaves like a [service task](#job-worker-implementation). +Alternatively, user tasks can be implemented with **Job workers** by removing the `zeebe:userTask` extension element. +Refer to the [Job worker implementation](#job-worker-implementation) section for details. -You can define assignments, scheduling, variable mappings, and a form for the user task as detailed in the following sections. +## Camunda user tasks -The [job worker implementation](#job-worker-implementation) section details the differences and limitations of job worker-based user tasks. +Camunda user tasks support assignments, scheduling, task updates, variable mappings, and a form for a user task as detailed in the following sections. + +:::note +The Camunda user task implementation type was previously referred to as the **Zeebe user task**. +::: ### Assignments @@ -98,7 +100,7 @@ To set the priority of a user task, specify the priority in the `priority` attri ### Variable mappings -By default, all Zeebe user task variables are merged into the process instance. This +By default, all Camunda user task variables are merged into the process instance. This behavior can be customized by defining an output mapping at the user task. Input mappings can be used to transform the variables into a different format. @@ -158,16 +160,19 @@ configuration parameters for tasklist applications. ## Job worker implementation -A user task does not have to be managed by Zeebe. Instead, you can also use -job workers to implement a custom user task logic. Note that you will lose all the task lifecycle and state management features that Zeebe provides and will have to implement them yourself. Use job workers only in case you require a very specific implementation of user tasks that can't be implemented on top of Zeebe user tasks. +A user task does not have to be managed by Zeebe. Instead, you can also use Job workers to implement a custom user task logic. + +Note that you will lose all the task lifecycle and state management features that Zeebe provides and will have to implement them yourself. Use job workers only in case you require a very specific implementation of user tasks that can't be implemented on top of Camunda user tasks. :::info -If you started using Camunda 8 with version 8.4 or a lower version and upgraded to 8.5 or newer, your user tasks are probably implemented as job workers. Refer to the [migration guide](/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks.md) to find a detailed list of the differences between the task implementation types and learn how to migrate to Zeebe user tasks. +Camunda version 8.4 and lower support only user tasks with the Job worker implementation. + +If you started using Camunda 8 with version 8.4 or a lower version and upgraded to 8.5 or newer, your user tasks are probably implemented as Job workers. Refer to the [migration guide](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md) to find a detailed list of the differences between the task implementation types and learn how to migrate to Camunda user tasks. ::: -You can define a job worker implementation for a user task by removing its `zeebe:userTask` extension element. +You can define a Job worker implementation for a user task by removing its `zeebe:userTask` extension element. -User tasks with a job worker implementation behave exactly like [service tasks](/components/modeler/bpmn/service-tasks/service-tasks.md). The differences between these task +User tasks with a Job worker implementation behave exactly like [service tasks](/components/modeler/bpmn/service-tasks/service-tasks.md). The differences between these task types are the visual representation (i.e. the task marker) and the semantics for the model. When a process instance enters a user task with job worker implementation, it creates @@ -190,9 +195,9 @@ This also limits available metrics and reporting for such user tasks to what is All user task-specific data like assignments and scheduling information is provided in the job as [task headers](/components/modeler/bpmn/service-tasks/service-tasks.md#task-headers). -You cannot use the Camunda 8 Zeebe User Task API to work on user tasks based on job workers. +You cannot use the Camunda 8 API to work on user tasks based on job workers. Overall, you are limiting those user tasks to the capabilities of [service tasks](/components/modeler/bpmn/service-tasks/service-tasks.md). -Zeebe user task-specific features are not available to those user tasks. +Camunda user task-specific features are not available to those user tasks. ## Additional resources 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 c7cf43464f..fbfe80c2ec 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md @@ -89,6 +89,10 @@ To correct any instances affected by this issue, we recommend the following step ### Camunda Form (embedded) +:::info +Embedded forms are supported only by Job worker-based user tasks and are not available for the [Camunda user task implementation type](/components/modeler/bpmn/user-tasks/user-tasks.md#user-task-implementation-types). +::: + When choosing **Camunda Form (embedded)** as type you have the option to directly paste the form's JSON schema into the **Form JSON configuration** field of the properties panel. The form will be embedded directly into the BPMN diagram's XML representation. From 6f95b88d66ee10072c192227f4c3fe9f2663064b Mon Sep 17 00:00:00 2001 From: volodymyr-melnykc Date: Wed, 11 Dec 2024 16:57:53 +0100 Subject: [PATCH 02/10] Update the guide for implementing a task life cycle with Camunda 8 API --- .../02-user-task-lifecycle.md | 30 +++++++++++++------ 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/docs/apis-tools/frontend-development/01-task-applications/02-user-task-lifecycle.md b/docs/apis-tools/frontend-development/01-task-applications/02-user-task-lifecycle.md index 85fdc6ea1e..425140230a 100644 --- a/docs/apis-tools/frontend-development/01-task-applications/02-user-task-lifecycle.md +++ b/docs/apis-tools/frontend-development/01-task-applications/02-user-task-lifecycle.md @@ -76,21 +76,31 @@ Our best practices, as implemented in Tasklist, are as follows: Make sure that you create your own validation logic that matches your use case. -## Implement the life cycle with the task API +## Implement task life cycle with the Camunda 8 API -To implement task life cycle operations with the task API, call the respective endpoints: +Use the Camunda 8 REST API to implement task life cycle operations. You can find the API specifications [here](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md). -- [`POST /user-tasks/:taskKey/assignment`](/apis-tools/zeebe-api-rest/specifications/assign-a-user-task.api.mdx) or [`DELETE /user-tasks/:taskKey/assignee`](/apis-tools/zeebe-api-rest/specifications/unassign-a-user-task.api.mdx) to change task assignment. -- [`PATCH /user-tasks/:taskKey`](/apis-tools/zeebe-api-rest/specifications/update-a-user-task.api.mdx) to update a task. -- [`POST /user-tasks/:taskKey/completion`](/apis-tools/zeebe-api-rest/specifications/complete-a-user-task.api.mdx) to complete a task. +Task life cycle events can be tracked via the following API endpoints: -All these endpoints (except `DELETE`) allow you to send a custom `action` attribute via the payload. The `action` attribute carries any arbitrary string and can be used to track any life cycle event, including those mentioned above. +- Assign user task: + - [`POST /user-tasks/:userTaskKey/assignment`](/apis-tools/camunda-api-rest/specifications/assign-user-task.api.mdx) + - [`DELETE /user-tasks/:userTaskKey/assignee`](/apis-tools/camunda-api-rest/specifications/unassign-user-task.api.mdx) is used to unassing a user task. +- Update user task: + - [`PATCH /user-tasks/:taskKey`](/apis-tools/camunda-api-rest/specifications/update-user-task.api.mdx) +- Complete user task: + - [`POST /user-tasks/:taskKey/completion`](/apis-tools/camunda-api-rest/specifications/complete-user-task.api.mdx) -#### [`POST /user-tasks/:taskKey/assignment`](/apis-tools/zeebe-api-rest/specifications/assign-a-user-task.api.mdx) +The endpoints above (except `DELETE`) allow you to send a custom `action` attribute via the payload. The `action` attribute carries any arbitrary string and can be used to track any life cycle event, including those mentioned above. + +#### Task assignment + +[`POST /user-tasks/:userTaskKey/assignment`](/apis-tools/camunda-api-rest/specifications/assign-user-task.api.mdx) Use the `assignment` endpoint to change the task assignment. Use the `action` attribute to indicate the cause of the change, including `claim`, `reassign`, or `assign`. -#### [`PATCH /user-tasks/:taskKey`](/apis-tools/zeebe-api-rest/specifications/update-a-user-task.api.mdx) +#### Task update + +[`PATCH /user-tasks/:taskKey`](/apis-tools/camunda-api-rest/specifications/update-user-task.api.mdx) Use the `update` endpoint to change candidate users, groups, the due date, or the follow-up date by defining the `changeset`. You can also send it with an empty `changeset` and just pass an `action`. Use it to send `start`, `pause`, and `resume` actions. Additionally, you can send anything of interest or relevant for the audit log such as `escalate`, `requestFurtherInformation`, `uploadDocument`, or `openExternalApp`. @@ -105,7 +115,9 @@ An example request payload could look like this: } ``` -#### [`POST /user-tasks/:taskKey/completion`](/apis-tools/zeebe-api-rest/specifications/complete-a-user-task.api.mdx) +#### Task completion + +[`POST /user-tasks/:taskKey/completion`](/apis-tools/camunda-api-rest/specifications/complete-user-task.api.mdx) Use the `completion` endpoint to complete a task. Pass along with it the outcome of the task via the `action` attribute, such as `approve` or `reject`. From 93730615d50525c03d24e9f3ae210443a1aa14d4 Mon Sep 17 00:00:00 2001 From: volodymyr-melnykc Date: Thu, 12 Dec 2024 17:22:44 +0100 Subject: [PATCH 03/10] Update the info message about embedded forms being supported only by Job worker-based user tasks --- .../modeler/web-modeler/advanced-modeling/form-linking.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 fbfe80c2ec..58c09aea9d 100644 --- a/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md +++ b/docs/components/modeler/web-modeler/advanced-modeling/form-linking.md @@ -90,7 +90,7 @@ To correct any instances affected by this issue, we recommend the following step ### Camunda Form (embedded) :::info -Embedded forms are supported only by Job worker-based user tasks and are not available for the [Camunda user task implementation type](/components/modeler/bpmn/user-tasks/user-tasks.md#user-task-implementation-types). +Embedded forms are supported only for Job Worker-based user tasks. They are not available for the [Camunda user task implementation type](/components/modeler/bpmn/user-tasks/user-tasks.md#user-task-implementation-types). ::: When choosing **Camunda Form (embedded)** as type you have the option to directly paste the form's JSON schema into the **Form JSON configuration** field of the properties panel. From 345d9d5cd7c85137cf49e290c2d033a8eb255778 Mon Sep 17 00:00:00 2001 From: volodymyr-melnykc Date: Thu, 12 Dec 2024 18:12:33 +0100 Subject: [PATCH 04/10] Update the guide with limitations for the Job worker-based user tasks --- .../modeler/bpmn/user-tasks/user-tasks.md | 41 ++++++++++--------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/docs/components/modeler/bpmn/user-tasks/user-tasks.md b/docs/components/modeler/bpmn/user-tasks/user-tasks.md index 2dd4458bde..9c9ec24844 100644 --- a/docs/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/docs/components/modeler/bpmn/user-tasks/user-tasks.md @@ -160,24 +160,22 @@ configuration parameters for tasklist applications. ## Job worker implementation -A user task does not have to be managed by Zeebe. Instead, you can also use Job workers to implement a custom user task logic. +A user task does not have to be managed by Zeebe. You can implement custom user task logic using Job workers. -Note that you will lose all the task lifecycle and state management features that Zeebe provides and will have to implement them yourself. Use job workers only in case you require a very specific implementation of user tasks that can't be implemented on top of Camunda user tasks. +To define a Job worker implementation for a user task, simply remove the `zeebe:userTask` extension element from the task. User tasks implemented via Job workers behave similarly to service tasks, with two key differences: -:::info -Camunda version 8.4 and lower support only user tasks with the Job worker implementation. +- Visual representation: The visual marker distinguishes user tasks from service tasks. +- Model semantics: The interpretation and purpose in the process model differ. -If you started using Camunda 8 with version 8.4 or lower version and upgraded to 8.5 or newer, your user tasks are probably implemented as Job workers. Refer to the [migration guide](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md) to find a detailed list of the differences between the task implementation types and learn how to migrate to Camunda user tasks. +:::info +The Job worker implementation for user tasks is deprecated. We recommend using [Camunda user tasks](#camunda-user-tasks) instead for enhanced functionality and adherence to best practices. For a detailed comparison of task implementation types and guidance on migrating to Camunda user tasks, see the [migration guide](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). ::: -You can define a Job worker implementation for a user task by removing its `zeebe:userTask` extension element. - -User tasks with a Job worker implementation behave exactly like [service tasks](/components/modeler/bpmn/service-tasks/service-tasks.md). The differences between these task -types are the visual representation (i.e. the task marker) and the semantics for the model. +When a process instance reaches a user task with a Job worker implementation: -When a process instance enters a user task with job worker implementation, it creates -a corresponding job and waits for its completion. A job worker should request jobs of the job type `io.camunda.zeebe:userTask` -and process them. When the job is completed, the process instance continues. +1. Zeebe creates a corresponding job and waits for its completion. +2. A Job worker processes jobs of the type io.camunda.zeebe:userTask. +3. Once the job is completed, the process instance resumes execution. Use [task headers](/components/modeler/bpmn/service-tasks/service-tasks.md#task-headers) to pass static parameters to the job worker. @@ -188,16 +186,19 @@ to transform the variables passed to the job worker, or to customize how the var ### Limitations -User tasks based on a job worker implementation provide no insight into the lifecycle of the task in the engine. -You need to manage the user task's lifecycle in your own application outside the engine. -This also limits available metrics and reporting for such user tasks to what is available for service tasks. +User tasks implemented using Job workers come with significant limitations when compared to [Camunda user tasks](#camunda-user-tasks): + +1. **API compatibility**: + You cannot use the [Camunda 8 API](/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) to manage user tasks based on Job workers. These tasks are restricted to the functionality provided for [service tasks](/components/modeler/bpmn/service-tasks/service-tasks.md). Job worker-based user tasks can only be managed using the deprecated [Tasklist API](/docs/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) or [Zeebe API](/docs/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md). + +2. **Lifecycle management**: + The Zeebe engine provides no visibility into lifecycle and state management features of Job worker-based user tasks. This means that you must handle these aspects in your custom application, outside the engine. Consider this approach only if your use case requires a highly specific user task implementation that cannot be achieved with Camunda user tasks. -All user task-specific data like assignments and scheduling information is provided in the job as -[task headers](/components/modeler/bpmn/service-tasks/service-tasks.md#task-headers). +3. **Reduced metrics and reporting**: + Metrics and reporting for such user tasks are limited to the capabilities available for service tasks. This means you lose access to user task-specific insights provided by the Zeebe engine. -You cannot use the Camunda 8 API to work on user tasks based on job workers. -Overall, you are limiting those user tasks to the capabilities of [service tasks](/components/modeler/bpmn/service-tasks/service-tasks.md). -Camunda user task-specific features are not available to those user tasks. +4. **Task-specific operations**: + Assignments, scheduling, and other user task-specific details are included in the job as [task headers](/components/modeler/bpmn/service-tasks/service-tasks.md#task-headers). These must be handled in your custom implementation. Advanced user task features offered by Camunda are not available for Job worker-based user tasks. ## Additional resources From 34163046bcec4ec4ce5d573a09fe38d94b73ec25 Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Fri, 13 Dec 2024 11:35:49 -0500 Subject: [PATCH 05/10] rename to camunda user task --- api/tasklist/tasklist-openapi.yaml | 6 +- .../camunda-api-rest-overview.md | 4 + .../03-task-application-architecture.md | 2 +- .../userTaskMigrationDecisionHelperForm.js | 2 +- docs/apis-tools/zeebe-api-rest/tutorial.md | 22 +-- .../zeebe-api-rest/zeebe-api-rest-overview.md | 2 +- .../concepts/process-instance-migration.md | 2 +- docs/reference/announcements/870.md | 183 ++++++++++++++++++ .../process-analysis/user-task-analytics.md | 2 +- .../system-configuration-platform-8.md | 2 +- .../01-introduction-to-task-applications.md | 2 +- .../03-task-application-architecture.md | 2 +- .../migrate-to-zeebe-user-tasks.md | 2 +- .../tasklist-api-rest-overview.md | 2 +- .../apis-tools/zeebe-api-rest/tutorial.md | 2 +- .../modeler/bpmn/user-tasks/user-tasks.md | 4 + .../advanced-modeling/form-linking.md | 2 +- 17 files changed, 217 insertions(+), 26 deletions(-) create mode 100644 docs/reference/announcements/870.md diff --git a/api/tasklist/tasklist-openapi.yaml b/api/tasklist/tasklist-openapi.yaml index 32ee7c05df..c9464f1400 100644 --- a/api/tasklist/tasklist-openapi.yaml +++ b/api/tasklist/tasklist-openapi.yaml @@ -725,7 +725,7 @@ components: - JOB_WORKER - ZEEBE_USER_TASK priority: - description: Rules to filter out tasks by their priority. Applicable only for Zeebe user tasks. + description: Rules to filter out tasks by their priority. Applicable only for job worker-based user tasks managed by Camunda. type: object properties: eq: @@ -859,7 +859,7 @@ components: - JOB_WORKER - ZEEBE_USER_TASK priority: - description: The priority of a user task. The higher the value the higher the priority. Applicable only for Zeebe user tasks. + description: The priority of a user task. The higher the value the higher the priority. Applicable only for job worker-based user tasks managed by Camunda. type: integer minimum: 0 maximum: 100 @@ -957,7 +957,7 @@ components: - JOB_WORKER - ZEEBE_USER_TASK priority: - description: The priority of a user task. The higher the value the higher the priority. Applicable only for Zeebe user tasks. + description: The priority of a user task. The higher the value the higher the priority. Applicable only for job worker-based user tasks managed by Camunda. type: integer minimum: 0 maximum: 100 diff --git a/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md b/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md index c640d87693..c2fea9b719 100644 --- a/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md +++ b/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md @@ -10,6 +10,10 @@ The Camunda 8 REST API is a REST API designed to interact with a Camunda 8 clust Ensure you [authenticate](./camunda-api-rest-authentication.md) before accessing the Camunda 8 REST API. ::: +:::note +The Camunda 8 REST API only supports user tasks managed by Camunda (formerly known as [Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md), which may still appear as such in your XML content). +::: + ## Context paths For SaaS: `https://${REGION}.zeebe.camunda.io:443/${CLUSTER_ID}/v2/`, and for Self-Managed installations: `http://localhost:8080/v2/`. diff --git a/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md b/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md index 2a6b29f4ae..bd7199260e 100644 --- a/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md +++ b/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md @@ -79,7 +79,7 @@ click ZeebeRest "../../../zeebe-api-rest/zeebe-api-rest-overview" Follow these resources to learn more about the individual components: -- Learn how to use the [Camunda 8 API](/apis-tools/camunda-api-rest/specifications/assign-user-task.api.mdx) for task, variable, and form retrieval, and to run operations on Zeebe user tasks. +- Learn how to use the [Camunda 8 API](/apis-tools/camunda-api-rest/specifications/assign-user-task.api.mdx) for task, variable, and form retrieval, and to run operations on job worker-based user tasks managed by Camunda, also known as Camunda user tasks. - Familiarize yourself with the [Tasklist API](/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) to run operations on Job worker-based user tasks. - Understand how to design, embed, and customize [forms](/apis-tools/frontend-development/03-forms/01-introduction-to-forms.md). - Understand how this architecture fits into the overall Camunda architecture with the [Java greenfield stack](/components/best-practices/architecture/deciding-about-your-stack.md). diff --git a/docs/apis-tools/tasklist-api-rest/assets/forms/userTaskMigrationDecisionHelperForm.js b/docs/apis-tools/tasklist-api-rest/assets/forms/userTaskMigrationDecisionHelperForm.js index c2220d4d34..1a03e94c80 100644 --- a/docs/apis-tools/tasklist-api-rest/assets/forms/userTaskMigrationDecisionHelperForm.js +++ b/docs/apis-tools/tasklist-api-rest/assets/forms/userTaskMigrationDecisionHelperForm.js @@ -302,7 +302,7 @@ export default { }, { content: - '\n\n\n{{#if conditions.useUserTasks = "no" or (conditions.runCustomTaskApp = "no" and conditions.runTasklistUI = "no") }}\n
    \nNothing to do for you!
    \nSince you do not use user tasks, you do not have to worry about migrating them.
    \nHowever, if you plan to introduce them at any point in time, you can refer to this decision helper again.\n
    \n{{/if}}\n\n{{#if conditions.runCustomTaskApp = "notYet" and conditions.runTasklistUI = "yes" and conditions.requireLifecycle != null }}\n
    \nUse Zeebe user tasks
    \nAs you plan to introduce a custom task application, \nuse "Zeebe user tasks" as the implementation type for your user tasks.\n

    \nFirst switch the implementation type of all your user tasks to "Zeebe user tasks",\nbefore you start developing your custom task application. \nJob-based user tasks are not supported in the Zeebe API for user tasks.

    \nYou can safely migrate your existing user tasks to the new task type,\nsince the Camunda Tasklist UI supports both task types.\n
    \n{{/if}}\n\n{{#if conditions.runCustomTaskApp = "notYet" and conditions.runTasklistUI = "no" }}\n
    \nUse Zeebe user tasks
    \nAs you plan to introduce a custom task application, \nuse "Zeebe user tasks" as the implementation type for your user tasks.\n
    \n{{/if}}\n\n{{#if conditions.requireLifecycle = "no" and conditions.runCustomTaskApp != "notYet"}}\n
    \nNo immediate action needed
    \nSince you do not plan to use task lifecycle features, there is no urgent need for you to migrate.
    \n{{#if conditions.runTasklistUI = "yes"}}\nThe Camunda Tasklist UI works with both job-based or Zeebe-based user tasks.\nIt does not require any technical migration from your side.
    \n{{/if}}\nHowever, we still recommend to consider a migration as it might ease a future adoption of those features. \n
    \n{{/if}}\n\n\n{{#if conditions.useUserTasks != "no" and conditions.runTasklistUI = "yes" and conditions.runCustomTaskApp = "no" and conditions.requireLifecycle = "yes"}}\n
    \nUse Zeebe user tasks
    \nTo use task lifecycle features, change the implementation type of your user tasks to Zeebe user tasks.

    \nWhile the Camunda Tasklist UI works with both job-based or Zeebe-based user tasks,\nonly Zeebe-based user tasks support lifecycle features.
    \n{{#if conditions.distribution = "sm"}}\n
    \nIn addition, to use the task lifecycle events and metrics,\nconsider to implement a custom exporter.\n{{/if}}\n
    \n{{/if}}\n\n{{#if conditions.useUserTasks != "no" and conditions.runCustomTaskApp = "yes" and conditions.requireLifecycle = "yes"}}\n
    \nUse Zeebe user tasks
    \nTo use task lifecycle features, change the implementation type of your user tasks to Zeebe user tasks.

    \nThis requires you to migrate your custom task application(s) first to use the new Zeebe API for user tasks.
    \nWe recommend you to either
    \n
      \n
    • Upgrade your dev cluster to 8.5, migrate your task application(s) on dev, and migrate your processes step-by-step on dev. \n Once done and tested, move over to production. Recommended for small to mid-size projects.
      • \n
    • Upgrade your dev and prod cluster to 8.5 and write an adapter layer that routes task operation calls to the respective API\n(existing job-based tasks to the Tasklist API, and Zeebe-based tasks to the Zeebe Task API). The Tasklist query API returns the task implementation type\nrequired for the routing. Using this approach, you can migrate each process step-by-step to production, and operate both types at the same. \nThis approach is recommended for larger projects and ensures smoothest migration without interrupting operations and continous delivery.
      • \n
    \n{{#if conditions.distribution = "sm"}}\nIn addition, to use the task lifecycle events and metrics,\nconsider to implement a custom exporter.\n{{/if}}\n
    \n{{/if}}\n\n\n{{#if false}}\nWe recommend to migrate to...\nYou can find learning material here...\nFor reference the following comparison table...\n{{/if}}\n\n{{#if false}}\n
    \n

    Read more

    \nTODO\n
    \n{{/if}}\n', + '\n\n\n{{#if conditions.useUserTasks = "no" or (conditions.runCustomTaskApp = "no" and conditions.runTasklistUI = "no") }}\n
    \nNothing to do for you!
    \nSince you do not use user tasks, you do not have to worry about migrating them.
    \nHowever, if you plan to introduce them at any point in time, you can refer to this decision helper again.\n
    \n{{/if}}\n\n{{#if conditions.runCustomTaskApp = "notYet" and conditions.runTasklistUI = "yes" and conditions.requireLifecycle != null }}\n
    \nUse Camunda user tasks
    \nAs you plan to introduce a custom task application, \nuse "Camunda user tasks" as the implementation type for your user tasks.\n

    \nFirst switch the implementation type of all your user tasks to "Camunda user tasks",\nbefore you start developing your custom task application. \nJob-based user tasks are not supported in the Zeebe API for user tasks.

    \nYou can safely migrate your existing user tasks to the new task type,\nsince the Camunda Tasklist UI supports both task types.\n
    \n{{/if}}\n\n{{#if conditions.runCustomTaskApp = "notYet" and conditions.runTasklistUI = "no" }}\n
    \nUse Camunda user tasks
    \nAs you plan to introduce a custom task application, \nuse "Camunda user tasks" as the implementation type for your user tasks.\n
    \n{{/if}}\n\n{{#if conditions.requireLifecycle = "no" and conditions.runCustomTaskApp != "notYet"}}\n
    \nNo immediate action needed
    \nSince you do not plan to use task lifecycle features, there is no urgent need for you to migrate.
    \n{{#if conditions.runTasklistUI = "yes"}}\nThe Camunda Tasklist UI works with both job-based or Zeebe-based user tasks.\nIt does not require any technical migration from your side.
    \n{{/if}}\nHowever, we still recommend to consider a migration as it might ease a future adoption of those features. \n
    \n{{/if}}\n\n\n{{#if conditions.useUserTasks != "no" and conditions.runTasklistUI = "yes" and conditions.runCustomTaskApp = "no" and conditions.requireLifecycle = "yes"}}\n
    \nUse Camunda user tasks
    \nTo use task lifecycle features, change the implementation type of your user tasks to Camunda user tasks.

    \nWhile the Camunda Tasklist UI works with both job-based or Zeebe-based user tasks,\nonly Zeebe-based user tasks support lifecycle features.
    \n{{#if conditions.distribution = "sm"}}\n
    \nIn addition, to use the task lifecycle events and metrics,\nconsider to implement a custom exporter.\n{{/if}}\n
    \n{{/if}}\n\n{{#if conditions.useUserTasks != "no" and conditions.runCustomTaskApp = "yes" and conditions.requireLifecycle = "yes"}}\n
    \nUse Camunda user tasks
    \nTo use task lifecycle features, change the implementation type of your user tasks to Camunda user tasks.

    \nThis requires you to migrate your custom task application(s) first to use the new Zeebe API for user tasks.
    \nWe recommend you to either
    \n
      \n
    • Upgrade your dev cluster to 8.5, migrate your task application(s) on dev, and migrate your processes step-by-step on dev. \n Once done and tested, move over to production. Recommended for small to mid-size projects.
      • \n
    • Upgrade your dev and prod cluster to 8.5 and write an adapter layer that routes task operation calls to the respective API\n(existing job-based tasks to the Tasklist API, and Zeebe-based tasks to the Zeebe Task API). The Tasklist query API returns the task implementation type\nrequired for the routing. Using this approach, you can migrate each process step-by-step to production, and operate both types at the same. \nThis approach is recommended for larger projects and ensures smoothest migration without interrupting operations and continous delivery.
      • \n
    \n{{#if conditions.distribution = "sm"}}\nIn addition, to use the task lifecycle events and metrics,\nconsider to implement a custom exporter.\n{{/if}}\n
    \n{{/if}}\n\n\n{{#if false}}\nWe recommend to migrate to...\nYou can find learning material here...\nFor reference the following comparison table...\n{{/if}}\n\n{{#if false}}\n
    \n

    Read more

    \nTODO\n
    \n{{/if}}\n', label: "HTML", type: "html", layout: { diff --git a/docs/apis-tools/zeebe-api-rest/tutorial.md b/docs/apis-tools/zeebe-api-rest/tutorial.md index 2bb1795037..1c78932f0a 100644 --- a/docs/apis-tools/zeebe-api-rest/tutorial.md +++ b/docs/apis-tools/zeebe-api-rest/tutorial.md @@ -1,10 +1,10 @@ --- id: zeebe-api-tutorial title: Tutorial -description: "New to the Zeebe API? Step through our tutorial to assign and unassign a user to and from a Zeebe user task." +description: "New to the Zeebe API? Step through our tutorial to assign and unassign a user to and from a Camunda user task." --- -In this tutorial, we'll step through examples to highlight the capabilities of the Zeebe API, such as assigning and unassigning a user to and from a Zeebe user task. +In this tutorial, we'll step through examples to highlight the capabilities of the Zeebe API, such as assigning and unassigning a user to and from a job worker-based user task managed by Camunda, also known as a Camunda user task. ## Prerequisites @@ -34,17 +34,17 @@ Examine the existing `.env.example` file for an example of how your `.env` file :::note -In this tutorial, we will execute arguments to assign and unassign a user to and from a Zeebe user task. You can examine the framework for processing these arguments in the `cli.js` file before getting started. +In this tutorial, we will execute arguments to assign and unassign a user to and from a Camunda user task. You can examine the framework for processing these arguments in the `cli.js` file before getting started. ::: -## Assign a Zeebe user task (POST) +## Assign a Camunda user task (POST) :::note -In this tutorial, you will capture a **Zeebe user task** ID to assign and unassign users in this API. Camunda 8.5 introduced this new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type, and these Zeebe user tasks are different from job worker-based user tasks. See more details on task type differences in the [migrating to Zeebe user tasks documentation](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md#task-type-differences). +In this tutorial, you will capture a **Camunda user task** ID to assign and unassign users in this API. Camunda 8.5 introduced this new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type, and these Camunda user tasks are different from job worker-based user tasks. See more details on task type differences in the [migrating to Camunda user tasks documentation](/apis-tools/migration-manuals/migrate-to-Camunda-user-tasks.md#task-type-differences). ::: -First, let's script an API call to assign a Zeebe user task. +First, let's script an API call to assign a Camunda user task. To do this, take the following steps: @@ -71,7 +71,7 @@ async function assignUser([userTaskKey, assignee]) { `const zeebeApiUrl = process.env.ZEEBE_BASE_URL` -5. On the next line, script the API endpoint to assign a Zeebe user task.: +5. On the next line, script the API endpoint to assign a Camunda user task.: ```javascript const url = `${ZeebeApiUrl}/user-tasks/${userTaskKey}/assignment`; @@ -114,7 +114,7 @@ try { } ``` -8. In your terminal, run `node cli.js zeebe assign `, where `` is the Zeebe user task ID you've captured from Tasklist, and `` is the assignee's email address. Include your own email address if you would like to see these results in your user interface. +1. In your terminal, run `node cli.js zeebe assign `, where `` is the Camunda user task ID you've captured from Tasklist, and `` is the assignee's email address. Include your own email address if you would like to see these results in your user interface. :::note This `assign` command is connected to the `assignUser` function at the bottom of the `zeebe.js` file, and executed by the `cli.js` file. While we will assign and unassign users in this tutorial, you may add additional arguments depending on the API calls you would like to make. @@ -122,9 +122,9 @@ This `assign` command is connected to the `assignUser` function at the bottom of If you have a valid user and task ID, the assignment will now output. If you have an invalid API name or action name, or no arguments provided, or improper/insufficient credentials configured, an error message will output as outlined in the `cli.js` file. If no action is provided, it will default to "assign" everywhere, except when unassigning a user. -## Unassign a Zeebe user task (DELETE) +## Unassign a Camunda user task (DELETE) -To unassign a user from a Zeebe user task, you can use the same Zeebe user task ID from the previous exercise and take the following steps: +To unassign a user from a Camunda user task, you can use the same Camunda user task ID from the previous exercise and take the following steps: 1. Outline your function, similar to the steps above: @@ -171,7 +171,7 @@ try { } ``` -4. In your terminal, run `node cli.js zeebe unassign `, where `` is the Zeebe user task ID. +4. In your terminal, run `node cli.js zeebe unassign `, where `` is the Camunda user task ID. ## If you get stuck diff --git a/docs/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md b/docs/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md index 0c8473dd07..2291756579 100644 --- a/docs/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md +++ b/docs/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md @@ -1,7 +1,7 @@ --- id: zeebe-api-rest-overview title: "Overview" -description: "Interact with Zeebe clusters. Run user task state operations for Zeebe user tasks." +description: "Interact with Zeebe clusters. Run user task state operations for Camunda user tasks." --- ## Introduction diff --git a/docs/components/concepts/process-instance-migration.md b/docs/components/concepts/process-instance-migration.md index 9e13aa0d36..0bc6c42f86 100644 --- a/docs/components/concepts/process-instance-migration.md +++ b/docs/components/concepts/process-instance-migration.md @@ -370,7 +370,7 @@ The following limitations exist that may be supported in future versions: - An element that becomes nested in a newly added subprocess - An element that was nested in a subprocess is no longer nested in that subprocess - Mapping instructions cannot change the element type -- Mapping instructions cannot change the task implementation, e.g. from a job worker user task to a Zeebe user task +- Mapping instructions cannot change the task implementation, e.g. from a job worker user task to a job worker-based user task managed by Camunda, also known as a Camunda user task - The process instance must be in a wait state, i.e. waiting for an event or external input like job completion. It may not be taking a sequence flow or triggering an event while migrating the instance A full overview of error codes can be found in the migration command [RPC](/apis-tools/zeebe-api/gateway-service.md#migrateprocessinstance-rpc) or [REST](/apis-tools/camunda-api-rest/specifications/migrate-process-instance.api.mdx). diff --git a/docs/reference/announcements/870.md b/docs/reference/announcements/870.md new file mode 100644 index 0000000000..b4d5c42fdf --- /dev/null +++ b/docs/reference/announcements/870.md @@ -0,0 +1,183 @@ +--- +id: announcements-870 +title: "8.7 Announcements" +description: "Important changes and updates for the Camunda 8.7 release including deprecation & removal notices." +--- + +Important changes and updates for the Camunda 8.7 release are summarized below. + +| Scheduled release date | Scheduled end of maintenance | Release notes | Blog | +| :--------------------- | :--------------------------- | :--------------------------------------------------- | :---------------------------------------------------------------------------------------------- | +| 11 February 2025 | 11 August 2026 | [8.7 release notes](/reference/release-notes/870.md) | [Announcing Camunda 8.7](https://camunda.com/blog/2024/11/camunda-8-7-releasing-february-2025/) | + +- [API updates](#api-updates-saasself-managed) +- [Identity management updates](#identity-management-updates-saasself-managed) +- [Installation and deployment updates](#installation-and-deployment-updates-self-managed) +- [Camunda Java client and Camunda Spring SDK](#camunda-java-client-and-camunda-spring-sdk-self-managed) + +## API updates SaaSSelf-Managed + +The 8.7 release includes API updates to support the move to a [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) unified experience. + +### Camunda 8 REST API updates + +- New Query endpoints (with advanced search filtering) will be added for process entities (processes, decisions, user tasks, and forms). These will replace the component APIs (Tasklist, Operate) going forward. +- New endpoints will allow you to manage and query users and resource permissions in an orchestration cluster. +- All the Camunda 8 REST API endpoints will support resource-based authorizations to enable fine-grained permissions. +- API terminology is aligned so technical assets have an identical, easily-understood, descriptive property name. + +### Deprecated: Operate and Tasklist v1 REST APIs + +The deprecation process for the [Operate](/apis-tools/operate-api/overview.md) and [Tasklist](/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) REST APIs starts with the 8.7 release. You can begin migrating to the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) for querying to prepare for this change. + +- Version 8.7, 8.8: These APIs are still available but deprecated, and so not recommended for new implementations. +- Version 8.9: These APIs will be removed. + +### Deprecated: Job-based User Tasks querying + +As **job-worker** user tasks will be deprecated with Camunda 8.9, Camunda recommends using **Camunda user tasks** (formerly known as **Zeebe user tasks**) in your process definitions. + +- Version 8.7, 8.8: **job-worker** user tasks are available for querying, but Camunda Modeler automatically applies the **Camunda user task** and shows a warning message for each job worker user task. +- Version 8.9: **job-worker** user tasks will be deprecated. With Camunda 8.9+, customers can use the **job-worker** implementation of user tasks as standard jobs with headers to enable open architecture and composable solutions. + +### Deprecated: Zeebe gRPC API endpoints + +With the 8.7 release, Camunda announces the deprecation of several [Zeebe gRPC](/apis-tools/zeebe-api/grpc.md) endpoints for removal in 8.9. + +- Key gRPC endpoints necessary for high-throughput and low-latency applications remain available with 8.7. +- The final list of retained gRPC endpoints will be confirmed with the 8.7 release. +- Selected endpoints will remain active, with others scheduled for removal in the 8.9 release. + +### Removed: Tasklist GraphQL API + +With the 8.7 release, the deprecated [Tasklist GraphQL API](/apis-tools/tasklist-api/tasklist-api-overview.md) will be removed from the product. + + + +## Identity management updates SaaSSelf-Managed + +The [Identity service](/self-managed/identity/what-is-identity.md) is enhanced to deliver greater flexibility, control, and security for both Self-Managed and SaaS users. These updates are part of our broader effort to streamline the platform’s architecture. + +### Cluster-level identity management + +Identity settings will be configured at the orchestration cluster level, allowing each cluster to have unique OIDC configurations. This cluster-specific setup empowers organizations to assign different identity providers (IdPs) across clusters, offering improved control over permissions and user group mappings, resulting in a more streamlined and efficient configuration experience. + +For SaaS customers, identity management in Camunda 8.7 remains consistent with Camunda 8.6, allowing the attachment of a single IdP per organization. However, cluster-level identity capabilities are provided for SaaS as well as Self-Managed. This means that user groups, roles, and access permissions can now be managed at the cluster level, giving SaaS customers the same granular access control as in Self-Managed environments. + +### Decoupling from Keycloak Self-Managed + +Built-in Keycloak integration in Self-Managed is removed, allowing customers to use any compatible IdP. + +- Keycloak remains fully supported as an external option. For cluster-level identity management it must be connected as an external OIDC provider moving forward. +- OpenID Connect (OIDC) remains the standard for seamless integration with chosen IdPs. + +### Resource-based permissions + +Resource-level permissions are introduced for process definitions and web applications. + +- Admin users retain full access, but regular users must be granted specific permissions to perform actions/view resources. +- For organizations that build custom front-ends and access Camunda via API, users with API permissions can still access process data through the V2 API. + + + +## Installation and deployment updates Self-Managed + +Camunda 8.7 introduces a streamlined architecture, consolidating core components such as Zeebe, Operate, and Tasklist into a single deployable unit. Enhanced deployment options are also included, such as new Kubernetes Helm guides, deployment reference architectures, and improved support for professional developers with Camunda 8 Run. + +You can download the alpha release of the unified package from the Camunda GitHub repository, either as an executable Java application (Camunda Orchestration Core) or a Docker image. + +### Helm charts + +If you are using the recommended Camunda 8 deployment option (Helm charts), the upgrade path from version 8.6 to 8.7 will be straightforward by chaninging the values file to the new syntax. Updated Helm charts will be provided to support the upgrade to the new streamlined architecture. + +New migration guides will also be provided to support you when migrating from a previous Camunda version. + +:::caution +Additional upgrade considerations are necessary for deployments that use custom scripts, such as Docker containers, manual installations, or custom-developed Kubernetes deployments. For these deployments, customers can either continue to deploy with their original 8.6 topology and upgrade each component independently, or adopt our Helm Chart approach for the upgrade, which allows for unifying the deployment into a single JAR or container executable. +::: + +#### Separated Ingress removal + +With Camunda 8.7, Helm chart supports only the Combined Ingress setup where all Camunda components run on the same Ingress object and same hostname. + +The following Helm chart values have been removed: + +```yaml +connectors.ingress +console.ingress +identity.ingress +operate.ingress +optimize.ingress +tasklist.ingress +webModeler.ingress +zeebeGateway.ingress +``` + +### Manual installation + +For organizations that do not use cloud-native platforms such as Kubernetes or container services, we will publish a reference architecture that provides guidance on implementing Camunda production clusters on VM-based systems, using Amazon Web Services (AWS) EC2 as an example. + +The architecture will include details on optimal instance sizing, network configurations, and security best practices, to ensure robust performance and reliability. + +### Camunda Exporter + +A new Camunda Exporter brings the importer and archiving logic of web components (Tasklist and Operate) closer to the distributed platform (Zeebe). The index schema is also being harmonized. + +#### Harmonized index schema + +Camunda is harmonizing our index structure and usage. + +- This removes unnecessary duplications over multiple indices due to the previous architecture. +- With this change, several Operate indices can and will be used by Tasklist. +- New indices have been created to integrate Identity into the system. + +![Harmonized indices schema](../img/harmonized-indices-schema.png) + +#### Camunda Exporter + +The exporter can consume Zeebe records (mostly events created by the engine), aggregate data, and store the related data into shared and harmonized indices. + +- Data is archived in the background, coupled to the exporter but without blocking the exporter's progress. +- Indices can be located in either ElasticSearch (ES) or Opensearch (OS). Our web components (Tasklist and Operate) then use the new harmonized indices to show data to the user. + +The following diagram shows a simplified version of this work. + +![Camunda Exporter diagram](../img/target-camunda-exporter.png) + +- For example, Tasklist and Operate Importers are still required for old data to be imported, but the Camunda exporter writes all new data into ES/OS. After old indices are drained, importers can be turned off. +- The archiver, which takes care of the archiving of completed process instances, will be moved into the Zeebe system as well, to reduce the installation complexity and provide a better scaling and replication factor (based on partitions). +- This helps achieve a streamlined architecture, and improves platform performance and stability (especially regarding ES/OS). +- A new separate component covers the migration, which will be part of the single application but can also deployed separately. It will adjust the previous Operate indices to make them more harmonized and usable by Tasklist. + + + +## Camunda Java client and Camunda Spring SDK Self-Managed + +With the Camunda 8.7 release, Camunda Java client and Camunda Spring SDK replace the Zeebe Java client and Zeebe Spring SDK. This allows you to use a single consolidated client to interact with Camunda clusters. + +The `CamundaClient` replaces the `ZeebeClient`, offering the same functionality and adding new capabilities. + +:::note + +- If you need to continue using the old `ZeebeClient`, you can use the version 8.6 artifact without any issues with newer cluster versions as the client is forward-compatible. +- The Zeebe Java client will not be developed further and only receives bug fixes while version 8.6 is officially supported. + +::: + +### Key changes + +| Change | Description | +| :---------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| New package structure | Package `io.camunda.client`: Contains the new `CamundaClient` and all 8.7 features. | +| Refactored properties and environment variables |

    • All old Java client property names are refactored to more general ones. For example, `zeebe.client.tenantId` to `camunda.client.tenantId`.

    • Similarly, environment variables are renamed following the same concept: `ZEEBE_REST_ADDRESS` to `CAMUNDA_REST_ADDRESS`.

    | +| Artifact ID change | The `artifactId` changes from `zeebe-client-java` to `camunda-client-java`. | + +## Southeast Asia region for SaaS customers SaaS + +SaaS customers can now create orchestration clusters in the [Singapore (asia-southeast1) region](/reference/regions.md), ensuring lower latency and improved processing speed for organizations operating in southeast Asian countries. diff --git a/optimize/components/userguide/process-analysis/user-task-analytics.md b/optimize/components/userguide/process-analysis/user-task-analytics.md index 10911b005b..f11de691d4 100644 --- a/optimize/components/userguide/process-analysis/user-task-analytics.md +++ b/optimize/components/userguide/process-analysis/user-task-analytics.md @@ -57,7 +57,7 @@ To evaluate user tasks, the following features are available in the report build - Currently, user task analytics can be used only with assigned or unassigned time. We are working on analyzing net-work time. - This will only work with Tasklist and custom task applications implementing the complete [Camunda Tasklist Lifecycle]($docs$/apis-tools/frontend-development/task-applications/introduction-to-task-applications/). -- User task analytics only work correctly if all user tasks in a process are of type `Zeebe user task`. The `Job worker` user type does not contain task lifecycle information and is therefore not displayed in the view `User tasks` view. +- User task analytics only work correctly if all user tasks in a process are of type `Camunda user task` (formerly Zeebe user task). The `job worker` user type does not contain task lifecycle information and is therefore not displayed in the `User tasks` view. ::: diff --git a/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-8.md b/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-8.md index f89a7ad4d5..f90787423b 100644 --- a/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-8.md +++ b/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-8.md @@ -43,7 +43,7 @@ To use multi-tenancy, the feature must be enabled across all components. | multitenancy.enabled | false | Enables the Camunda 8 multi-tenancy feature in Optimize. | | security.auth.ccsm.baseUrl | null | The base URL of Identity. | -### Settings related to Camunda 8 Zeebe user tasks +### Settings related to Camunda user tasks (formerly Zeebe user tasks) Camunda 8 Self-Managed only diff --git a/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/01-introduction-to-task-applications.md b/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/01-introduction-to-task-applications.md index 9f29b2dc23..3d343cdcc7 100644 --- a/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/01-introduction-to-task-applications.md +++ b/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/01-introduction-to-task-applications.md @@ -59,7 +59,7 @@ Task details are shown when a task is selected from the queue. A [form](/guides/ :::tip Typically, a task application utilizes forms to capture information from the user, to make a decision, to collect the results from a real-world task, or to provide task instructions to the user. -However, a [user task](/components/modeler/bpmn/user-tasks/user-tasks.md/#user-task-forms) is not limited to forms. A user task could also represent navigating to an external desktop or web application, where a task is to be performed, such as updating a record in a CRM. You can even use them to track physical work or actions using sensors, IoT devices, or any interface that can talk to the web, by using the [APIs](/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) or registering a [job worker](/components/concepts/job-workers.md) to the job type `io.camunda.zeebe:userTask` (compatible with [job worker-based user tasks](/components/modeler/bpmn/user-tasks/user-tasks.md) only). +However, a [user task](/components/modeler/bpmn/user-tasks/user-tasks.md/#user-task-forms) is not limited to forms. A user task could also represent navigating to an external desktop or web application, where a task is to be performed, such as updating a record in a CRM. You can even use them to track physical work or actions using sensors, IoT devices, or any interface that can talk to the web, by using the [APIs](/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) or registering a [job worker](/components/concepts/job-workers.md) to the job type `io.camunda.zeebe:userTask` (compatible with [job worker-based user tasks](/components/modeler/bpmn/user-tasks/user-tasks.md) only). However, note that job worker-based user tasks are deprecated with Camunda 8.6. While these are currently still supported, consider [migrating to Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). For these cases, utilize the flexible [custom form key](/components/modeler/web-modeler/advanced-modeling/form-linking.md/#custom-form-key). ::: diff --git a/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md b/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md index b0027b9582..5532305347 100644 --- a/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md +++ b/versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md @@ -80,6 +80,6 @@ click ZeebeRest "../../../zeebe-api-rest/zeebe-api-rest-overview" Follow these resources to learn more about the individual components: - Learn how to use the [Camunda 8 API](/apis-tools/camunda-api-rest/specifications/assign-user-task.api.mdx) for task, variable, and form retrieval, and to run operations on Zeebe user tasks. -- Familiarize yourself with the [Tasklist API](/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) to run operations on job worker-based user tasks. +- Familiarize yourself with the [Tasklist API](/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) to run operations on job worker-based user tasks. However, note that job worker-based user tasks are deprecated with Camunda 8.6. While these are currently still supported, consider [migrating to Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). - Understand how to design, embed, and customize [forms](/apis-tools/frontend-development/03-forms/01-introduction-to-forms.md). - Understand how this architecture fits into the overall Camunda architecture with the [Java greenfield stack](/components/best-practices/architecture/deciding-about-your-stack.md). diff --git a/versioned_docs/version-8.6/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md b/versioned_docs/version-8.6/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md index d1f19118f9..b3d1722d53 100644 --- a/versioned_docs/version-8.6/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md +++ b/versioned_docs/version-8.6/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md @@ -16,7 +16,7 @@ import ZeebeTaskSelectionImg from '../tasklist-api-rest/assets/img/zeebe-user-ta Camunda 8.5 introduced a new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type: Zeebe user tasks. -Zeebe user tasks have several benefits compared to job worked-based user tasks. It includes: +Zeebe user tasks have several benefits compared to job worked-based user tasks (which while still supported, are now deprecated with 8.6). Such benefits include: - Running directly on the automation engine for high performance. - Removing dependencies and round trips to Tasklist. diff --git a/versioned_docs/version-8.6/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md b/versioned_docs/version-8.6/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md index 31bedd5f7c..c7de8fb7b0 100644 --- a/versioned_docs/version-8.6/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md +++ b/versioned_docs/version-8.6/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md @@ -8,7 +8,7 @@ description: "Build applications for human-centered processes by querying user t :::note Camunda introduced the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) with `8.6` to manage and query process entities such as processes, decisions, forms, and user tasks. -Camunda has also introduced [Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md) to build more advanced functionalities. If you use Zeebe user tasks with `8.6`, task management endpoints in the Tasklist API will not work. +Job worker-based user tasks are deprecated with Camunda 8.6. While these are currently still supported, Camunda has also introduced [Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md) to build more advanced functionalities. If you use Zeebe user tasks with `8.6`, task management endpoints in the Tasklist API will not work. ::: ## Introduction diff --git a/versioned_docs/version-8.6/apis-tools/zeebe-api-rest/tutorial.md b/versioned_docs/version-8.6/apis-tools/zeebe-api-rest/tutorial.md index 2bb1795037..36d9be4c62 100644 --- a/versioned_docs/version-8.6/apis-tools/zeebe-api-rest/tutorial.md +++ b/versioned_docs/version-8.6/apis-tools/zeebe-api-rest/tutorial.md @@ -41,7 +41,7 @@ In this tutorial, we will execute arguments to assign and unassign a user to and ## Assign a Zeebe user task (POST) :::note -In this tutorial, you will capture a **Zeebe user task** ID to assign and unassign users in this API. Camunda 8.5 introduced this new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type, and these Zeebe user tasks are different from job worker-based user tasks. See more details on task type differences in the [migrating to Zeebe user tasks documentation](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md#task-type-differences). +In this tutorial, you will capture a **Zeebe user task** ID to assign and unassign users in this API. Camunda 8.5 introduced this new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type, and these Zeebe user tasks are different from job worker-based user tasks (which while still supported, are now deprecated with 8.6). See more details on task type differences in the [migrating to Zeebe user tasks documentation](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md#task-type-differences). ::: First, let's script an API call to assign a Zeebe user task. diff --git a/versioned_docs/version-8.6/components/modeler/bpmn/user-tasks/user-tasks.md b/versioned_docs/version-8.6/components/modeler/bpmn/user-tasks/user-tasks.md index 90a64a6191..cef90cd1f2 100644 --- a/versioned_docs/version-8.6/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/versioned_docs/version-8.6/components/modeler/bpmn/user-tasks/user-tasks.md @@ -26,6 +26,10 @@ You can define assignments, scheduling, variable mappings, and a form for the us The [job worker implementation](#job-worker-implementation) section details the differences and limitations of job worker-based user tasks. +:::note +With 8.6, job worker-based user tasks are now deprecated. While these are currently still supported, consider [migrating to Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). +::: + ### Assignments User tasks support specifying assignments, using the `zeebe:AssignmentDefinition` extension element. diff --git a/versioned_docs/version-8.6/components/modeler/web-modeler/advanced-modeling/form-linking.md b/versioned_docs/version-8.6/components/modeler/web-modeler/advanced-modeling/form-linking.md index cf43c6b50c..4f558fe9ca 100644 --- a/versioned_docs/version-8.6/components/modeler/web-modeler/advanced-modeling/form-linking.md +++ b/versioned_docs/version-8.6/components/modeler/web-modeler/advanced-modeling/form-linking.md @@ -90,7 +90,7 @@ To correct any instances affected by this issue, we recommend the following step ### Camunda Form (embedded) :::info -Embedded forms are supported only by job worker-based user tasks and are not available for the [Zeebe user task implementation type](/components/modeler/bpmn/user-tasks/user-tasks.md#user-task-implementation-types). +Embedded forms are supported only by job worker-based user tasks and are not available for the [Zeebe user task implementation type](/components/modeler/bpmn/user-tasks/user-tasks.md#user-task-implementation-types). However, job worker-based user tasks are now deprecated with 8.6. While these are currently still supported, consider [migrating to Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). ::: When choosing **Camunda Form (embedded)** as type you have the option to directly paste the form's JSON schema into the **Form JSON configuration** field of the properties panel. From 0624bdd1eb4f741663ffd50efe85561ddf845a25 Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Fri, 13 Dec 2024 11:39:17 -0500 Subject: [PATCH 06/10] update announcement --- docs/reference/announcements/870.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/reference/announcements/870.md b/docs/reference/announcements/870.md index b4d5c42fdf..ddf2710228 100644 --- a/docs/reference/announcements/870.md +++ b/docs/reference/announcements/870.md @@ -33,9 +33,9 @@ The deprecation process for the [Operate](/apis-tools/operate-api/overview.md) a - Version 8.7, 8.8: These APIs are still available but deprecated, and so not recommended for new implementations. - Version 8.9: These APIs will be removed. -### Deprecated: Job-based User Tasks querying +### Deprecated: Job-based user tasks querying -As **job-worker** user tasks will be deprecated with Camunda 8.9, Camunda recommends using **Camunda user tasks** (formerly known as **Zeebe user tasks**) in your process definitions. +As **job-worker** user tasks will be deprecated with Camunda 8.9, Camunda recommends using **Camunda user tasks** (formerly known as **Zeebe user tasks**) in your process definitions. Note that you may still see references of **Zeebe user tasks** in your XML, but this is the same thing as Camunda user tasks. - Version 8.7, 8.8: **job-worker** user tasks are available for querying, but Camunda Modeler automatically applies the **Camunda user task** and shows a warning message for each job worker user task. - Version 8.9: **job-worker** user tasks will be deprecated. With Camunda 8.9+, customers can use the **job-worker** implementation of user tasks as standard jobs with headers to enable open architecture and composable solutions. From 216b06cc9a21fb3bcb76ef2ea77d238ecd8280b3 Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Fri, 13 Dec 2024 11:45:56 -0500 Subject: [PATCH 07/10] rename migration manual --- .../camunda-api-rest/camunda-api-rest-overview.md | 2 +- .../03-task-application-architecture.md | 6 +++--- ...zeebe-user-tasks.md => migrate-to-camunda-user-tasks.md} | 2 +- docs/components/modeler/bpmn/user-tasks/user-tasks.md | 2 +- docs/reference/announcements/870.md | 4 ++-- sidebars.js | 2 +- static/.htaccess | 2 +- 7 files changed, 10 insertions(+), 10 deletions(-) rename docs/apis-tools/migration-manuals/{migrate-to-zeebe-user-tasks.md => migrate-to-camunda-user-tasks.md} (99%) diff --git a/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md b/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md index c2fea9b719..25c7b93dcf 100644 --- a/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md +++ b/docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md @@ -11,7 +11,7 @@ Ensure you [authenticate](./camunda-api-rest-authentication.md) before accessing ::: :::note -The Camunda 8 REST API only supports user tasks managed by Camunda (formerly known as [Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md), which may still appear as such in your XML content). +The Camunda 8 REST API only supports user tasks managed by Camunda (formerly known as [Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md), which may still appear as such in your XML content). ::: ## Context paths diff --git a/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md b/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md index bd7199260e..d3ed54419c 100644 --- a/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md +++ b/docs/apis-tools/frontend-development/01-task-applications/03-task-application-architecture.md @@ -6,7 +6,7 @@ description: "Understand and decide on the architecture of your task application A typical task application architecture consists of a task application frontend, a backend-for-frontend, and one or more data sources or services that contain business data relevant for the application users to perform their work. The backend implements Camunda Zeebe and Tasklist clients to retrieve and interact with tasks via Camunda APIs. For historical process instance data, Operate is also required. -Depending on the user task implementation type (Job worker-based vs Camunda user task) you use in your processes, you need to run either the Tasklist or Zeebe client to run operations on task. Task, form, and variable retrieval happens via the API. Learn more about the differences of the task implementation types in the [migration guide for Camunda user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). +Depending on the user task implementation type (Job worker-based vs Camunda user task) you use in your processes, you need to run either the Tasklist or Zeebe client to run operations on task. Task, form, and variable retrieval happens via the API. Learn more about the differences of the task implementation types in the [migration guide for Camunda user tasks](/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md). :::tip Starting a new project? Use Camunda user tasks to simplify your implementation. @@ -72,8 +72,8 @@ style Tasklist stroke:#10c95d,color:#000 click Forms "../../forms/introduction-to-forms" click Rest "../../../tasklist-api-rest/tasklist-api-rest-overview" -click Job "../../../migration-manuals/migrate-to-zeebe-user-tasks" -click ZeebeTasks "../../../migration-manuals/migrate-to-zeebe-user-tasks" +click Job "../../../migration-manuals/migrate-to-camunda-user-tasks" +click ZeebeTasks "../../../migration-manuals/migrate-to-camunda-user-tasks" click ZeebeRest "../../../zeebe-api-rest/zeebe-api-rest-overview" ``` diff --git a/docs/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md b/docs/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md similarity index 99% rename from docs/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md rename to docs/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md index cba59ddf08..cf678173bf 100644 --- a/docs/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md +++ b/docs/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md @@ -1,5 +1,5 @@ --- -id: migrate-to-zeebe-user-tasks +id: migrate-to-camunda-user-tasks title: Migrate to Camunda user tasks description: "Learn how to migrate job worker-based user tasks to Camunda user tasks." --- diff --git a/docs/components/modeler/bpmn/user-tasks/user-tasks.md b/docs/components/modeler/bpmn/user-tasks/user-tasks.md index 9c9ec24844..aeb45d6258 100644 --- a/docs/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/docs/components/modeler/bpmn/user-tasks/user-tasks.md @@ -168,7 +168,7 @@ To define a Job worker implementation for a user task, simply remove the `zeebe: - Model semantics: The interpretation and purpose in the process model differ. :::info -The Job worker implementation for user tasks is deprecated. We recommend using [Camunda user tasks](#camunda-user-tasks) instead for enhanced functionality and adherence to best practices. For a detailed comparison of task implementation types and guidance on migrating to Camunda user tasks, see the [migration guide](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md). +The Job worker implementation for user tasks is deprecated. We recommend using [Camunda user tasks](#camunda-user-tasks) instead for enhanced functionality and adherence to best practices. For a detailed comparison of task implementation types and guidance on migrating to Camunda user tasks, see the [migration guide](/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md). ::: When a process instance reaches a user task with a Job worker implementation: diff --git a/docs/reference/announcements/870.md b/docs/reference/announcements/870.md index ddf2710228..dc6d960d5b 100644 --- a/docs/reference/announcements/870.md +++ b/docs/reference/announcements/870.md @@ -37,8 +37,8 @@ The deprecation process for the [Operate](/apis-tools/operate-api/overview.md) a As **job-worker** user tasks will be deprecated with Camunda 8.9, Camunda recommends using **Camunda user tasks** (formerly known as **Zeebe user tasks**) in your process definitions. Note that you may still see references of **Zeebe user tasks** in your XML, but this is the same thing as Camunda user tasks. -- Version 8.7, 8.8: **job-worker** user tasks are available for querying, but Camunda Modeler automatically applies the **Camunda user task** and shows a warning message for each job worker user task. -- Version 8.9: **job-worker** user tasks will be deprecated. With Camunda 8.9+, customers can use the **job-worker** implementation of user tasks as standard jobs with headers to enable open architecture and composable solutions. +- Version 8.7, 8.8: **Job-worker** user tasks are available for querying, but Camunda Modeler automatically applies the **Camunda user task** and shows a warning message for each job worker user task. +- Version 8.9: **Job-worker** user tasks will be deprecated. With Camunda 8.9+, customers can use the **job-worker** implementation of user tasks as standard jobs with headers to enable open architecture and composable solutions. ### Deprecated: Zeebe gRPC API endpoints diff --git a/sidebars.js b/sidebars.js index 14ac338fc9..472ac8d9e8 100644 --- a/sidebars.js +++ b/sidebars.js @@ -888,7 +888,7 @@ module.exports = { }, { "Migration manuals": [ - "apis-tools/migration-manuals/migrate-to-zeebe-user-tasks", + "apis-tools/migration-manuals/migrate-to-camunda-user-tasks", "apis-tools/migration-manuals/migrate-to-camunda-api", ], }, diff --git a/static/.htaccess b/static/.htaccess index 5455aece44..a16a2c6845 100644 --- a/static/.htaccess +++ b/static/.htaccess @@ -96,7 +96,7 @@ RewriteRule ^docs/reference/bpmn-processes/?(.*)$ /docs/components/modeler/bpmn/ #--------------------------------------------------------------------------------- # Move migrating to Zeebe user tasks -RewriteRule ^docs/next/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks/?$ /docs/next/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks/$1 [R=301,L] +RewriteRule ^docs/next/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks/?$ /docs/next/apis-tools/migration-manuals/migrate-to-camunda-user-tasks/$1 [R=301,L] RewriteRule ^docs/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks/?$ /docs/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks/$1 [R=301,L] RewriteRule ^docs/8.6/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks/?$ /docs/8.6/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks/$1 [R=301,L] From 87b6cedff5e399ccda50e4ca624da01323bdef6e Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Fri, 13 Dec 2024 11:56:09 -0500 Subject: [PATCH 08/10] add to glossary --- docs/reference/glossary.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/reference/glossary.md b/docs/reference/glossary.md index 486cd1eb27..85445d0f77 100644 --- a/docs/reference/glossary.md +++ b/docs/reference/glossary.md @@ -262,7 +262,12 @@ This way, a Camunda workflow can receive messages from an external system or ser A user task is used to model work that needs to be done by a human and is assisted by a business process execution engine or software application. This differs from [manual tasks](/components/modeler/bpmn/manual-tasks/manual-tasks.md), which are not assisted by external tooling. +With 8.7, Camunda offers job worker-based user tasks managed by Camunda, also known as Camunda user tasks (and formerly known as Zeebe user tasks). Note that you may still see references of **Zeebe user tasks** in your XML, but this is the same thing as Camunda user tasks. + +Camunda recommends using Camunda user tasks in your process definitions. With 8.7, **job-worker** user tasks are available for querying, but Camunda Modeler automatically applies the **Camunda user task** and shows a warning message for each job worker user task. + - [User tasks](/components/modeler/bpmn/user-tasks/user-tasks.md) +- [Migrate to Camunda user tasks](/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md) ### Webhook Connector From 8e900731ffdff9c4528a3cc17dc351d00a04f0ad Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Fri, 13 Dec 2024 11:57:42 -0500 Subject: [PATCH 09/10] adjust link --- docs/apis-tools/zeebe-api-rest/tutorial.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/apis-tools/zeebe-api-rest/tutorial.md b/docs/apis-tools/zeebe-api-rest/tutorial.md index 1c78932f0a..dd5a9298c3 100644 --- a/docs/apis-tools/zeebe-api-rest/tutorial.md +++ b/docs/apis-tools/zeebe-api-rest/tutorial.md @@ -41,7 +41,7 @@ In this tutorial, we will execute arguments to assign and unassign a user to and ## Assign a Camunda user task (POST) :::note -In this tutorial, you will capture a **Camunda user task** ID to assign and unassign users in this API. Camunda 8.5 introduced this new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type, and these Camunda user tasks are different from job worker-based user tasks. See more details on task type differences in the [migrating to Camunda user tasks documentation](/apis-tools/migration-manuals/migrate-to-Camunda-user-tasks.md#task-type-differences). +In this tutorial, you will capture a **Camunda user task** ID to assign and unassign users in this API. Camunda 8.5 introduced this new [user task](/components/modeler/bpmn/user-tasks/user-tasks.md) implementation type, and these Camunda user tasks are different from job worker-based user tasks. See more details on task type differences in the [migrating to Camunda user tasks documentation](/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md#task-type-differences). ::: First, let's script an API call to assign a Camunda user task. From 539684bd017cf4f767c50eca257a7cf78e408485 Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Fri, 13 Dec 2024 12:09:28 -0500 Subject: [PATCH 10/10] fix link --- docs/reference/release-notes/850.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/reference/release-notes/850.md b/docs/reference/release-notes/850.md index d514f55adc..23e61dd0d9 100644 --- a/docs/reference/release-notes/850.md +++ b/docs/reference/release-notes/850.md @@ -108,7 +108,7 @@ The first iteration of this feature brings back existing features from Camunda 7 -The first step to offer an intuitive and consistent experience via a single, [unified Camunda 8 REST API](https://camunda.com/blog/2024/03/streamlining-camunda-apis-zeebe-rest-api/) is to provide the Zeebe REST API. With this release, developers can use the Zeebe REST API to manage [Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md), enabling immediate task state changes. The Zeebe REST API includes support for Identity authentication and multi-tenancy, ensuring parity to the Zeebe gRPC API. +The first step to offer an intuitive and consistent experience via a single, [unified Camunda 8 REST API](https://camunda.com/blog/2024/03/streamlining-camunda-apis-zeebe-rest-api/) is to provide the Zeebe REST API. With this release, developers can use the Zeebe REST API to manage [Zeebe user tasks](/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md), enabling immediate task state changes. The Zeebe REST API includes support for Identity authentication and multi-tenancy, ensuring parity to the Zeebe gRPC API. ### Refactoring suggestions Modeler