From 797e5ce71c92e73f79b2050a5c78efe86c2709c4 Mon Sep 17 00:00:00 2001 From: christinaausley <84338309+christinaausley@users.noreply.github.com> Date: Wed, 5 Mar 2025 16:46:28 +0100 Subject: [PATCH] adjust zbctl references in versioned docs (#5131) * technical review of zbctl replacement * flag remaining zbctl references * remove admonition * add admonition to next * backport to 8.6 and 8.7 --- .../cli-client/cli-get-started.md | 6 + .../community-clients/cli-client/index.md | 6 + .../go-client/go-get-started.md | 8 +- .../community-clients/go-client/index.md | 6 + .../community-clients/go-client/job-worker.md | 6 + .../desktop-modeler/troubleshooting.md | 6 +- .../resolve-incidents-update-variables.md | 2 +- .../deploy/amazon/amazon-eks/eks-helm.md | 2 +- .../components/concepts/messages.md | 55 +++- .../concepts/process-instance-creation.md | 98 ++++--- .../common-pitfalls.md | 2 +- .../desktop-modeler/troubleshooting.md | 6 +- .../resolve-incidents-update-variables.md | 4 + .../integrate-web-modeler-in-ci-cd.md | 6 +- .../concepts/multi-region/dual-region.md | 20 +- .../troubleshoot-zeebe-connection.md | 2 +- .../multi-region/dual-region-ops.md | 239 ----------------- .../deploy/amazon/amazon-eks/dual-region.md | 84 ------ .../deploy/amazon/amazon-eks/eks-helm.md | 131 +--------- .../deploy/local/local-kubernetes-cluster.md | 2 +- .../self-managed/setup/deploy/local/manual.md | 48 ++-- .../accessing-components-without-ingress.md | 6 +- .../operations/cluster-scaling.md | 6 +- .../security/secure-client-communication.md | 6 +- .../cli-client/cli-get-started.md | 6 + .../community-clients/cli-client/index.md | 6 + .../go-client/go-get-started.md | 6 + .../community-clients/go-client/index.md | 6 + .../community-clients/go-client/job-worker.md | 6 + .../components/concepts/messages.md | 53 +++- .../concepts/process-instance-creation.md | 98 ++++--- .../common-pitfalls.md | 2 +- .../desktop-modeler/troubleshooting.md | 6 +- .../resolve-incidents-update-variables.md | 4 + .../integrate-web-modeler-in-ci-cd.md | 8 +- .../concepts/multi-region/dual-region.md | 20 +- .../troubleshoot-zeebe-connection.md | 2 +- .../multi-region/dual-region-ops.md | 245 +----------------- .../deploy/amazon/amazon-eks/dual-region.md | 84 ------ .../deploy/amazon/amazon-eks/eks-helm.md | 131 +--------- .../deploy/local/local-kubernetes-cluster.md | 2 +- .../self-managed/setup/deploy/local/manual.md | 48 ++-- .../setup/deploy/openshift/dual-region.md | 30 --- .../accessing-components-without-ingress.md | 6 +- .../operations/cluster-scaling.md | 6 +- .../security/secure-client-communication.md | 6 +- 46 files changed, 412 insertions(+), 1126 deletions(-) diff --git a/docs/apis-tools/community-clients/cli-client/cli-get-started.md b/docs/apis-tools/community-clients/cli-client/cli-get-started.md index 3cdc65abac5..a857db31817 100644 --- a/docs/apis-tools/community-clients/cli-client/cli-get-started.md +++ b/docs/apis-tools/community-clients/cli-client/cli-get-started.md @@ -5,6 +5,12 @@ sidebar_label: "Getting started with the CLI client" description: "Get started with this tutorial that shows you how to interact with Camunda 8 using the community-supported CLI client and command line interface `zbctl`." --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + In this tutorial, you will learn how to use the [community-supported](https://github.com/camunda-community-hub) `zbctl` CLI client to interact with Camunda 8. :::note diff --git a/docs/apis-tools/community-clients/cli-client/index.md b/docs/apis-tools/community-clients/cli-client/index.md index 43651b355f1..ff7045dc45d 100644 --- a/docs/apis-tools/community-clients/cli-client/index.md +++ b/docs/apis-tools/community-clients/cli-client/index.md @@ -5,6 +5,12 @@ sidebar_label: "Quick reference" description: "Learn how to use the community-supported CLI client and command line interface `zbctl` to interact with Camunda 8 and test a connection." --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + You can use the [community-supported](https://github.com/camunda-community-hub) `zbctl` command line interface to interact with Camunda 8. After installation, a connection can be tested immediately. diff --git a/docs/apis-tools/community-clients/go-client/go-get-started.md b/docs/apis-tools/community-clients/go-client/go-get-started.md index 0b45f4c99ff..ce8dc406843 100644 --- a/docs/apis-tools/community-clients/go-client/go-get-started.md +++ b/docs/apis-tools/community-clients/go-client/go-get-started.md @@ -8,7 +8,13 @@ description: "Get started with this tutorial that shows you how to interact with import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; -In this tutorial, you will learn how to use the the [community-supported](https://github.com/camunda-community-hub) Go client in a Go application to interact with Camunda 8. +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + +In this tutorial, you will learn how to use the [community-supported](https://github.com/camunda-community-hub) Go client in a Go application to interact with Camunda 8. You can find a complete example on [GitHub](https://github.com/camunda/camunda-platform-get-started/tree/main/go). diff --git a/docs/apis-tools/community-clients/go-client/index.md b/docs/apis-tools/community-clients/go-client/index.md index a56913e1ffd..68bfa24bbd0 100644 --- a/docs/apis-tools/community-clients/go-client/index.md +++ b/docs/apis-tools/community-clients/go-client/index.md @@ -5,6 +5,12 @@ sidebar_label: "Quick reference" description: "Instantiate the client by passing in the address of the cluster you want to connect to in a Go application to interact with Camunda 8." --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + You can use the [community-supported](https://github.com/camunda-community-hub) Zeebe Go client library to interact with Camunda 8. ## Dependencies diff --git a/docs/apis-tools/community-clients/go-client/job-worker.md b/docs/apis-tools/community-clients/go-client/job-worker.md index 8d98b60532e..1100cccbc5f 100644 --- a/docs/apis-tools/community-clients/go-client/job-worker.md +++ b/docs/apis-tools/community-clients/go-client/job-worker.md @@ -5,6 +5,12 @@ description: "Let's take a deeper look at job workers to handle jobs." keywords: ["backpressure", "back-pressure", "back pressure"] --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + The Go client provides a job worker that handles both polling and streaming for available jobs. This allows you to focus on writing code to handle the activated jobs. On `Open`, the job worker waits `PollInterval` milliseconds and then polls for `MaxJobsActive` jobs. It then continues with the following schedule: diff --git a/docs/components/modeler/desktop-modeler/troubleshooting.md b/docs/components/modeler/desktop-modeler/troubleshooting.md index 81e854a9464..62a051613ce 100644 --- a/docs/components/modeler/desktop-modeler/troubleshooting.md +++ b/docs/components/modeler/desktop-modeler/troubleshooting.md @@ -54,11 +54,11 @@ To produce logging output, you can also run Desktop Modeler from the command lin You try to connect (i.e., to deploy) to a remote Zeebe instance, and Desktop Modeler tells you it "cannot find a running Zeebe." -To resolve this issue, check if you can connect to Zeebe through another client, i.e., community-supported[`zbctl`](/apis-tools/community-clients/cli-client/index.md). If that works, [further debug your Zeebe connection](#debug-zeebe-connection-issues). If that does not work, resolve the [general connection issue](#resolve-a-general-zeebe-connection-issue) first. +To resolve this issue, check if you can connect to Zeebe through another client, for example, community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md). If that works, [further debug your Zeebe connection](#debug-zeebe-connection-issues). If that does not work, resolve the [general connection issue](#resolve-a-general-zeebe-connection-issue) first. ## Resolve a general Zeebe connection issue -You try to connect to Zeebe from both Desktop Modeler _and_ community-supported[`zbctl`](/apis-tools/community-clients/cli-client/index.md), and neither of them works. General connection failures can have a couple of reasons: +You try to connect to Zeebe from both Desktop Modeler _and_ community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md), and neither of them works. General connection failures can have a couple of reasons: ### The (remote) Zeebe instance is not reachable @@ -72,7 +72,7 @@ Secure connections to Zeebe require [HTTP/2 over TLS with protocol negotiation v ## Debug Zeebe connection issues -You can connect to Zeebe via community-supported[`zbctl`](/apis-tools/community-clients/cli-client/index.md) or another API client. However, connecting through Desktop Modeler fails. +You can connect to Zeebe via community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md) or another API client. However, connecting through Desktop Modeler fails. ### Secure connection to Zeebe fails diff --git a/docs/components/operate/userguide/resolve-incidents-update-variables.md b/docs/components/operate/userguide/resolve-incidents-update-variables.md index 46209f4e810..3324790d9cc 100644 --- a/docs/components/operate/userguide/resolve-incidents-update-variables.md +++ b/docs/components/operate/userguide/resolve-incidents-update-variables.md @@ -8,7 +8,7 @@ import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; :::note -This guide includes steps with community-supported[`zbctl`](/apis-tools/community-clients/cli-client/index.md). +This guide includes steps with community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md). ::: Every process instance created for the [`order-process.bpmn`](/bpmn/operate/order-process.bpmn) process model requires an `orderValue` so the XOR gateway evaluation will happen properly. diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md index 98546da1333..811d4236fb6 100644 --- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md +++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md @@ -20,7 +20,7 @@ Lastly you'll verify that the connection to your Self-Managed Camunda 8 environm - [kubectl (1.30+)](https://kubernetes.io/docs/tasks/tools/#kubectl) to interact with the cluster. - [jq (1.7+)](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.gnu.org/software/gettext/manual/html_node/envsubst-Invocation.html) to generate manifests. -- (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via [zbctl](/apis-tools/community-clients/cli-client/index.md) or [Camunda Modeler](https://camunda.com/download/modeler/). +- (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via community-supported [zbctl](/apis-tools/community-clients/cli-client/index.md) or [Camunda Modeler](https://camunda.com/download/modeler/). - A namespace to host the Camunda Platform, in this guide we will reference `camunda` as the target namespace. ### Considerations diff --git a/versioned_docs/version-8.6/components/concepts/messages.md b/versioned_docs/version-8.6/components/concepts/messages.md index 37c57a5c728..16c48853c5c 100644 --- a/versioned_docs/version-8.6/components/concepts/messages.md +++ b/versioned_docs/version-8.6/components/concepts/messages.md @@ -12,20 +12,41 @@ A message is not sent to a process instance directly. Instead, the message corre ![Message Correlation](assets/message-correlation.png) -A subscription is opened when a process instance awaits a message; for example, when entering a message catch event. The message name is defined either statically in the process (e.g. `Money collected`) or dynamically as an expression. The correlation key is defined dynamically as an expression (e.g. `= orderId`). The expressions are evaluated on activating the message catch event. The results of the evaluations are used as message name and as correlation key of the subscription (e.g. `"order-123"`). +A subscription is opened when a process instance awaits a message; for example, when entering a message catch event. The message name is defined either statically in the process (e.g. `Money collected`) or dynamically as an expression. The correlation key is defined dynamically as an expression (for example, `= orderId`). The expressions are evaluated on activating the message catch event. The results of the evaluations are used as message name and as correlation key of the subscription (e.g. `"order-123"`). When a message is published and the message name and correlation key match to a subscription, the message is correlated to the corresponding process instance. If no proper subscription is opened, the message is discarded. A subscription is closed when the corresponding element (e.g. the message catch event), or its scope is left. After a subscription is opened, it is not updated (for example, when the referenced process instance variable is changed.)
- Publish message via zbctl + Publish message via Camunda 8 REST API

``` -zbctl publish message "Money collected" --correlationKey "order-123" +curl -L 'http://localhost:8080/v2/messages/publication' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "name": "Money collected", + "correlationKey": "order-123" +}' ``` +See the [API reference for publish message](/apis-tools/camunda-api-rest/specifications/publish-a-message.api.mdx) for more information, including additional request fields and code samples. +When you require immediate feedback if the message was correlated to an open subscription, you can use `Correlate message` via Camunda 8 REST API. If correlation is successful it will return the first process instance key the message correlated with. + +``` +curl -L 'http://localhost:8080/v2/messages/correlation' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ +"name": "Money collected", +"correlationKey": "order-123" +}' +``` + +See the [API reference for correlate message](/apis-tools/camunda-api-rest/specifications/correlate-a-message.api.mdx) for more information, including additional request fields and code samples. +

@@ -40,13 +61,22 @@ When a subscription is opened, it polls the buffer for a proper message. If a pr The buffering of a message is disabled when its TTL is set to zero. If no proper subscription is open, the message is discarded.
- Publish message with TTL via zbctl + Publish message with TTL via Camunda 8 REST API

``` -zbctl publish message "Money collected" --correlationKey "order-123" --ttl 1h +curl -L 'http://localhost:8080/v2/messages/publication' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "name": "Money collected", + "correlationKey": "order-123", + "timeToLive": 3600000 +}' ``` +See the [API reference for publish message](/apis-tools/camunda-api-rest/specifications/publish-a-message.api.mdx) for more information, including additional request fields and code samples. +

@@ -67,13 +97,22 @@ A message is rejected and not correlated if a message with the same name, the sa The uniqueness check is disabled when no message ID is set.
- Publish message with ID via zbctl + Publish message with message ID via Camunda 8 REST API

``` -zbctl publish message "Money collected" --correlationKey "order-123" --messageId "tracking-12345" +curl -L 'http://localhost:8080/v2/messages/publication' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "name": "Money collected", + "correlationKey": "order-123", + "messageId": "tracking-12345" +}' ``` +See the [API reference for publish message](/apis-tools/camunda-api-rest/specifications/publish-a-message.api.mdx) for more information, including additional request fields and code samples. +

@@ -81,7 +120,7 @@ zbctl publish message "Money collected" --correlationKey "order-123" --messageId By combining the principles of message correlation, message uniqueness, and message buffering, very different behaviors can be achieved. Please note that a message name is mandatory, so it is omitted from the table. -| Correlation key | Message Id | Time to live | Receiver type | Behavior | +| Correlation key | Message ID | Time to live | Receiver type | Behavior | | --------------- | ---------- | ------------ | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | set | not set | set to 0 | Start event | A new instance is started if no instance with the correlation key set at start is active, see [single instance](./#single-instance). | | set | not set | set to 0 | Intermediate event | The message is correlated if a matching subscription is active. | diff --git a/versioned_docs/version-8.6/components/concepts/process-instance-creation.md b/versioned_docs/version-8.6/components/concepts/process-instance-creation.md index 04f1d5369c8..af964cf47f1 100644 --- a/versioned_docs/version-8.6/components/concepts/process-instance-creation.md +++ b/versioned_docs/version-8.6/components/concepts/process-instance-creation.md @@ -27,28 +27,34 @@ This command creates a new process instance and immediately responds with the pr ![create-process](assets/create-process.png)
- Code example -

-Create a process instance: +

Create a process instance via Camunda 8 REST API +

``` -zbctl create instance "order-process" +curl -L 'http://localhost:8080/v2/process-instances' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "processDefinitionKey": "2251799813685249”, + "processDefinitionVersion": 1 +}' ``` Response: ``` { - "processKey": 2251799813685249, - "bpmnProcessId": "order-process", - "version": 1, - "processInstanceKey": 2251799813686019 + "processDefinitionId": "order-process", + "processDefinitionVersion": 1, + "processDefinitionKey": "2251799813685249", + "processInstanceKey": "2251799813686019" } - ``` -

-
+See the [API reference for process instance creation](/apis-tools/camunda-api-rest/specifications/create-process-instance.api.mdx) for more information, including additional request fields and code samples. + +

+ ### Create and await results @@ -67,32 +73,37 @@ When the client resends the command, it creates a new process instance. :::
- Code example -

-Create a process instance and await results: +

Create a process instance and await results via Camunda 8 REST API +

``` -zbctl create instance "order-process" --withResult --variables '{"orderId": "1234"}' +curl -L 'http://localhost:8080/v2/process-instances' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "processDefinitionId": "order-process”, + "processDefinitionVersion": 1, + "awaitCompletion": true, + "variables": { "orderId": "1234" } +}' ``` Response: -:::note -The variables in the response depend on the process. -::: - ``` { - "processKey": 2251799813685249, - "bpmnProcessId": "order-process", - "version": 1, - "processInstanceKey": 2251799813686045, - "variables": "{\"orderId\":\"1234\"}" + "processDefinitionId": "order-process", + "processDefinitionVersion": 1, + "variables": { "orderId": "1234" } + "processDefinitionKey": "2251799813685249", + "processInstanceKey": "2251799813686019", } ``` -

-
+See the [API reference for process instance creation](/apis-tools/camunda-api-rest/specifications/create-process-instance.api.mdx) for more information, including additional request fields and code samples. + +

+ Failure scenarios applicable to other commands are applicable to this command as well. Clients may not get a response in the following cases even if the process execution is completed successfully: @@ -123,22 +134,29 @@ Start instructions have the same [limitations as process instance modification]( Start instructions are supported for both `CreateProcessInstance` commands.
- Code example -

-Create a process instance starting before the 'ship_parcel' element: - -```java -client.newCreateInstanceCommand() - .bpmnProcessId("order-process") - .latestVersion() - .variables(Map.of("orderId", "1234")) - .startBeforeElement("ship_parcel") - .send() - .join(); +

Create a process instance and start at a user-defined element +

+ ``` +curl -L 'http://localhost:8080/v2/process-instances' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "processDefinitionId": "order-process”, + "processDefinitionVersion": -1, + "startInstructions": [ + { + "elementId": "ship_parcel" + } + ], + "variables": { "orderId": "1234" } +}' +``` + +See the [API reference for process instance creation](/apis-tools/camunda-api-rest/specifications/create-process-instance.api.mdx) for more information, including additional request fields and code samples. -

-
+

+ ## Events diff --git a/versioned_docs/version-8.6/components/console/console-troubleshooting/common-pitfalls.md b/versioned_docs/version-8.6/components/console/console-troubleshooting/common-pitfalls.md index 27ddde881c0..799de28a84c 100644 --- a/versioned_docs/version-8.6/components/console/console-troubleshooting/common-pitfalls.md +++ b/versioned_docs/version-8.6/components/console/console-troubleshooting/common-pitfalls.md @@ -15,5 +15,5 @@ Let's take a closer look at common issues and resolutions within Console. ## I cannot connect to Zeebe - Check if your [API client](../manage-clusters/manage-api-clients.md) has the necessary rights. To interact with Zeebe, the **Scope** `Zeebe` must be set. -- Check if your credentials are configured correctly. There is a CLI tool that allows you to check the status: [`zbctl`](https://www.npmjs.com/package/zbctl). With the command `zbctl status`, you can read the topology. If this command works, the connection can be established. +- Check if your credentials are configured correctly. There is a community-supported CLI tool that allows you to check the status: [`zbctl`](https://www.npmjs.com/package/zbctl). With the command `zbctl status`, you can read the topology. If this command works, the connection can be established. - Check if your cluster is **Healthy**: A Zeebe cluster may be temporarily unavailable. To check if your cluster is healthy, navigate to the **Clusters** tab in the top navigation. Click on the cluster to view its details for a closer view of the status over all components (Zeebe, Operate, Tasklist, Optimize). diff --git a/versioned_docs/version-8.6/components/modeler/desktop-modeler/troubleshooting.md b/versioned_docs/version-8.6/components/modeler/desktop-modeler/troubleshooting.md index 49868dcb771..62a051613ce 100644 --- a/versioned_docs/version-8.6/components/modeler/desktop-modeler/troubleshooting.md +++ b/versioned_docs/version-8.6/components/modeler/desktop-modeler/troubleshooting.md @@ -54,11 +54,11 @@ To produce logging output, you can also run Desktop Modeler from the command lin You try to connect (i.e., to deploy) to a remote Zeebe instance, and Desktop Modeler tells you it "cannot find a running Zeebe." -To resolve this issue, check if you can connect to Zeebe through another client, i.e., [`zbctl`](/apis-tools/community-clients/cli-client/index.md). If that works, [further debug your Zeebe connection](#debug-zeebe-connection-issues). If that does not work, resolve the [general connection issue](#resolve-a-general-zeebe-connection-issue) first. +To resolve this issue, check if you can connect to Zeebe through another client, for example, community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md). If that works, [further debug your Zeebe connection](#debug-zeebe-connection-issues). If that does not work, resolve the [general connection issue](#resolve-a-general-zeebe-connection-issue) first. ## Resolve a general Zeebe connection issue -You try to connect to Zeebe from both Desktop Modeler _and_ [`zbctl`](/apis-tools/community-clients/cli-client/index.md), and neither of them works. General connection failures can have a couple of reasons: +You try to connect to Zeebe from both Desktop Modeler _and_ community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md), and neither of them works. General connection failures can have a couple of reasons: ### The (remote) Zeebe instance is not reachable @@ -72,7 +72,7 @@ Secure connections to Zeebe require [HTTP/2 over TLS with protocol negotiation v ## Debug Zeebe connection issues -You can connect to Zeebe via [`zbctl`](/apis-tools/community-clients/cli-client/index.md) or another API client. However, connecting through Desktop Modeler fails. +You can connect to Zeebe via community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md) or another API client. However, connecting through Desktop Modeler fails. ### Secure connection to Zeebe fails diff --git a/versioned_docs/version-8.6/components/operate/userguide/resolve-incidents-update-variables.md b/versioned_docs/version-8.6/components/operate/userguide/resolve-incidents-update-variables.md index bae1e13b90c..3324790d9cc 100644 --- a/versioned_docs/version-8.6/components/operate/userguide/resolve-incidents-update-variables.md +++ b/versioned_docs/version-8.6/components/operate/userguide/resolve-incidents-update-variables.md @@ -7,6 +7,10 @@ description: "Let's examine variable and incidents." import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; +:::note +This guide includes steps with community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md). +::: + Every process instance created for the [`order-process.bpmn`](/bpmn/operate/order-process.bpmn) process model requires an `orderValue` so the XOR gateway evaluation will happen properly. Let’s look at a case where `orderValue` is present and was set as a string, but our `order-process.bpmn` model required an integer to properly evaluate the `orderValue` and route the instance. diff --git a/versioned_docs/version-8.6/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md b/versioned_docs/version-8.6/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md index 1c1a149b441..99d3c1434e5 100644 --- a/versioned_docs/version-8.6/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md +++ b/versioned_docs/version-8.6/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md @@ -178,7 +178,7 @@ In the build stage, deploy your process or project to a cluster or embedded engi For GitLab users, consider using [GitLab Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) to provide preview environments. ::: -Deploy resources using the [`zbctl` CLI](/apis-tools/community-clients/cli-client/index.md) in this pipeline step, compatible with both SaaS and Self-Managed clusters. Alternately, utilize the [Java](/apis-tools/java-client/index.md) client library or any [community-built alternatives](/apis-tools/community-clients/index.md). +Deploy resources using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) in this pipeline step, compatible with both SaaS and Self-Managed clusters. Alternately, utilize the [Java](/apis-tools/java-client/index.md) client library or any [community-built alternatives](/apis-tools/community-clients/index.md). :::info Feature branches and Web Modeler installations To maintain a single source of truth, avoid multiple Web Modeler instances for different feature branches. Instead, maintain a single Web Modeler installation for all environments, utilizing milestones to signify versioning and pipeline stages. Feature branches can be managed by cloning and merging files or projects, ensuring synchronization using VCS. @@ -206,7 +206,7 @@ To retrieve the actual file `content`, iterate over the response and fetch it vi If you are running Connectors in your process or application, you need to deploy the runtimes as well. Parse the process XML for `zeebe:taskDefinition` bindings to identify the necessary runtimes (in addition to job workers). To learn how to deploy Connector runtimes, read more [here](/self-managed/connectors-deployment/install-and-start.md) for Self-Managed, or [here](/components/connectors/custom-built-connectors/connector-sdk.md#runtime-environments) for SaaS. -Deploy resources in this pipeline step using the [`zbctl` CLI](/apis-tools/community-clients/cli-client/index.md), compatible with both SaaS and Self-Managed clusters. Alternatively, utilize the Java or Go client library or any community-built alternatives. +Deploy resources in this pipeline step using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md), compatible with both SaaS and Self-Managed clusters. Alternatively, utilize the Java or Go client library or any community-built alternatives. #### Add environment variables via secrets @@ -257,7 +257,7 @@ In case you use an embedded Zeebe engine, or want to provide a lightweight, focu ### Publish stage -Push approved changes to staging or production by deploying them to the respective clusters. You can use the [`zbctl` CLI](/apis-tools/community-clients/cli-client/index.md) to deploy via your pipeline, which works both for a SaaS or Self-Managed cluster. Deployments work slightly different on SaaS and Self-Managed, since there are differences in the cluster connection. Read more about deployments [here](/apis-tools/working-with-apis-tools.md#deploy-processes-start-process-instances-and-more-using-zeebe-client-libraries). +Push approved changes to staging or production by deploying them to the respective clusters. You can use the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) to deploy via your pipeline, which works both for a SaaS or Self-Managed cluster. Deployments work slightly different on SaaS and Self-Managed, since there are differences in the cluster connection. Read more about deployments [here](/apis-tools/working-with-apis-tools.md#deploy-processes-start-process-instances-and-more-using-zeebe-client-libraries). #### Define resource authorizations diff --git a/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md b/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md index 3e85a365a9b..30a381dd823 100644 --- a/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md +++ b/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md @@ -111,16 +111,16 @@ The following Zeebe brokers and replication configuration is supported: ### Camunda 8 dual-region limitations -| **Aspect** | **Details** | -| :----------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Installation methods |

| -| Camunda Platform Configuration |

The overall Camunda platform is **active-passive**

| -| Identity Support | Identity, including multi-tenancy and Role-Based Access Control (RBAC), is currently unavailable in this setup. | -| Optimize Support | Not supported (requires Identity). | -| Connectors Deployment | Connectors can be deployed in a dual-region setup, but attention to [idempotency](../../../components/connectors/use-connectors/inbound.md#creating-the-connector-event) is required to avoid event duplication. In a dual-region setup, you'll have two connector deployments and using message idempotency is of importance to not duplicate events. | -| Connectors | If you are running Connectors and have a process with an inbound connector deployed in a dual-region setup, consider the following: | -| Zeebe Cluster Scaling | Not supported. | -| Web Modeler | Web Modeler is a standalone component that is not covered in this guide. Modelling applications can operate independently outside of the automation clusters. | +| **Aspect** | **Details** | +| :----------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Installation methods |

| +| Camunda Platform Configuration |

The overall Camunda platform is **active-passive**

| +| Identity Support | Identity, including multi-tenancy and Role-Based Access Control (RBAC), is currently unavailable in this setup. | +| Optimize Support | Not supported (requires Identity). | +| Connectors Deployment | Connectors can be deployed in a dual-region setup, but attention to [idempotency](../../../components/connectors/use-connectors/inbound.md#creating-the-connector-event) is required to avoid event duplication. In a dual-region setup, you'll have two connector deployments and using message idempotency is of importance to not duplicate events. | +| Connectors | If you are running Connectors and have a process with an inbound connector deployed in a dual-region setup, consider the following: | +| Zeebe Cluster Scaling | Not supported. | +| Web Modeler | Web Modeler is a standalone component that is not covered in this guide. Modelling applications can operate independently outside of the automation clusters. | ### Infrastructure and deployment platform considerations diff --git a/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md b/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md index 0e6313d149c..7838aae910c 100644 --- a/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md +++ b/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md @@ -6,7 +6,7 @@ sidebar_label: "Zeebe connection" You try to connect (i.e., to deploy) to a remote Zeebe cluster and Web Modeler reports an error. -To resolve this issue, check if you can connect to Zeebe through another client, i.e., [`zbctl`](/apis-tools/community-clients/cli-client/index.md). +To resolve this issue, check if you can connect to Zeebe through another client. If that doesn't work, resolve the general connection issue first (see [the platform deployment troubleshooting section](/self-managed/operational-guides/troubleshooting/troubleshooting.md), for example.) If that works, further debug your Zeebe connection with the help of the information stated below. Enabling [debug logging in `modeler-restapi`](#how-can-i-debug-log-grpc--zeebe-communication) may also help to understand the issue. diff --git a/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md b/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md index 01a436bf1e9..8b68c67b90d 100644 --- a/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md +++ b/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md @@ -54,7 +54,6 @@ Running a dual-region configuration requires users to detect and manage any regi - In that guide, we're showcasing Kubernetes dual-region installation, based on the following tools: - [Helm (3.x)](https://helm.sh/docs/intro/install/) for installing and upgrading the [Camunda Helm chart](https://artifacthub.io/packages/helm/camunda/camunda-platform). - [Kubectl (1.30.x)](https://kubernetes.io/docs/tasks/tools/#kubectl) to interact with the Kubernetes cluster. -- (deprecated) [zbctl](/apis-tools/community-clients/cli-client/index.md) to interact with the Zeebe cluster. - `cURL` or similar to interact with the REST API. ## Terminology @@ -153,9 +152,6 @@ The following alternatives to port-forwarding are possible: In our example, we went with port-forwarding to a localhost, but other alternatives can also be used. - - - 1. Use the [REST API](../../../apis-tools/camunda-api-rest/camunda-api-rest-overview.md) to retrieve the list of the remaining brokers ```bash @@ -295,57 +291,6 @@ curl -L -X GET 'http://localhost:8080/v2/topology' \ - - - -1. Use the [zbctl client](/apis-tools/community-clients/cli-client/index.md) to retrieve list of remaining brokers - -```bash -kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING -zbctl status --insecure --address localhost:26500 -``` - -
- Example output - - -```bash -Cluster size: 8 -Partitions count: 8 -Replication factor: 4 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 8 : Leader, Healthy - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Leader, Healthy -``` - - -
-
-
- 2. Port-forward the service of the Zeebe Gateway to access the [management REST API](../../zeebe-deployment/configuration/gateway.md#managementserver) ```bash @@ -363,9 +308,6 @@ curl -XPOST 'http://localhost:9600/actuator/cluster/brokers?force=true' -H 'Cont Port-forwarding the Zeebe Gateway via `kubectl` and printing the topology should reveal that the cluster size has decreased to 4, partitions have been redistributed over the remaining brokers, and new leaders have been elected. - - - ```bash kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 8080:8080 -n $CAMUNDA_NAMESPACE_SURVIVING @@ -503,56 +445,6 @@ curl -L -X GET 'http://localhost:8080/v2/topology' \ - - - -```bash -kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING -zbctl status --insecure --address localhost:26500 -``` - -
- Example output - - -```bash -Cluster size: 4 -Partitions count: 8 -Replication factor: 2 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Leader, Healthy - Partition 3 : Follower, Healthy - Partition 8 : Leader, Healthy - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Leader, Healthy - Partition 5 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Leader, Healthy -``` - - -
- -
-
- You can also use the Zeebe Gateway's REST API to ensure the scaling progress has been completed. For better output readability, we use [jq](https://jqlang.github.io/jq/). ```bash @@ -730,9 +622,6 @@ It is expected that the Zeebe broker pods will not reach the "Ready" state since Port-forwarding the Zeebe Gateway via `kubectl` and printing the topology should reveal that the new Zeebe brokers are recognized but yet a full member of the Zeebe cluster. - - - ```bash kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 8080:8080 -n $CAMUNDA_NAMESPACE_SURVIVING @@ -898,64 +787,6 @@ curl -L -X GET 'http://localhost:8080/v2/topology' \ - - - -```bash -kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING -zbctl status --insecure --address localhost:26500 -``` - -
- Example Output - - -```bash -Cluster size: 4 -Partitions count: 8 -Replication factor: 2 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Leader, Healthy - Broker 1 - camunda-zeebe-0.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Leader, Healthy - Partition 3 : Leader, Healthy - Partition 8 : Follower, Healthy - Broker 3 - camunda-zeebe-1.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Leader, Healthy - Partition 5 : Leader, Healthy - Broker 5 - camunda-zeebe-2.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Leader, Healthy - Broker 7 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 -``` - - -
- -
-
- @@ -1455,76 +1286,6 @@ curl -XGET 'http://localhost:9600/actuator/cluster' | jq .lastChange -Port-forwarding the Zeebe Gateway via kubectl and printing the topology should reveal that all brokers have joined the Zeebe cluster again. - -``` -kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING -zbctl status --insecure --address localhost:26500 -``` - -
- Example Output - - -```bash -Cluster size: 8 -Partitions count: 8 -Replication factor: 4 -Gateway version: 8.6.0 -Brokers: -Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Leader, Healthy -Broker 1 - camunda-zeebe-0.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy -Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 8 : Follower, Healthy -Broker 3 - camunda-zeebe-1.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy -Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Leader, Healthy - Partition 3 : Leader, Healthy - Partition 4 : Leader, Healthy - Partition 5 : Follower, Healthy -Broker 5 - camunda-zeebe-2.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy -Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Leader, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Leader, Healthy -Broker 7 - camunda-zeebe-3.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy -``` - - -
-
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md index 0935fb22d65..5da24dc53c9 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md @@ -507,9 +507,6 @@ helm install $HELM_RELEASE_NAME camunda/camunda-platform \ 1. Open a terminal and port-forward the Zeebe Gateway via `kubectl` from one of your clusters. Zeebe is stretching over both clusters and is `active-active`, meaning it doesn't matter which Zeebe Gateway to use to interact with your Zeebe cluster. - - - ```shell kubectl --context "$CLUSTER_0" -n $CAMUNDA_NAMESPACE_0 port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 8080:8080 ``` @@ -764,84 +761,3 @@ curl -L -X GET 'http://localhost:8080/v2/topology' \ - - - - -```shell -kubectl --context "$CLUSTER_0" -n $CAMUNDA_NAMESPACE_0 port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -``` - -1. Open another terminal and use [zbctl](/apis-tools/community-clients/cli-client/index.md) to print the Zeebe cluster status: - -```shell -zbctl status --insecure --address localhost:26500 -``` - -3. Make sure that your output contains all eight brokers from the two regions: - -
- Example output - - -```shell -Cluster size: 8 -Partitions count: 8 -Replication factor: 4 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 1 - camunda-zeebe-0.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Leader, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy - Partition 8 : Follower, Healthy - Broker 3 - camunda-zeebe-1.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Leader, Healthy - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Leader, Healthy - Broker 5 - camunda-zeebe-2.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Leader, Healthy - Broker 7 - camunda-zeebe-3.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Leader, Healthy -``` - - -
- -
-
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md index 306ef0a96b7..33c30ed4625 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md @@ -20,7 +20,7 @@ Lastly you'll verify that the connection to your Self-Managed Camunda 8 environm - [kubectl (1.30+)](https://kubernetes.io/docs/tasks/tools/#kubectl) to interact with the cluster. - [jq (1.7+)](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.gnu.org/software/gettext/manual/html_node/envsubst-Invocation.html) to generate manifests. -- (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via [zbctl](/apis-tools/community-clients/cli-client/index.md) or [Camunda Modeler](https://camunda.com/download/modeler/). +- (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via community-supported [zbctl](/apis-tools/community-clients/cli-client/index.md) or [Camunda Modeler](https://camunda.com/download/modeler/). - A namespace to host the Camunda Platform, in this guide we will reference `camunda` as the target namespace. ### Considerations @@ -621,9 +621,6 @@ Console: ### Use the token - - - For a detailed guide on generating and using a token, please conduct the relevant documentation on [authenticating with the REST API](./../../../../../apis-tools/camunda-api-rest/camunda-api-rest-authentication.md?environment=self-managed). @@ -761,132 +758,6 @@ curl --header "Authorization: Bearer ${TOKEN}" "${ZEEBE_ADDRESS_REST}/v2/topolog - - - -After following the installation instructions in the [zbctl docs](/apis-tools/community-clients/cli-client/index.md), we can configure the required connectivity to check that the Zeebe cluster is reachable. - - - - -Export the following environment variables: - -```shell -export ZEEBE_ADDRESS=zeebe.$DOMAIN_NAME:443 -export ZEEBE_AUTHORIZATION_SERVER_URL=https://$DOMAIN_NAME/auth/realms/camunda-platform/protocol/openid-connect/token -export ZEEBE_TOKEN_AUDIENCE='zeebe-api' -export ZEEBE_TOKEN_SCOPE='camunda-identity' -``` - - - - -This requires to port-forward the Zeebe Gateway to be able to connect to the cluster. - -```shell -kubectl port-forward services/camunda-zeebe-gateway 26500:26500 --namespace camunda -``` - -Export the following environment variables: - -```shell -export ZEEBE_ADDRESS=localhost:26500 -export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token -export ZEEBE_TOKEN_AUDIENCE='zeebe-api' -export ZEEBE_TOKEN_SCOPE='camunda-identity' -``` - - - - - -Executing the following command will result in a successful connection to the Zeebe cluster... - -```shell -zbctl status -# or in the case of port-forwarding (without domain) -zbctl status --insecure -``` - -...and results in the following output: - -
- Example output - - -```shell -Cluster size: 3 -Partitions count: 3 -Replication factor: 3 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Broker 1 - camunda-zeebe-1.camunda-zeebe.camunda.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 2 : Leader, Healthy - Partition 3 : Follower, Healthy - Broker 2 - camunda-zeebe-2.camunda-zeebe.camunda.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy -``` - - -
- -For more advanced topics, like deploying a process or registering a worker, consult the [zbctl docs](/apis-tools/community-clients/cli-client/cli-get-started.md). - -
- - -Follow our existing [Modeler guide on deploying a diagram](/self-managed/modeler/desktop-modeler/deploy-to-self-managed.md). Below are the helper values required to be filled in Modeler: - - - - - -The following values are required for the OAuth authentication: - -- **Cluster endpoint:** `https://zeebe.$DOMAIN_NAME`, replacing `$DOMAIN_NAME` with your domain -- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application -- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application -- **OAuth Token URL:** `https://$DOMAIN_NAME/auth/realms/camunda-platform/protocol/openid-connect/token`, replacing `$DOMAIN_NAME` with your domain -- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed - - - - - -This requires port-forwarding the Zeebe Gateway to be able to connect to the cluster: - -```shell -kubectl port-forward services/camunda-zeebe-gateway 26500:26500 --namespace camunda -``` - -The following values are required for OAuth authentication: - -- **Cluster endpoint:** `http://localhost:26500` -- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application -- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application -- **OAuth Token URL:** `http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token` -- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed - - - - - -
- ## Test the installation with payment example application To test your installation with the deployment of a sample application, refer to the [installing payment example guide](../../../guides/installing-payment-example.md). diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md b/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md index ab452275685..61f10cbc8d0 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md @@ -89,7 +89,7 @@ First, port-forward each of the components. Use a separate terminal for each com ## Connecting to the workflow engine -To interact with the Camunda workflow engine via the Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe Gateway as follows: +To interact with the Camunda workflow engine via the Zeebe Gateway using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe Gateway as follows: ```sh kubectl port-forward svc/camunda-platform-zeebe-gateway 26500:26500 diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md b/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md index b24d42b708f..35aa51c3ea7 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md @@ -92,23 +92,37 @@ You’ll know Zeebe has started successfully when you see a message similar to t [exporter] [0.0.0.0:26501-zb-actors-1] INFO io.camunda.zeebe.broker.exporter.elasticsearch - Exporter opened ``` -You can test the Zeebe Gateway by asking for the cluster topology with [zbtcl](/apis-tools/community-clients/cli-client/index.md#usage): - -```shell -./bin/zbctl --insecure status -``` - -`zbctl status` should produce an output like this: - -``` -Cluster size: 1 -Partitions count: 1 -Replication factor: 1 -Gateway version: 8.1.6 -Brokers: - Broker 0 - 0.0.0.0:26501 - Version: 8.1.6 - Partition 1 : Leader, Healthy +You can test the Zeebe Gateway by asking for the cluster topology with the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md): + +``` +curl -L 'http://localhost:8080/v2/topology' \ +-H 'Accept: application/json' +``` + +Which should produce an output like this: + +```json +{ + "brokers": [ + { + "nodeId": 0, + "host": "string", + "port": 0, + "partitions": [ + { + "partitionId": 0, + "role": "leader", + "health": "healthy" + } + ], + "version": "8.8.0" + } + ], + "clusterSize": 1, + "partitionsCount": 1, + "replicationFactor": 1, + "gatewayVersion": "8.8.0" +} ``` ## Run Operate diff --git a/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md b/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md index 0051b6f00d6..24893f4ea2c 100644 --- a/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md +++ b/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md @@ -12,13 +12,13 @@ You need to keep `port-forward` running all the time to communicate with the rem ## Accessing workflow engine -To interact with Camunda workflow engine via the [Zeebe Gateway](/self-managed/zeebe-deployment/configuration/gateway.md) using [zbctl](/apis-tools/community-clients/cli-client/index.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe cluster as following: +To interact with Camunda workflow engine via [Zeebe Gateway](/self-managed/zeebe-deployment/configuration/gateway.md) using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe cluster as following: ``` kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 ``` -Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe Broker. +Now, you can connect and execute operations against your new Zeebe cluster. :::note Accessing the Zeebe cluster directly using `kubectl port-forward` is recommended for development purposes. @@ -93,7 +93,7 @@ Log in to these services using the first user `demo`/`demo` credentials. If you deploy process definitions, they will appear in the dashboard. Then, you can drill down to see your active instances. -You can deploy and create new instances using the Zeebe clients or `zbctl`. +You can deploy and create new instances using the Zeebe clients. You can also trigger **Connectors** inbound webhook, given you deployed one. You can do so with the following example: `curl -X POST -H "Content-Type: application/json" -d '{"myId": 123456, "myMessage": "Hello, world!"}' http://localhost:8088/inbound/`. diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/cluster-scaling.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/cluster-scaling.md index a60941f04c5..71c4a9c295d 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/cluster-scaling.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/cluster-scaling.md @@ -155,7 +155,8 @@ kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 Run the following command to see the current status of the cluster: ``` -zbctl --insecure status +curl -L 'http://localhost:8080/v2/topology' \ +-H 'Accept: application/json' ``` The response would show that partitions are distributed to new brokers: @@ -252,7 +253,8 @@ This step is optional, but it is useful when you are testing to see if scaling w Run the following command to see the current status of the cluster: ``` -zbctl --insecure status +curl -L 'http://localhost:8080/v2/topology' \ +-H 'Accept: application/json' ``` The response would show that the partitions are moved away from brokers `3`, `4`, and `5`: diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/security/secure-client-communication.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/security/secure-client-communication.md index 8687752b72b..14b8747d95d 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/security/secure-client-communication.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/security/secure-client-communication.md @@ -113,12 +113,16 @@ Then start up your gateway with the certificate and key specified above. For exa docker run -p 26500:26500 -e ZEEBE_BROKER_NETWORK_HOST=0.0.0.0 -e ZEEBE_BROKER_GATEWAY_SECURITY_ENABLED=true -e ZEEBE_BROKER_GATEWAY_SECURITY_CERTIFICATECHAINPATH=/usr/local/zeebe/cert.pem -e ZEEBE_BROKER_GATEWAY_SECURITY_PRIVATEKEYPATH=/usr/local/zeebe/key.pem --mount type=bind,source="$(pwd)"/cert.pem,target=/usr/local/zeebe/cert.pem --mount type=bind,source="$(pwd)"/key.pem,target=/usr/local/zeebe/key.pem camunda/zeebe ``` -There is one caveat: in order for the client to accept this self-signed certificate, you will need to trust it. The simplest way is to specify it as part of the client's configuration. For example, if you're using `zbctl`, you can then do `zbctl --certPath cert.pem status`. Refer to the documentation above on how to configure your clients. +There is one caveat: in order for the client to accept this self-signed certificate, you will need to trust it. The simplest way is to specify it as part of the client's configuration. Refer to the documentation above on how to configure your clients. ## Troubleshooting authentication issues Here we will describe a few ways the clients and gateway could be misconfigured and what those errors look like. Hopefully, this will help you recognize these situations and provide an easy fix. +:::note +`zbctl` is a [community-supported client](/apis-tools/community-clients/cli-client/index.md). +::: + ### TLS is enabled in `zbctl` but disabled in the gateway The client will fail with the following error: diff --git a/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/cli-get-started.md b/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/cli-get-started.md index 3cdc65abac5..a857db31817 100644 --- a/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/cli-get-started.md +++ b/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/cli-get-started.md @@ -5,6 +5,12 @@ sidebar_label: "Getting started with the CLI client" description: "Get started with this tutorial that shows you how to interact with Camunda 8 using the community-supported CLI client and command line interface `zbctl`." --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + In this tutorial, you will learn how to use the [community-supported](https://github.com/camunda-community-hub) `zbctl` CLI client to interact with Camunda 8. :::note diff --git a/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/index.md b/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/index.md index 43651b355f1..ff7045dc45d 100644 --- a/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/index.md +++ b/versioned_docs/version-8.7/apis-tools/community-clients/cli-client/index.md @@ -5,6 +5,12 @@ sidebar_label: "Quick reference" description: "Learn how to use the community-supported CLI client and command line interface `zbctl` to interact with Camunda 8 and test a connection." --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + You can use the [community-supported](https://github.com/camunda-community-hub) `zbctl` command line interface to interact with Camunda 8. After installation, a connection can be tested immediately. diff --git a/versioned_docs/version-8.7/apis-tools/community-clients/go-client/go-get-started.md b/versioned_docs/version-8.7/apis-tools/community-clients/go-client/go-get-started.md index 0b45f4c99ff..89edde14ce3 100644 --- a/versioned_docs/version-8.7/apis-tools/community-clients/go-client/go-get-started.md +++ b/versioned_docs/version-8.7/apis-tools/community-clients/go-client/go-get-started.md @@ -8,6 +8,12 @@ description: "Get started with this tutorial that shows you how to interact with import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + In this tutorial, you will learn how to use the the [community-supported](https://github.com/camunda-community-hub) Go client in a Go application to interact with Camunda 8. You can find a complete example on [GitHub](https://github.com/camunda/camunda-platform-get-started/tree/main/go). diff --git a/versioned_docs/version-8.7/apis-tools/community-clients/go-client/index.md b/versioned_docs/version-8.7/apis-tools/community-clients/go-client/index.md index a56913e1ffd..68bfa24bbd0 100644 --- a/versioned_docs/version-8.7/apis-tools/community-clients/go-client/index.md +++ b/versioned_docs/version-8.7/apis-tools/community-clients/go-client/index.md @@ -5,6 +5,12 @@ sidebar_label: "Quick reference" description: "Instantiate the client by passing in the address of the cluster you want to connect to in a Go application to interact with Camunda 8." --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + You can use the [community-supported](https://github.com/camunda-community-hub) Zeebe Go client library to interact with Camunda 8. ## Dependencies diff --git a/versioned_docs/version-8.7/apis-tools/community-clients/go-client/job-worker.md b/versioned_docs/version-8.7/apis-tools/community-clients/go-client/job-worker.md index 8d98b60532e..1100cccbc5f 100644 --- a/versioned_docs/version-8.7/apis-tools/community-clients/go-client/job-worker.md +++ b/versioned_docs/version-8.7/apis-tools/community-clients/go-client/job-worker.md @@ -5,6 +5,12 @@ description: "Let's take a deeper look at job workers to handle jobs." keywords: ["backpressure", "back-pressure", "back pressure"] --- +:::note Heads up! +This project is community-supported. + +See the [announcement](reference/announcements.md#deprecation-zeebe-go-client--cli-client-zbctl) for more information. +::: + The Go client provides a job worker that handles both polling and streaming for available jobs. This allows you to focus on writing code to handle the activated jobs. On `Open`, the job worker waits `PollInterval` milliseconds and then polls for `MaxJobsActive` jobs. It then continues with the following schedule: diff --git a/versioned_docs/version-8.7/components/concepts/messages.md b/versioned_docs/version-8.7/components/concepts/messages.md index bee82521845..16c48853c5c 100644 --- a/versioned_docs/version-8.7/components/concepts/messages.md +++ b/versioned_docs/version-8.7/components/concepts/messages.md @@ -19,13 +19,34 @@ When a message is published and the message name and correlation key match to a A subscription is closed when the corresponding element (e.g. the message catch event), or its scope is left. After a subscription is opened, it is not updated (for example, when the referenced process instance variable is changed.)
- Publish message via zbctl + Publish message via Camunda 8 REST API

``` -zbctl publish message "Money collected" --correlationKey "order-123" +curl -L 'http://localhost:8080/v2/messages/publication' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "name": "Money collected", + "correlationKey": "order-123" +}' ``` +See the [API reference for publish message](/apis-tools/camunda-api-rest/specifications/publish-a-message.api.mdx) for more information, including additional request fields and code samples. +When you require immediate feedback if the message was correlated to an open subscription, you can use `Correlate message` via Camunda 8 REST API. If correlation is successful it will return the first process instance key the message correlated with. + +``` +curl -L 'http://localhost:8080/v2/messages/correlation' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ +"name": "Money collected", +"correlationKey": "order-123" +}' +``` + +See the [API reference for correlate message](/apis-tools/camunda-api-rest/specifications/correlate-a-message.api.mdx) for more information, including additional request fields and code samples. +

@@ -40,13 +61,22 @@ When a subscription is opened, it polls the buffer for a proper message. If a pr The buffering of a message is disabled when its TTL is set to zero. If no proper subscription is open, the message is discarded.
- Publish message with TTL via zbctl + Publish message with TTL via Camunda 8 REST API

``` -zbctl publish message "Money collected" --correlationKey "order-123" --ttl 1h +curl -L 'http://localhost:8080/v2/messages/publication' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "name": "Money collected", + "correlationKey": "order-123", + "timeToLive": 3600000 +}' ``` +See the [API reference for publish message](/apis-tools/camunda-api-rest/specifications/publish-a-message.api.mdx) for more information, including additional request fields and code samples. +

@@ -67,13 +97,22 @@ A message is rejected and not correlated if a message with the same name, the sa The uniqueness check is disabled when no message ID is set.
- Publish message with ID via zbctl + Publish message with message ID via Camunda 8 REST API

``` -zbctl publish message "Money collected" --correlationKey "order-123" --messageId "tracking-12345" +curl -L 'http://localhost:8080/v2/messages/publication' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "name": "Money collected", + "correlationKey": "order-123", + "messageId": "tracking-12345" +}' ``` +See the [API reference for publish message](/apis-tools/camunda-api-rest/specifications/publish-a-message.api.mdx) for more information, including additional request fields and code samples. +

@@ -119,7 +158,7 @@ The first message creates a new process instance. The following messages are cor When the instance ends and messages with the same correlation key are not correlated yet, a new process instance is created. :::note -You may also use TTL to wait for messages that may arrive earlier when combining [start events and intermediate catch events](/docs/components/modeler/bpmn/events.md). +You may also use TTL to wait for messages that may arrive earlier when combining [start events and intermediate catch events](/components/modeler/bpmn/events.md). ::: ### Single instance diff --git a/versioned_docs/version-8.7/components/concepts/process-instance-creation.md b/versioned_docs/version-8.7/components/concepts/process-instance-creation.md index 04f1d5369c8..af964cf47f1 100644 --- a/versioned_docs/version-8.7/components/concepts/process-instance-creation.md +++ b/versioned_docs/version-8.7/components/concepts/process-instance-creation.md @@ -27,28 +27,34 @@ This command creates a new process instance and immediately responds with the pr ![create-process](assets/create-process.png)
- Code example -

-Create a process instance: +

Create a process instance via Camunda 8 REST API +

``` -zbctl create instance "order-process" +curl -L 'http://localhost:8080/v2/process-instances' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "processDefinitionKey": "2251799813685249”, + "processDefinitionVersion": 1 +}' ``` Response: ``` { - "processKey": 2251799813685249, - "bpmnProcessId": "order-process", - "version": 1, - "processInstanceKey": 2251799813686019 + "processDefinitionId": "order-process", + "processDefinitionVersion": 1, + "processDefinitionKey": "2251799813685249", + "processInstanceKey": "2251799813686019" } - ``` -

-
+See the [API reference for process instance creation](/apis-tools/camunda-api-rest/specifications/create-process-instance.api.mdx) for more information, including additional request fields and code samples. + +

+ ### Create and await results @@ -67,32 +73,37 @@ When the client resends the command, it creates a new process instance. :::
- Code example -

-Create a process instance and await results: +

Create a process instance and await results via Camunda 8 REST API +

``` -zbctl create instance "order-process" --withResult --variables '{"orderId": "1234"}' +curl -L 'http://localhost:8080/v2/process-instances' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "processDefinitionId": "order-process”, + "processDefinitionVersion": 1, + "awaitCompletion": true, + "variables": { "orderId": "1234" } +}' ``` Response: -:::note -The variables in the response depend on the process. -::: - ``` { - "processKey": 2251799813685249, - "bpmnProcessId": "order-process", - "version": 1, - "processInstanceKey": 2251799813686045, - "variables": "{\"orderId\":\"1234\"}" + "processDefinitionId": "order-process", + "processDefinitionVersion": 1, + "variables": { "orderId": "1234" } + "processDefinitionKey": "2251799813685249", + "processInstanceKey": "2251799813686019", } ``` -

-
+See the [API reference for process instance creation](/apis-tools/camunda-api-rest/specifications/create-process-instance.api.mdx) for more information, including additional request fields and code samples. + +

+ Failure scenarios applicable to other commands are applicable to this command as well. Clients may not get a response in the following cases even if the process execution is completed successfully: @@ -123,22 +134,29 @@ Start instructions have the same [limitations as process instance modification]( Start instructions are supported for both `CreateProcessInstance` commands.
- Code example -

-Create a process instance starting before the 'ship_parcel' element: - -```java -client.newCreateInstanceCommand() - .bpmnProcessId("order-process") - .latestVersion() - .variables(Map.of("orderId", "1234")) - .startBeforeElement("ship_parcel") - .send() - .join(); +

Create a process instance and start at a user-defined element +

+ ``` +curl -L 'http://localhost:8080/v2/process-instances' \ +-H 'Content-Type: application/json' \ +-H 'Accept: application/json' \ +-d '{ + "processDefinitionId": "order-process”, + "processDefinitionVersion": -1, + "startInstructions": [ + { + "elementId": "ship_parcel" + } + ], + "variables": { "orderId": "1234" } +}' +``` + +See the [API reference for process instance creation](/apis-tools/camunda-api-rest/specifications/create-process-instance.api.mdx) for more information, including additional request fields and code samples. -

-
+

+ ## Events diff --git a/versioned_docs/version-8.7/components/console/console-troubleshooting/common-pitfalls.md b/versioned_docs/version-8.7/components/console/console-troubleshooting/common-pitfalls.md index 27ddde881c0..799de28a84c 100644 --- a/versioned_docs/version-8.7/components/console/console-troubleshooting/common-pitfalls.md +++ b/versioned_docs/version-8.7/components/console/console-troubleshooting/common-pitfalls.md @@ -15,5 +15,5 @@ Let's take a closer look at common issues and resolutions within Console. ## I cannot connect to Zeebe - Check if your [API client](../manage-clusters/manage-api-clients.md) has the necessary rights. To interact with Zeebe, the **Scope** `Zeebe` must be set. -- Check if your credentials are configured correctly. There is a CLI tool that allows you to check the status: [`zbctl`](https://www.npmjs.com/package/zbctl). With the command `zbctl status`, you can read the topology. If this command works, the connection can be established. +- Check if your credentials are configured correctly. There is a community-supported CLI tool that allows you to check the status: [`zbctl`](https://www.npmjs.com/package/zbctl). With the command `zbctl status`, you can read the topology. If this command works, the connection can be established. - Check if your cluster is **Healthy**: A Zeebe cluster may be temporarily unavailable. To check if your cluster is healthy, navigate to the **Clusters** tab in the top navigation. Click on the cluster to view its details for a closer view of the status over all components (Zeebe, Operate, Tasklist, Optimize). diff --git a/versioned_docs/version-8.7/components/modeler/desktop-modeler/troubleshooting.md b/versioned_docs/version-8.7/components/modeler/desktop-modeler/troubleshooting.md index 49868dcb771..62a051613ce 100644 --- a/versioned_docs/version-8.7/components/modeler/desktop-modeler/troubleshooting.md +++ b/versioned_docs/version-8.7/components/modeler/desktop-modeler/troubleshooting.md @@ -54,11 +54,11 @@ To produce logging output, you can also run Desktop Modeler from the command lin You try to connect (i.e., to deploy) to a remote Zeebe instance, and Desktop Modeler tells you it "cannot find a running Zeebe." -To resolve this issue, check if you can connect to Zeebe through another client, i.e., [`zbctl`](/apis-tools/community-clients/cli-client/index.md). If that works, [further debug your Zeebe connection](#debug-zeebe-connection-issues). If that does not work, resolve the [general connection issue](#resolve-a-general-zeebe-connection-issue) first. +To resolve this issue, check if you can connect to Zeebe through another client, for example, community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md). If that works, [further debug your Zeebe connection](#debug-zeebe-connection-issues). If that does not work, resolve the [general connection issue](#resolve-a-general-zeebe-connection-issue) first. ## Resolve a general Zeebe connection issue -You try to connect to Zeebe from both Desktop Modeler _and_ [`zbctl`](/apis-tools/community-clients/cli-client/index.md), and neither of them works. General connection failures can have a couple of reasons: +You try to connect to Zeebe from both Desktop Modeler _and_ community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md), and neither of them works. General connection failures can have a couple of reasons: ### The (remote) Zeebe instance is not reachable @@ -72,7 +72,7 @@ Secure connections to Zeebe require [HTTP/2 over TLS with protocol negotiation v ## Debug Zeebe connection issues -You can connect to Zeebe via [`zbctl`](/apis-tools/community-clients/cli-client/index.md) or another API client. However, connecting through Desktop Modeler fails. +You can connect to Zeebe via community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md) or another API client. However, connecting through Desktop Modeler fails. ### Secure connection to Zeebe fails diff --git a/versioned_docs/version-8.7/components/operate/userguide/resolve-incidents-update-variables.md b/versioned_docs/version-8.7/components/operate/userguide/resolve-incidents-update-variables.md index bae1e13b90c..3324790d9cc 100644 --- a/versioned_docs/version-8.7/components/operate/userguide/resolve-incidents-update-variables.md +++ b/versioned_docs/version-8.7/components/operate/userguide/resolve-incidents-update-variables.md @@ -7,6 +7,10 @@ description: "Let's examine variable and incidents." import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; +:::note +This guide includes steps with community-supported [`zbctl`](/apis-tools/community-clients/cli-client/index.md). +::: + Every process instance created for the [`order-process.bpmn`](/bpmn/operate/order-process.bpmn) process model requires an `orderValue` so the XOR gateway evaluation will happen properly. Let’s look at a case where `orderValue` is present and was set as a string, but our `order-process.bpmn` model required an integer to properly evaluate the `orderValue` and route the instance. diff --git a/versioned_docs/version-8.7/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md b/versioned_docs/version-8.7/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md index 598a743d067..890c69f1b80 100644 --- a/versioned_docs/version-8.7/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md +++ b/versioned_docs/version-8.7/guides/devops-lifecycle/integrate-web-modeler-in-ci-cd.md @@ -14,7 +14,7 @@ import TabItem from "@theme/TabItem"; [Web Modeler](../../components/modeler/about-modeler.md) serves as a powerful tool for the development and deployment of processes and process applications. While Web Modeler simplifies one-click deployment for development, professional teams often rely on continuous integration and continuous deployment (CI/CD) pipelines for automated production deployments. The [Web Modeler API](/apis-tools/web-modeler-api/index.md) facilitates integration of Web Modeler into these pipelines, aligning with team practices and organizational process governance. -- For low-risk processes, you can use the Web Modeler [process application development pipeline](/docs/components/modeler/web-modeler/process-application-pipeline.md) to quickly develop and progress process application releases through the stages of a standard development lifecycle. [Version comparison](/docs/components/modeler/web-modeler/versions.md#compare-versions) (Visual and XML diffing), built in [review](/components/modeler/web-modeler/process-application-pipeline.md#review), and [Git Sync](/components/modeler/web-modeler/git-sync.md) provide a powerful combination for collaboration between team members using both Web and Desktop Modeler. +- For low-risk processes, you can use Web Modeler [process application development pipeline](/components/modeler/web-modeler/process-application-pipeline.md) to quickly develop and progress process application releases through the stages of a standard development lifecycle. [Version comparison](/components/modeler/web-modeler/versions.md#compare-versions) (Visual and XML diffing), built in [review](/components/modeler/web-modeler/process-application-pipeline.md#review), and [Git Sync](/components/modeler/web-modeler/git-sync.md) provide a powerful combination for collaboration between team members using both Web and Desktop Modeler. - For business-critical and higher-risk processes that require strict governance and/or quality requirements, you can integrate Web Modeler into your CI/CD pipelines. @@ -178,7 +178,7 @@ In the build stage, deploy your process or project to a cluster or embedded engi For GitLab users, consider using [GitLab Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) to provide preview environments. ::: -Deploy resources using the [`zbctl` CLI](/apis-tools/community-clients/cli-client/index.md) in this pipeline step, compatible with both SaaS and Self-Managed clusters. Alternately, utilize the [Java](/apis-tools/java-client/index.md) client library or any [community-built alternatives](/apis-tools/community-clients/index.md). +Deploy resources using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) in this pipeline step, compatible with both SaaS and Self-Managed clusters. Alternately, utilize the [Java](/apis-tools/java-client/index.md) client library or any [community-built alternatives](/apis-tools/community-clients/index.md). :::info Feature branches and Web Modeler installations To maintain a single source of truth, avoid multiple Web Modeler instances for different feature branches. Instead, maintain a single Web Modeler installation for all environments, utilizing versions to signify versioning and pipeline stages. Feature branches can be managed by cloning and merging files or projects, ensuring synchronization using VCS. @@ -206,7 +206,7 @@ To retrieve the actual file `content`, iterate over the response and fetch it vi If you are running Connectors in your process or application, you need to deploy the runtimes as well. Parse the process XML for `zeebe:taskDefinition` bindings to identify the necessary runtimes (in addition to job workers). To learn how to deploy Connector runtimes, read more [here](/self-managed/connectors-deployment/install-and-start.md) for Self-Managed, or [here](/components/connectors/custom-built-connectors/connector-sdk.md#runtime-environments) for SaaS. -Deploy resources in this pipeline step using the [`zbctl` CLI](/apis-tools/community-clients/cli-client/index.md), compatible with both SaaS and Self-Managed clusters. Alternatively, utilize the Java or Go client library or any community-built alternatives. +Deploy resources in this pipeline step using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md), compatible with both SaaS and Self-Managed clusters. Alternatively, utilize the Java or Go client library or any community-built alternatives. #### Add environment variables via secrets @@ -257,7 +257,7 @@ In case you use an embedded Zeebe engine, or want to provide a lightweight, focu ### Publish stage -Push approved changes to staging or production by deploying them to the respective clusters. You can use the [`zbctl` CLI](/apis-tools/community-clients/cli-client/index.md) to deploy via your pipeline, which works both for a SaaS or Self-Managed cluster. Deployments work slightly different on SaaS and Self-Managed, since there are differences in the cluster connection. Read more about deployments [here](/apis-tools/working-with-apis-tools.md#deploy-processes-start-process-instances-and-more-using-zeebe-client-libraries). +Push approved changes to staging or production by deploying them to the respective clusters. You can use the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) to deploy via your pipeline, which works both for a SaaS or Self-Managed cluster. Deployments work slightly different on SaaS and Self-Managed, since there are differences in the cluster connection. Read more about deployments [here](/apis-tools/working-with-apis-tools.md#deploy-processes-start-process-instances-and-more-using-zeebe-client-libraries). #### Define resource authorizations diff --git a/versioned_docs/version-8.7/self-managed/concepts/multi-region/dual-region.md b/versioned_docs/version-8.7/self-managed/concepts/multi-region/dual-region.md index 30a2ad15f5d..c3c15e75ec9 100644 --- a/versioned_docs/version-8.7/self-managed/concepts/multi-region/dual-region.md +++ b/versioned_docs/version-8.7/self-managed/concepts/multi-region/dual-region.md @@ -111,16 +111,16 @@ The following Zeebe brokers and replication configuration are supported: ### Camunda 8 dual-region limitations -| **Aspect** | **Details** | -| :----------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Installation methods |

| -| Camunda Platform Configuration |

The overall Camunda platform is **active-passive**

| -| Identity Support | Identity, including multi-tenancy and Role-Based Access Control (RBAC), is currently unavailable in this setup. | -| Optimize Support | Not supported (requires Identity). | -| Connectors Deployment | Connectors can be deployed in a dual-region setup, but attention to [idempotency](../../../components/connectors/use-connectors/inbound.md#creating-the-connector-event) is required to avoid event duplication. In a dual-region setup, you'll have two connector deployments and using message idempotency is of importance to not duplicate events. | -| Connectors | If you are running Connectors and have a process with an inbound connector deployed in a dual-region setup, consider the following: | -| Zeebe Cluster Scaling | Not supported. | -| Web Modeler | Web Modeler is a standalone component that is not covered in this guide. Modelling applications can operate independently outside of the orchestration clusters. | +| **Aspect** | **Details** | +| :----------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Installation methods |

| +| Camunda Platform Configuration |

The overall Camunda platform is **active-passive**

| +| Identity Support | Identity, including multi-tenancy and Role-Based Access Control (RBAC), is currently unavailable in this setup. | +| Optimize Support | Not supported (requires Identity). | +| Connectors Deployment | Connectors can be deployed in a dual-region setup, but attention to [idempotency](../../../components/connectors/use-connectors/inbound.md#creating-the-connector-event) is required to avoid event duplication. In a dual-region setup, you'll have two connector deployments and using message idempotency is of importance to not duplicate events. | +| Connectors | If you are running Connectors and have a process with an inbound connector deployed in a dual-region setup, consider the following: | +| Zeebe Cluster Scaling | Not supported. | +| Web Modeler | Web Modeler is a standalone component that is not covered in this guide. Modelling applications can operate independently outside of the orchestration clusters. | ### Infrastructure and deployment platform considerations diff --git a/versioned_docs/version-8.7/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md b/versioned_docs/version-8.7/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md index 0e6313d149c..7838aae910c 100644 --- a/versioned_docs/version-8.7/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md +++ b/versioned_docs/version-8.7/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md @@ -6,7 +6,7 @@ sidebar_label: "Zeebe connection" You try to connect (i.e., to deploy) to a remote Zeebe cluster and Web Modeler reports an error. -To resolve this issue, check if you can connect to Zeebe through another client, i.e., [`zbctl`](/apis-tools/community-clients/cli-client/index.md). +To resolve this issue, check if you can connect to Zeebe through another client. If that doesn't work, resolve the general connection issue first (see [the platform deployment troubleshooting section](/self-managed/operational-guides/troubleshooting/troubleshooting.md), for example.) If that works, further debug your Zeebe connection with the help of the information stated below. Enabling [debug logging in `modeler-restapi`](#how-can-i-debug-log-grpc--zeebe-communication) may also help to understand the issue. diff --git a/versioned_docs/version-8.7/self-managed/operational-guides/multi-region/dual-region-ops.md b/versioned_docs/version-8.7/self-managed/operational-guides/multi-region/dual-region-ops.md index 9178aefbb72..a582f4e8fe3 100644 --- a/versioned_docs/version-8.7/self-managed/operational-guides/multi-region/dual-region-ops.md +++ b/versioned_docs/version-8.7/self-managed/operational-guides/multi-region/dual-region-ops.md @@ -39,7 +39,7 @@ This procedure has been updated in the Camunda 8.6 release. The procedure used i This operational blueprint procedure is a step-by-step guide on how to restore operations in the case of a total region failure. It explains how to temporarily restore functionality in the surviving region and how to ultimately do a full recovery to restore the dual-region setup. The operational procedure builds on top of the [dual-region AWS setup guidance](/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md), but is generally applicable for any dual-region setup. -It has been also validated for the [OpenShift dual-region setup guidance](/docs/self-managed/setup/deploy/openshift/dual-region.md). +It has been also validated for the [OpenShift dual-region setup guidance](/self-managed/setup/deploy/openshift/dual-region.md). Before proceeding with the operational procedure, thoroughly review and understand the contents of the [dual-region concept page](./../../concepts/multi-region/dual-region.md). This page outlines various limitations and requirements pertinent to the procedure, which are crucial for successful execution. @@ -53,11 +53,10 @@ Running a dual-region configuration requires users to detect and manage any regi ## Prerequisites -- A dual-region Camunda 8 setup installed in two different regions, preferably derived from our [AWS dual-region concept](/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md) or [OpenShift dual-region concept](/docs/self-managed/setup/deploy/openshift/dual-region.md). +- A dual-region Camunda 8 setup installed in two different regions, preferably derived from our [AWS dual-region concept](/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md) or [OpenShift dual-region concept](/self-managed/setup/deploy/openshift/dual-region.md). - In that guide, we're showcasing Kubernetes dual-region installation, based on the following tools: - [Helm (3.x)](https://helm.sh/docs/intro/install/) for installing and upgrading the [Camunda Helm chart](https://artifacthub.io/packages/helm/camunda/camunda-platform). - [Kubectl (1.30.x)](https://kubernetes.io/docs/tasks/tools/#kubectl) to interact with the Kubernetes cluster. -- (deprecated) [zbctl](/apis-tools/community-clients/cli-client/index.md) to interact with the Zeebe cluster. - `cURL` or similar to interact with the REST API. ## Terminology @@ -186,9 +185,6 @@ The following alternatives to port-forwarding are possible: In our example, we went with port-forwarding to a localhost, but other alternatives can also be used. - - - 1. Use the [REST API](../../../apis-tools/camunda-api-rest/camunda-api-rest-overview.md) to retrieve the list of the remaining brokers ```bash @@ -328,59 +324,6 @@ In our example, we went with port-forwarding to a localhost, but other alternati - - - -1. Use the [zbctl client](/apis-tools/community-clients/cli-client/index.md) to retrieve list of remaining brokers - - ```bash - kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING - zbctl status --insecure --address localhost:26500 - ``` - -
- Example output - - - ```bash - Cluster size: 8 - Partitions count: 8 - Replication factor: 4 - Gateway version: 8.6.0 - Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 8 : Leader, Healthy - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Leader, Healthy - ``` - - - -
- -
-
- 2. Port-forward the service of the Zeebe Gateway to access the [management REST API](../../zeebe-deployment/configuration/gateway.md#managementserver) ```bash @@ -398,9 +341,6 @@ In our example, we went with port-forwarding to a localhost, but other alternati Port-forwarding the Zeebe Gateway via `kubectl` and printing the topology should reveal that the cluster size has decreased to 4, partitions have been redistributed over the remaining brokers, and new leaders have been elected. - - - ```bash kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 8080:8080 -n $CAMUNDA_NAMESPACE_SURVIVING @@ -538,56 +478,6 @@ curl -L -X GET 'http://localhost:8080/v2/topology' \ - - - -```bash -kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING -zbctl status --insecure --address localhost:26500 -``` - -
- Example output - - -```bash -Cluster size: 4 -Partitions count: 8 -Replication factor: 2 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Leader, Healthy - Partition 3 : Follower, Healthy - Partition 8 : Leader, Healthy - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Leader, Healthy - Partition 5 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Leader, Healthy -``` - - -
- -
-
- You can also use the Zeebe Gateway's REST API to ensure the scaling progress has been completed. For better output readability, we use [jq](https://jqlang.github.io/jq/). ```bash @@ -801,9 +691,6 @@ It is expected that the Zeebe broker pods will not reach the "Ready" state since Port-forwarding the Zeebe Gateway via `kubectl` and printing the topology should reveal that the new Zeebe brokers are recognized but yet a full member of the Zeebe cluster. - - - ```bash kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 8080:8080 -n $CAMUNDA_NAMESPACE_SURVIVING @@ -969,64 +856,6 @@ curl -L -X GET 'http://localhost:8080/v2/topology' \ - - - -```bash -kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING -zbctl status --insecure --address localhost:26500 -``` - -
- Example Output - - -```bash -Cluster size: 4 -Partitions count: 8 -Replication factor: 2 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Leader, Healthy - Broker 1 - camunda-zeebe-0.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Leader, Healthy - Partition 3 : Leader, Healthy - Partition 8 : Follower, Healthy - Broker 3 - camunda-zeebe-1.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Leader, Healthy - Partition 5 : Leader, Healthy - Broker 5 - camunda-zeebe-2.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Leader, Healthy - Broker 7 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 -``` - - -
- -
-
- @@ -1562,76 +1391,6 @@ curl -XGET 'http://localhost:9600/actuator/cluster' | jq .lastChange -Port-forwarding the Zeebe Gateway via kubectl and printing the topology should reveal that all brokers have joined the Zeebe cluster again. - -``` -kubectl --context $CLUSTER_SURVIVING port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -n $CAMUNDA_NAMESPACE_SURVIVING -zbctl status --insecure --address localhost:26500 -``` - -
- Example Output - - -```bash -Cluster size: 8 -Partitions count: 8 -Replication factor: 4 -Gateway version: 8.6.0 -Brokers: -Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Leader, Healthy -Broker 1 - camunda-zeebe-0.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy -Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 8 : Follower, Healthy -Broker 3 - camunda-zeebe-1.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy -Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Leader, Healthy - Partition 3 : Leader, Healthy - Partition 4 : Leader, Healthy - Partition 5 : Follower, Healthy -Broker 5 - camunda-zeebe-2.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy -Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Leader, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Leader, Healthy -Broker 7 - camunda-zeebe-3.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy -``` - - -
-
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md index 22a35de8f35..f13712d3976 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md @@ -519,9 +519,6 @@ helm install $HELM_RELEASE_NAME camunda/camunda-platform \ 1. Open a terminal and port-forward the Zeebe Gateway via `kubectl` from one of your clusters. Zeebe is stretching over both clusters and is `active-active`, meaning it doesn't matter which Zeebe Gateway to use to interact with your Zeebe cluster. - - - ```shell kubectl --context "$CLUSTER_0" -n $CAMUNDA_NAMESPACE_0 port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 8080:8080 ``` @@ -776,84 +773,3 @@ curl -L -X GET 'http://localhost:8080/v2/topology' \ - - - - -```shell -kubectl --context "$CLUSTER_0" -n $CAMUNDA_NAMESPACE_0 port-forward services/$HELM_RELEASE_NAME-zeebe-gateway 26500:26500 -``` - -1. Open another terminal and use [zbctl](/apis-tools/community-clients/cli-client/index.md) to print the Zeebe cluster status: - -```shell -zbctl status --insecure --address localhost:26500 -``` - -3. Make sure that your output contains all eight brokers from the two regions: - -
- Example output - - -```shell -Cluster size: 8 -Partitions count: 8 -Replication factor: 4 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 1 - camunda-zeebe-0.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Leader, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Follower, Healthy - Broker 2 - camunda-zeebe-1.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy - Partition 8 : Follower, Healthy - Broker 3 - camunda-zeebe-1.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Leader, Healthy - Broker 4 - camunda-zeebe-2.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Leader, Healthy - Broker 5 - camunda-zeebe-2.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 3 : Follower, Healthy - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Broker 6 - camunda-zeebe-3.camunda-zeebe.camunda-london.svc:26501 - Version: 8.6.0 - Partition 4 : Follower, Healthy - Partition 5 : Follower, Healthy - Partition 6 : Leader, Healthy - Partition 7 : Leader, Healthy - Broker 7 - camunda-zeebe-3.camunda-zeebe.camunda-paris.svc:26501 - Version: 8.6.0 - Partition 5 : Follower, Healthy - Partition 6 : Follower, Healthy - Partition 7 : Follower, Healthy - Partition 8 : Leader, Healthy -``` - - -
- -
-
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md index 71244313b09..c0334dfc055 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md @@ -20,7 +20,7 @@ Lastly you'll verify that the connection to your Self-Managed Camunda 8 environm - [kubectl (1.30+)](https://kubernetes.io/docs/tasks/tools/#kubectl) to interact with the cluster. - [jq (1.7+)](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.gnu.org/software/gettext/manual/html_node/envsubst-Invocation.html) to generate manifests. -- (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via [zbctl](/apis-tools/community-clients/cli-client/index.md) or [Camunda Modeler](https://camunda.com/download/modeler/). +- (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via community-supported [zbctl](/apis-tools/community-clients/cli-client/index.md) or [Camunda Modeler](https://camunda.com/download/modeler/). - A namespace to host the Camunda Platform, in this guide we will reference `camunda` as the target namespace. ### Considerations @@ -622,9 +622,6 @@ Console: ### Use the token - - - For a detailed guide on generating and using a token, please conduct the relevant documentation on [authenticating with the REST API](./../../../../../apis-tools/camunda-api-rest/camunda-api-rest-authentication.md?environment=self-managed). @@ -762,132 +759,6 @@ curl --header "Authorization: Bearer ${TOKEN}" "${ZEEBE_ADDRESS_REST}/v2/topolog - - - -After following the installation instructions in the [zbctl docs](/apis-tools/community-clients/cli-client/index.md), we can configure the required connectivity to check that the Zeebe cluster is reachable. - - - - -Export the following environment variables: - -```shell -export ZEEBE_ADDRESS=zeebe.$DOMAIN_NAME:443 -export ZEEBE_AUTHORIZATION_SERVER_URL=https://$DOMAIN_NAME/auth/realms/camunda-platform/protocol/openid-connect/token -export ZEEBE_TOKEN_AUDIENCE='zeebe-api' -export ZEEBE_TOKEN_SCOPE='camunda-identity' -``` - - - - -This requires to port-forward the Zeebe Gateway to be able to connect to the cluster. - -```shell -kubectl port-forward services/camunda-zeebe-gateway 26500:26500 --namespace camunda -``` - -Export the following environment variables: - -```shell -export ZEEBE_ADDRESS=localhost:26500 -export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token -export ZEEBE_TOKEN_AUDIENCE='zeebe-api' -export ZEEBE_TOKEN_SCOPE='camunda-identity' -``` - - - - - -Executing the following command will result in a successful connection to the Zeebe cluster... - -```shell -zbctl status -# or in the case of port-forwarding (without domain) -zbctl status --insecure -``` - -...and results in the following output: - -
- Example output - - -```shell -Cluster size: 3 -Partitions count: 3 -Replication factor: 3 -Gateway version: 8.6.0 -Brokers: - Broker 0 - camunda-zeebe-0.camunda-zeebe.camunda.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Follower, Healthy - Broker 1 - camunda-zeebe-1.camunda-zeebe.camunda.svc:26501 - Version: 8.6.0 - Partition 1 : Leader, Healthy - Partition 2 : Leader, Healthy - Partition 3 : Follower, Healthy - Broker 2 - camunda-zeebe-2.camunda-zeebe.camunda.svc:26501 - Version: 8.6.0 - Partition 1 : Follower, Healthy - Partition 2 : Follower, Healthy - Partition 3 : Leader, Healthy -``` - - -
- -For more advanced topics, like deploying a process or registering a worker, consult the [zbctl docs](/apis-tools/community-clients/cli-client/cli-get-started.md). - -
- - -Follow our existing [Modeler guide on deploying a diagram](/self-managed/modeler/desktop-modeler/deploy-to-self-managed.md). Below are the helper values required to be filled in Modeler: - - - - - -The following values are required for the OAuth authentication: - -- **Cluster endpoint:** `https://zeebe.$DOMAIN_NAME`, replacing `$DOMAIN_NAME` with your domain -- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application -- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application -- **OAuth Token URL:** `https://$DOMAIN_NAME/auth/realms/camunda-platform/protocol/openid-connect/token`, replacing `$DOMAIN_NAME` with your domain -- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed - - - - - -This requires port-forwarding the Zeebe Gateway to be able to connect to the cluster: - -```shell -kubectl port-forward services/camunda-zeebe-gateway 26500:26500 --namespace camunda -``` - -The following values are required for OAuth authentication: - -- **Cluster endpoint:** `http://localhost:26500` -- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application -- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application -- **OAuth Token URL:** `http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token` -- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed - - - - - -
- ## Test the installation with payment example application To test your installation with the deployment of a sample application, refer to the [installing payment example guide](../../../guides/installing-payment-example.md). diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/local/local-kubernetes-cluster.md b/versioned_docs/version-8.7/self-managed/setup/deploy/local/local-kubernetes-cluster.md index 5991e4683c5..54b60fd2be9 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/local/local-kubernetes-cluster.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/local/local-kubernetes-cluster.md @@ -89,7 +89,7 @@ First, port-forward each of the components. Use a separate terminal for each com ## Connecting to the workflow engine -To interact with the Camunda workflow engine via Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe Gateway as follows: +To interact with the Camunda workflow engine via Zeebe Gateway using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe Gateway as follows: ```sh kubectl port-forward svc/camunda-platform-zeebe-gateway 26500:26500 diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/local/manual.md b/versioned_docs/version-8.7/self-managed/setup/deploy/local/manual.md index b24d42b708f..35aa51c3ea7 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/local/manual.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/local/manual.md @@ -92,23 +92,37 @@ You’ll know Zeebe has started successfully when you see a message similar to t [exporter] [0.0.0.0:26501-zb-actors-1] INFO io.camunda.zeebe.broker.exporter.elasticsearch - Exporter opened ``` -You can test the Zeebe Gateway by asking for the cluster topology with [zbtcl](/apis-tools/community-clients/cli-client/index.md#usage): - -```shell -./bin/zbctl --insecure status -``` - -`zbctl status` should produce an output like this: - -``` -Cluster size: 1 -Partitions count: 1 -Replication factor: 1 -Gateway version: 8.1.6 -Brokers: - Broker 0 - 0.0.0.0:26501 - Version: 8.1.6 - Partition 1 : Leader, Healthy +You can test the Zeebe Gateway by asking for the cluster topology with the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md): + +``` +curl -L 'http://localhost:8080/v2/topology' \ +-H 'Accept: application/json' +``` + +Which should produce an output like this: + +```json +{ + "brokers": [ + { + "nodeId": 0, + "host": "string", + "port": 0, + "partitions": [ + { + "partitionId": 0, + "role": "leader", + "health": "healthy" + } + ], + "version": "8.8.0" + } + ], + "clusterSize": 1, + "partitionsCount": 1, + "replicationFactor": 1, + "gatewayVersion": "8.8.0" +} ``` ## Run Operate diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md index 3722ab2d172..2fe3290fa94 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md @@ -509,9 +509,6 @@ chmod +x verify_installation_completed.sh 1. Open a terminal and port-forward the Zeebe Gateway via `oc` from one of your clusters. Zeebe is stretching over both clusters and is `active-active`, meaning it doesn't matter which Zeebe Gateway to use to interact with your Zeebe cluster. - - - ```shell oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/$HELM_RELEASE_NAME-zeebe-gateway" 8080:8080 ``` @@ -533,33 +530,6 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/ - - - -```shell -oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/$HELM_RELEASE_NAME-zeebe-gateway" 26500:26500 -``` - -1. Open another terminal and use [zbctl](/apis-tools/community-clients/cli-client/index.md) to print the Zeebe cluster status: - - ```shell - zbctl status --insecure --address localhost:26500 - ``` - -2. Make sure that your output contains all eight brokers from the two regions: - -
- Example output - - ```text reference - https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/zbctl-output.txt - ``` - -
- -
-
- ## Failover Consult the generic [dual-region failover procedure](/self-managed/operational-guides/multi-region/dual-region-ops.md). diff --git a/versioned_docs/version-8.7/self-managed/setup/guides/accessing-components-without-ingress.md b/versioned_docs/version-8.7/self-managed/setup/guides/accessing-components-without-ingress.md index 07615294c12..24893f4ea2c 100644 --- a/versioned_docs/version-8.7/self-managed/setup/guides/accessing-components-without-ingress.md +++ b/versioned_docs/version-8.7/self-managed/setup/guides/accessing-components-without-ingress.md @@ -12,13 +12,13 @@ You need to keep `port-forward` running all the time to communicate with the rem ## Accessing workflow engine -To interact with Camunda workflow engine via [Zeebe Gateway](/self-managed/zeebe-deployment/configuration/gateway.md) using [zbctl](/apis-tools/community-clients/cli-client/index.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe cluster as following: +To interact with Camunda workflow engine via [Zeebe Gateway](/self-managed/zeebe-deployment/configuration/gateway.md) using the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe cluster as following: ``` kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 ``` -Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe Broker. +Now, you can connect and execute operations against your new Zeebe cluster. :::note Accessing the Zeebe cluster directly using `kubectl port-forward` is recommended for development purposes. @@ -93,7 +93,7 @@ Log in to these services using the first user `demo`/`demo` credentials. If you deploy process definitions, they will appear in the dashboard. Then, you can drill down to see your active instances. -You can deploy and create new instances using the Zeebe clients or `zbctl`. +You can deploy and create new instances using the Zeebe clients. You can also trigger **Connectors** inbound webhook, given you deployed one. You can do so with the following example: `curl -X POST -H "Content-Type: application/json" -d '{"myId": 123456, "myMessage": "Hello, world!"}' http://localhost:8088/inbound/`. diff --git a/versioned_docs/version-8.7/self-managed/zeebe-deployment/operations/cluster-scaling.md b/versioned_docs/version-8.7/self-managed/zeebe-deployment/operations/cluster-scaling.md index a60941f04c5..71c4a9c295d 100644 --- a/versioned_docs/version-8.7/self-managed/zeebe-deployment/operations/cluster-scaling.md +++ b/versioned_docs/version-8.7/self-managed/zeebe-deployment/operations/cluster-scaling.md @@ -155,7 +155,8 @@ kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 Run the following command to see the current status of the cluster: ``` -zbctl --insecure status +curl -L 'http://localhost:8080/v2/topology' \ +-H 'Accept: application/json' ``` The response would show that partitions are distributed to new brokers: @@ -252,7 +253,8 @@ This step is optional, but it is useful when you are testing to see if scaling w Run the following command to see the current status of the cluster: ``` -zbctl --insecure status +curl -L 'http://localhost:8080/v2/topology' \ +-H 'Accept: application/json' ``` The response would show that the partitions are moved away from brokers `3`, `4`, and `5`: diff --git a/versioned_docs/version-8.7/self-managed/zeebe-deployment/security/secure-client-communication.md b/versioned_docs/version-8.7/self-managed/zeebe-deployment/security/secure-client-communication.md index 8687752b72b..14b8747d95d 100644 --- a/versioned_docs/version-8.7/self-managed/zeebe-deployment/security/secure-client-communication.md +++ b/versioned_docs/version-8.7/self-managed/zeebe-deployment/security/secure-client-communication.md @@ -113,12 +113,16 @@ Then start up your gateway with the certificate and key specified above. For exa docker run -p 26500:26500 -e ZEEBE_BROKER_NETWORK_HOST=0.0.0.0 -e ZEEBE_BROKER_GATEWAY_SECURITY_ENABLED=true -e ZEEBE_BROKER_GATEWAY_SECURITY_CERTIFICATECHAINPATH=/usr/local/zeebe/cert.pem -e ZEEBE_BROKER_GATEWAY_SECURITY_PRIVATEKEYPATH=/usr/local/zeebe/key.pem --mount type=bind,source="$(pwd)"/cert.pem,target=/usr/local/zeebe/cert.pem --mount type=bind,source="$(pwd)"/key.pem,target=/usr/local/zeebe/key.pem camunda/zeebe ``` -There is one caveat: in order for the client to accept this self-signed certificate, you will need to trust it. The simplest way is to specify it as part of the client's configuration. For example, if you're using `zbctl`, you can then do `zbctl --certPath cert.pem status`. Refer to the documentation above on how to configure your clients. +There is one caveat: in order for the client to accept this self-signed certificate, you will need to trust it. The simplest way is to specify it as part of the client's configuration. Refer to the documentation above on how to configure your clients. ## Troubleshooting authentication issues Here we will describe a few ways the clients and gateway could be misconfigured and what those errors look like. Hopefully, this will help you recognize these situations and provide an easy fix. +:::note +`zbctl` is a [community-supported client](/apis-tools/community-clients/cli-client/index.md). +::: + ### TLS is enabled in `zbctl` but disabled in the gateway The client will fail with the following error: