diff --git a/docs/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png b/docs/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png index de3b4209e0..fc315f12bb 100644 Binary files a/docs/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png and b/docs/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png differ diff --git a/docs/components/best-practices/architecture/deciding-about-your-stack.md b/docs/components/best-practices/architecture/deciding-about-your-stack.md index 4d29d53e8d..04bdeecf13 100644 --- a/docs/components/best-practices/architecture/deciding-about-your-stack.md +++ b/docs/components/best-practices/architecture/deciding-about-your-stack.md @@ -9,83 +9,84 @@ tags: - Maven --- -If you don't have special architecture requirements, we recommend using SaaS following the proposed greenfield stack. - :::caution Camunda 8 -This best practice targets Camunda 8 only! If you look for Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). +This best practice targets Camunda 8. For Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). ::: -## The greenfield stack +Our greenfield stack recommendation is a result of extensive discussions and evaluations. While not the only option, it is a solid choice if there are no specific reasons to choose an alternative. -We like to give one greenfield stack recommendation, which is the stack you can simply use if there is no reason against it. And while we went through long and detailed discussions to come to this recommendation, it _doesn't_ mean that it is necessarily superior to alternative stacks. You can still feel confident if you go down another route (note below for alternative options). +Your choice of programming language should align with your team's expertise; we suggest Java or JavaScript for their broad applicability and support, and have outlined the Java greenfield stack below with Camunda 8 SaaS. -The stack looks pretty similar in various programming language. Please use the programming language your team is most familiar with. If in doubt, use Java or JavaScript. +## The Java greenfield stack -### The Java greenfield stack +:::caution +[Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) is currently a community-maintained project. +::: ![greenfield stack architecture diagram](deciding-about-your-stack-assets/greenfield-architecture.png) -Use the following stack: +This architecture diagram illustrates the flow of requests from a user's browser through Camunda SaaS, where workflows and decisions are orchestrated. The process then moves to the Spring Boot application, which is responsible for executing business logic, handling database interactions with PostgreSQL, and managing various components such as custom REST endpoints, BPMN/DMN definitions, and external task workers. -1. Use [Camunda 8 SaaS](https://signup.camunda.com/accounts?utm_source=docs.camunda.io&utm_medium=referral) and create a cluster there +### Why this stack? -1. Build your process solution project as a [Spring Boot](https://spring.io/projects/spring-boot) application, using the [Spring Zeebe](/docs/apis-tools/community-clients/spring.md). +- SaaS simplifies workflow engine integration. +- Spring Boot is widely adopted for Java application development. +- Flexible for both on-premise and cloud environments. -1. Use [Maven](https://maven.apache.org/) as a build tool. +Discover more in our [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or the [Spring Zeebe instructions](https://github.com/camunda-community-hub/spring-zeebe). -1. Use your favorite IDE, for example Visual Studio Code, IntelliJ or Eclipse. +### Set up the stack -1. Use [Open JDK 17](https://jdk.java.net/17/) as Java runtime. +For a Java-based setup using Camunda 8 SaaS and Spring Boot, use the following stack: -1. Model the processes with the [Camunda Modeler](https://camunda.org/download/modeler/). +#### Camunda 8 SaaS account and cluster -1. Add your process models and all Java code to the project. +If you're new to Camunda SaaS, check out our [getting started guide](/guides/introduction-to-camunda-8.md#getting-started) to set up your environment. -To run the process application _in production_: +After signing up, create a cluster by following [creating a cluster in Camunda 8](/guides/create-cluster.md), which provides step-by-step instructions on setting up a new cluster in the Camunda 8 environment. -3. Run the process application by copying the `jar` file to the server and start it with `java -jar YourProcessApplication.jar`. This is most often done via Docker. +#### Spring Boot -Refer to our [example application](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot). +Develop your own process solutions as [Spring Boot](https://spring.io/projects/spring-boot) applications. This involves setting up a new Spring Boot project, either manually or using tools like [Spring Initializr](https://start.spring.io/). -We decided on this stack for the following reasons: +Integrate [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) into the Spring Boot project by adding necessary dependencies to the project’s pom.xml file and configuring the application to use Camunda services. -- All components are open source and easily available. -- SaaS is the easiest way to consume capabilities like a workflow engine. -- Spring Boot is currently the most adopted way of building Java applications. -- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud. +#### Maven -Take a look at the [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or follow the instructions in [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) to get started. +Use [Maven](https://maven.apache.org/) to manage the build lifecycle of the application. -## Polyglot stacks +#### IDE selection -You can develop process solutions as described with Java above also in any other programming language. Simply use the [existing language clients / SDKs](../../../apis-tools/working-with-apis-tools.md) for doing this. +Select an Integrated Development Environment (IDE) that supports Java development, Maven, and Spring Boot. Frequently used options include Visual Studio Code, IntelliJ IDEA, or Eclipse. - +Install and use OpenJDK 17 as your Java runtime environment. Download it from the [official JDK 17 download page](https://jdk.java.net/17/). -## Customize your stack +#### Modeling + +Download and use Camunda Modeler for designing and modeling business processes. Modeler is available [here](https://camunda.org/download/modeler/). + +#### Code integration -### Running Camunda 8 self-managed +Incorporate all Java code and BPMN process models into the Spring Boot project, ensuring that they are structured correctly and referenced properly within the application. -You can also run Camunda 8 self-managed on your own Kubernetes cluster. Details can be found in the [deployment docs](/self-managed/installation/overview.md). +### Run the process application: -While there [exists a Docker Compose configuration](/self-managed/installation/deploy/other/docker.md) to run Camunda 8 locally, this is not meant to be used for production, but rather to quickly startup components on a developer machine to be able to play around. +To run the process application, transfer the `jar` to the desired server. -### Modeling for executable processes +Start the application using the command `java -jar YourProcessApplication.jar`. Frequently, this deployment process is managed through Docker for ease of use. + +For a practical implementation, refer to our [example application on GitHub](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot), which demonstrates a typical setup for a Spring Boot-based process application with Camunda. + + + +## Customize your stack -We distinguish two different roles modeling in BPM projects: +### Polyglot stacks -- _Process developers_ develop an executable process implementation. Process developers implementing solutions with Camunda must use Camunda Modeler to model executable processes, edit technical attributes, and manage and version (e.g. in Git or SVN) the resulting (XML) files as part of the development project. +You can develop process solutions as described with Java above also in any other programming language, including JavaScript. Use the [existing language clients and SDKs](/apis-tools/working-with-apis-tools.md) for doing this. -- _Process analysts_ capture the operational know how about a process. For this part of the work, it is possible to use a different tool than Camunda Modeler. +### Run Camunda 8 Self-Managed -| | Camunda Modeler | Third-Party Modeler (BPMN Standard Compliant) | Third-Party Modeler (Non-Compliant to Standard) | -| ------------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | -| Roundtrip in between process analysts and developers possible | ✔ | ✔ (Carefully check level of BPMN compliance - the [Model Interchange Working Group](http://bpmn-miwg.github.io/bpmn-miwg-tools/) can serve as a first starting point | | -| Use for process analysts | ✔ | ✔ | | -| Use for process developers | ✔ | | | -| Use when | You do not have a BPMN standard compliant modeling tool already rolled out. | You already rolled out a BPMN tool with a standard compliancy sufficient for roundtrip. | Try to avoid | -| | [Download](https://camunda.org/download/modeler/) | [e.g. Cawemo](http://cawemo.com/) | | +Run Camunda 8 on your Kubernetes cluster. For local development, a [Docker Compose configuration is available](/self-managed/platform-deployment/docker.md), though not for production use. Learn more in the [deployment docs](/self-managed/platform-deployment/overview.md). diff --git a/docs/components/modeler/web-modeler/collaboration.md b/docs/components/modeler/web-modeler/collaboration.md index a25b7bd929..bfa0628f86 100644 --- a/docs/components/modeler/web-modeler/collaboration.md +++ b/docs/components/modeler/web-modeler/collaboration.md @@ -28,7 +28,7 @@ There are four roles with different levels of access rights that can be assigned - **Commenter**: the user cannot edit folders or diagrams nor invite users, but can view and leave comments on diagrams. - **Viewer**: The user cannot edit folders or diagrams nor leave comments, but can only view diagrams. -Additionally, the **Owner** of the organization has special privileges to do administrative tasks in **super-user mode**. +Additionally, the **Owner** and **Admins** of the organization have special privileges to do administrative tasks in **super-user mode**. #### Super-user mode @@ -36,15 +36,15 @@ Additionally, the **Owner** of the organization has special privileges to do adm Super-user mode is not yet available in Web Modeler Self-Managed. ::: -Super-user mode is only available to the **Owner** of the organization and can be enabled via the user menu in Web Modeler: +Super-user mode is only available to the **Owner** and **Admins** of the organization and can be enabled via the user menu in Web Modeler:

Enable super-user mode in Web Modeler's user menu

The main purpose of this mode is to assign collaborators to orphaned projects (which have no collaborators). Ordinarily, these projects would not be accessible or visible to any users. -When the **Owner** activates super-user mode, they are temporarily granted **Project Admin** access to all projects -of the organization. This allows the **Owner** to assign collaborators to orphaned projects and gives the **Owner** +When the **Owner** or an **Admin** activates super-user mode, they are temporarily granted **Project Admin** access to all projects +of the organization. This allows them to assign collaborators to orphaned projects and gives them full access when none of the ordinary collaborators are available. ### Inviting users to projects diff --git a/docs/self-managed/installation/guides/helm-kubernetes/upgrade.md b/docs/self-managed/installation/guides/helm-kubernetes/upgrade.md index d6fad6ee7d..5c447cee3a 100644 --- a/docs/self-managed/installation/guides/helm-kubernetes/upgrade.md +++ b/docs/self-managed/installation/guides/helm-kubernetes/upgrade.md @@ -80,9 +80,9 @@ helm upgrade camunda camunda/camunda-platform\ --set global.identity.auth.operate.existingSecret=$OPERATE_SECRET \ --set global.identity.auth.connectors.existingSecret=$CONNECTORS_SECRET \ --set global.identity.auth.zeebe.existingSecret=$ZEEBE_SECRET \ - --set identity.keycloak.auth.adminPassword=$KEYCLOAK_ADMIN_SECRET \ - --set identity.keycloak.auth.managementPassword=$KEYCLOAK_MANAGEMENT_SECRET \ - --set identity.keycloak.postgresql.auth.password=$POSTGRESQL_SECRET + --set identityKeycloak.auth.adminPassword=$KEYCLOAK_ADMIN_SECRET \ + --set identityKeycloak.auth.managementPassword=$KEYCLOAK_MANAGEMENT_SECRET \ + --set identityKeycloak.postgresql.auth.password=$POSTGRESQL_SECRET ``` :::note @@ -93,8 +93,98 @@ For more details on the Keycloak upgrade path, you can also read the [Bitnami Ke ## Version update instructions +### v10.0.0 + +Camunda Release Cycle: 8.5 + +:::caution Breaking changes +The Camunda Helm chart v10.0.0 has major changes in the values file structure. Follow the upgrade steps for each component before starting the chart upgrade. +::: + +#### Identity + +The Camunda Identity component was formerly a sub-chart of the Camunda Helm chart. Now, it is part of the parent Camunda Helm chart. + +There are no changes in the Identity keys, but since the `LabelSelector` `MatchLabels` of a Kubernetes resource are immutable, its deployment should be deleted as the label `app.kubernetes.io/name` has been changed from `identity` to `camunda-platform`. + +```shell +kubectl -n camunda delete -l app.kubernetes.io/name=identity deployment +``` + +#### Identity - Keycloak + +The Identity Keycloak values key has been changed from `identity.keycloak` to `identityKeycloak`. +To migrate, move the values under the new key in the values file. + +Old: + +```yaml +identity: + keycloak: +``` + +New: + +```yaml +identityKeycloak: +``` + +#### Identity - PostgreSQL + +The Identity PostgreSQL values key has been changed from `identity.postgresql` to `identityPostgresql`. +To migrate, move the values under the new key in the values file. + +Old: + +```yaml +identity: + postgresql: +``` + +New: + +```yaml +identityPostgresql: +``` + +#### Web Modeler - PostgreSQL + +The WebModler PostgreSQL values key has been changed from `postgresql` to `webModelerPostgresql`. +To migrate, move the values under the new key in the values file. + +Old: + +```yaml +postgresql: +``` + +New: + +```yaml +webModelerPostgresql: +``` + +#### Zeebe Gateway + +The Zeebe Gateway values key has been changed from `zeebe-gateway` to `zeebeGateway`. +To migrate, move the values under the new key in the values file. + +Old: + +```yaml +zeebe-gateway: +``` + +New: + +```yaml +zeebeGateway: +``` + ### v9.3.0 +Camunda Release Cycle: 8.4 + #### Enabling Console When enabling Console for the first time, you may see the following error: @@ -117,6 +207,8 @@ You should now be able to log into Console. ### v9.0.0 +Camunda Release Cycle: 8.4 + For full change log, view the Camunda Helm chart [v9.0.0 release notes](https://github.com/camunda/camunda-platform-helm/releases/tag/camunda-platform-9.0.0). #### Helm chart @@ -147,6 +239,8 @@ Elasticsearch image has been upgraded from 8.8.2 to 8.9.2. ### v8.3.1 +Camunda Release Cycle: 8.3 + :::caution The following steps are applied when upgrading from **any** previous version, including `8.3.0`. ::: @@ -176,6 +270,8 @@ The following resources have been renamed: ### v8.3.0 (minor) +Camunda Release Cycle: 8.3 + :::caution Updating Operate, Tasklist, and Optimize from 8.2.x to 8.3.0 will potentially take longer than expected, depending on the data to be migrated. Additionally, we identified some bugs that could also prevent the migration from succeeding. These are being addressed and will be available in an upcoming 8.3.1 patch. We suggest not updating until the patch is released. @@ -406,6 +502,8 @@ webModeler: ### v8.2.9 +Camunda Release Cycle: 8.2 + #### Optimize For Optimize 3.10.1, a new environment variable introduced redirection URL. However, the change is not compatible with Camunda Helm charts until it is fixed in 3.10.3 (and Helm chart 8.2.9). Therefore, those versions are coupled to certain Camunda Helm chart versions: @@ -419,6 +517,8 @@ No action is needed if you use Optimize 3.10.3 (shipped with this Helm chart ver ### v8.2.3 +Camunda Release Cycle: 8.2 + #### Zeebe Gateway :::caution Breaking change @@ -438,6 +538,8 @@ To authenticate: ### v8.2.0 (Minor) +Camunda Release Cycle: 8.2 + #### Connectors Camunda 8 Connectors component is one of our applications which performs the integration with an external system. @@ -555,6 +657,8 @@ Then follow the [typical upgrade steps](#upgrading-where-identity-enabled). ### v8.0.13 +Camunda Release Cycle: 8.0 + If you installed Camunda 8 using Helm charts before `8.0.13`, you need to apply the following steps to handle the new Elasticsearch labels. As a prerequisite, make sure you have the Elasticsearch Helm repository added: diff --git a/docs/self-managed/installation/run-local/manual.md b/docs/self-managed/installation/run-local/manual.md index 7bd9e0f608..4778acf43d 100644 --- a/docs/self-managed/installation/run-local/manual.md +++ b/docs/self-managed/installation/run-local/manual.md @@ -134,6 +134,8 @@ If you _have_ deployed processes or created process instances, you'll see them o ![operate-dash-with-processes](../../installation/assets/operate-introduction.png) +To update Operate versions, visit the [guide to update guide](/self-managed/operational-guides/update-guide/introduction.md). + ## Run Tasklist To run Tasklist, execute the following commands: diff --git a/docs/self-managed/operate-deployment/updating-operate.md b/docs/self-managed/operate-deployment/updating-operate.md deleted file mode 100644 index c48f2e0d3f..0000000000 --- a/docs/self-managed/operate-deployment/updating-operate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: updating-operate -title: Updating Operate -description: "Follow these steps for a successful Operate version update." ---- - -When updating Operate versions, it's important to pay attention to a few points: - -- Every Operate version supports importing data for the current version and the previous one. For example, if you are running Operate `1.3`, Operate imports data from Zeebe `1.2` and `1.3`. -- Before updating the Operate version and skipping multiple minor versions, import all the data from previous versions. See the sections below for additional details. - -## Skipping multiple minor versions - -For example, let's assume a server running Operate version `1.0` wants to update to version `1.3`. - -Take the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1`. -2. Let Operate run for a few hours and verify if everything works as expected. -3. Repeat **Step 1** and **Step 2** to update to version `1.2`. -4. Update both Operate and Zeebe to version `1.3`. - -:::note -Depending on your amount of data, we recommend allowing a minor version to run for at least 24 hours before updating to the next version. -::: diff --git a/docs/self-managed/operational-guides/update-guide/840-to-850.md b/docs/self-managed/operational-guides/update-guide/840-to-850.md index 2e8e19c952..a3e43f39c0 100644 --- a/docs/self-managed/operational-guides/update-guide/840-to-850.md +++ b/docs/self-managed/operational-guides/update-guide/840-to-850.md @@ -6,6 +6,14 @@ description: "Review which adjustments must be made to migrate from Camunda 8.4. The following sections explain which adjustments must be made to migrate from Camunda 8.4.x to 8.5.x for each component. +## Helm chart + +:::caution Breaking changes +The Camunda Helm chart v10.0.0 that comes with Camunda 8.5 has major changes in the values file structure. Update the values keys before starting the chart upgrade. +::: + +Carefully follow the [upgrade instructions](../../platform-deployment/helm-kubernetes/upgrade.md#v1000) to upgrade from Camunda Helm chart v9.x.x to Camunda Helm chart v10.x.x. + ## Zeebe ### Deprecated broker health checks diff --git a/docs/self-managed/operational-guides/update-guide/introduction.md b/docs/self-managed/operational-guides/update-guide/introduction.md index 07143ddcff..4715d9a75c 100644 --- a/docs/self-managed/operational-guides/update-guide/introduction.md +++ b/docs/self-managed/operational-guides/update-guide/introduction.md @@ -10,6 +10,8 @@ application or server installation from one Camunda 8 version to the other. When updating from one minor version to the next, you do not need to update to each **patch** version along the way. However, do not skip **minor** versions when updating. ::: +Depending on your amount of data, run a minor version for at least 24 hours before updating to the next version. + :::note Versions prior to Camunda 8 are listed below and identified as Camunda Cloud versions. ::: diff --git a/docs/self-managed/zeebe-deployment/operations/network-ports.md b/docs/self-managed/zeebe-deployment/operations/network-ports.md index 90cf942741..1c2acae0c5 100644 --- a/docs/self-managed/zeebe-deployment/operations/network-ports.md +++ b/docs/self-managed/zeebe-deployment/operations/network-ports.md @@ -62,7 +62,7 @@ Config file Environment Variables ZEEBE_BROKER_NETWORK_COMMANDAPI_PORT = 26501 ZEEBE_BROKER_NETWORK_INTERNALAPI_PORT = 26501 - ZEEBE_BROKER_NETWORK_MONITOIRNGAPI_PORT = 26501 + ZEEBE_BROKER_NETWORK_MONITORINGAPI_PORT = 26501 ``` diff --git a/howtos/documentation-guidelines.md b/howtos/documentation-guidelines.md index 073101d8af..15cb06c1d4 100644 --- a/howtos/documentation-guidelines.md +++ b/howtos/documentation-guidelines.md @@ -211,7 +211,7 @@ After the proposed change is finished open a GitHub PR and assign at least one r - Connectors: @camunda/connectors - Self-Managed/Distribution: @camunda/distribution - InfEx: @camunda/infex-docs-dri -- Identity: @ultraschuppi +- Identity: @dlavrenuek - DevEx: @akeller - Product Management: @felix-mueller - Documentation: @christinaausley diff --git a/static/.htaccess b/static/.htaccess index c4412b4a22..d78c835e4b 100644 --- a/static/.htaccess +++ b/static/.htaccess @@ -3,8 +3,22 @@ RewriteEngine on RewriteCond %{SERVER_PORT} !^443$ RewriteRule (.*) https://%{SERVER_NAME}/$1 [R=301,L] -# Consolidate SM troubleshooting pages (next only) +# Remove updating-operate pages +RewriteRule ^docs/components/operate/userguide/updating-operate/?$ /docs/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/next/components/operate/userguide/updating-operate/?$ /docs/next/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.4/components/operate/userguide/updating-operate/?$ /docs/8.4/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.3/components/operate/userguide/updating-operate/?$ /docs/8.3/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.2/components/operate/userguide/updating-operate/?$ /docs/8.2/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.1/components/operate/userguide/updating-operate/?$ /docs/8.1/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] + +RewriteRule ^docs/self-managed/operate-deployment/updating-operate/?$ /docs/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/next/self-managed/operate-deployment/updating-operate/?$ /docs/next/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.4/self-managed/operate-deployment/updating-operate/?$ /docs/8.4/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.3/self-managed/operate-deployment/updating-operate/?$ /docs/8.3/self-managed/operational-guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.2/self-managed/operate-deployment/updating-operate/?$ /docs/8.2/guides/update-guide/introduction/$1 [R=301,L] +RewriteRule ^docs/8.1/self-managed/operate-deployment/updating-operate/?$ /docs/8.1/guides/update-guide/introduction/$1 [R=301,L] +# Consolidate SM troubleshooting pages (next only) RewriteRule ^docs/next/self-managed/platform-deployment/troubleshooting/?$ /docs/next/self-managed/operational-guides/troubleshooting/$1 [R=301,L] # Rename whitelist to allowlist diff --git a/versioned_docs/version-1.3/components/operate/userguide/updating-operate.md b/versioned_docs/version-1.3/components/operate/userguide/updating-operate.md deleted file mode 100644 index 5c45330864..0000000000 --- a/versioned_docs/version-1.3/components/operate/userguide/updating-operate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: updating-operate-cloud -title: Updating Operate -description: Instructions on how to update your Operate ---- - -When updating Operate versions, it is important to pay attention to few points: - -* Every Operate version, supports importing data for the current version and the previous one. For example: if you are running Operate `1.3`, your Operate imports data from Zeebe `1.2` and `1.3`. -* When wanting to update Operate version and skip multiple minor versions, make sure to import all the data from previous versions before (see below) - - -## Skipping multiple minor versions - -Let's assume the following scenario: -A server running Operate version `1.0` wants to update to version `1.3`. - -We recommend to follow the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1` -2. Let Operate run for some hours* and verify if everything works as expected -3. Repeat steps `1` and `2` while updating to version `1.2` (before you jump to `1.3`) -4. Then you should be safe to update both Operate and Zeebe to version `1.3` - -NOTE: * Depends on your amount of data, we recommend you let each minor version run for at least 24h before updating to the next one \ No newline at end of file diff --git a/versioned_docs/version-1.3/self-managed/operate-deployment/install-and-start.md b/versioned_docs/version-1.3/self-managed/operate-deployment/install-and-start.md index 4eb79f4845..969e918088 100644 --- a/versioned_docs/version-1.3/self-managed/operate-deployment/install-and-start.md +++ b/versioned_docs/version-1.3/self-managed/operate-deployment/install-and-start.md @@ -110,4 +110,4 @@ If you _have_ deployed processes or created process instances, you'll see them o ## Update Operate -To update Operate versions, visit the [user guide](../../components/operate/userguide/updating-operate.md). \ No newline at end of file +To update Operate versions, visit the [update guide](/guides/update-guide/introduction.md). \ No newline at end of file diff --git a/versioned_docs/version-1.3/self-managed/operate-deployment/updating-operate.md b/versioned_docs/version-1.3/self-managed/operate-deployment/updating-operate.md deleted file mode 100644 index 2bd67f34e5..0000000000 --- a/versioned_docs/version-1.3/self-managed/operate-deployment/updating-operate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: updating-operate -title: Updating Operate -description: "Follow these steps for a successful Operate version update." ---- - -When updating Operate versions, it's important to pay attention to a few points: - -* Every Operate version supports importing data for the current version and the previous one. For example, if you are running Operate `1.3`, Operate imports data from Zeebe `1.2` and `1.3`. -* Before updating the Operate version and skipping multiple minor versions, import all the data from previous versions. See the sections below for additional details. - -## Skipping multiple minor versions - -For example, let's assume a server running Operate version `1.0` wants to update to version `1.3`. - -Take the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1`. -2. Let Operate run for a few hours and verify if everything works as expected. -3. Repeat **Step 1** and **Step 2** to update to version `1.2`. -4. Update both Operate and Zeebe to version `1.3`. - -:::note -Depending on your amount of data, we recommend allowing a minor version to run for at least 24 hours before updating to the next version. -::: diff --git a/versioned_docs/version-8.1/components/operate/userguide/updating-operate.md b/versioned_docs/version-8.1/components/operate/userguide/updating-operate.md deleted file mode 100644 index aff735c9fc..0000000000 --- a/versioned_docs/version-8.1/components/operate/userguide/updating-operate.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: updating-operate-cloud -title: Updating Operate -description: Instructions on how to update your Operate ---- - -When updating Operate versions, it is important to pay attention to few points: - -- Every Operate version, supports importing data for the current version and the previous one. For example: if you are running Operate `1.3`, your Operate imports data from Zeebe `1.2` and `1.3`. -- When wanting to update Operate version and skip multiple minor versions, make sure to import all the data from previous versions before (see below) - -## Skipping multiple minor versions - -Let's assume the following scenario: -A server running Operate version `1.0` wants to update to version `1.3`. - -We recommend to follow the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1` -2. Let Operate run for some hours\* and verify if everything works as expected -3. Repeat steps `1` and `2` while updating to version `1.2` (before you jump to `1.3`) -4. Then you should be safe to update both Operate and Zeebe to version `1.3` - -NOTE: \* Depends on your amount of data, we recommend you let each minor version run for at least 24h before updating to the next one diff --git a/versioned_docs/version-8.1/guides/update-guide/introduction.md b/versioned_docs/version-8.1/guides/update-guide/introduction.md index d3121438dd..ebc483c538 100644 --- a/versioned_docs/version-8.1/guides/update-guide/introduction.md +++ b/versioned_docs/version-8.1/guides/update-guide/introduction.md @@ -6,6 +6,8 @@ title: Introduction These documents guide you through the process of updating your Camunda 8 application or server installation from one Camunda 8 version to the other. +Depending on your amount of data, run a minor version for at least 24 hours before updating to the next version. + You can find guides on how to update your Connector runtimes to a newer version of the [Connector SDK](/components/connectors/custom-built-connectors/connector-sdk.md) in the **Connectors** section. diff --git a/versioned_docs/version-8.1/self-managed/operate-deployment/updating-operate.md b/versioned_docs/version-8.1/self-managed/operate-deployment/updating-operate.md deleted file mode 100644 index c48f2e0d3f..0000000000 --- a/versioned_docs/version-8.1/self-managed/operate-deployment/updating-operate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: updating-operate -title: Updating Operate -description: "Follow these steps for a successful Operate version update." ---- - -When updating Operate versions, it's important to pay attention to a few points: - -- Every Operate version supports importing data for the current version and the previous one. For example, if you are running Operate `1.3`, Operate imports data from Zeebe `1.2` and `1.3`. -- Before updating the Operate version and skipping multiple minor versions, import all the data from previous versions. See the sections below for additional details. - -## Skipping multiple minor versions - -For example, let's assume a server running Operate version `1.0` wants to update to version `1.3`. - -Take the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1`. -2. Let Operate run for a few hours and verify if everything works as expected. -3. Repeat **Step 1** and **Step 2** to update to version `1.2`. -4. Update both Operate and Zeebe to version `1.3`. - -:::note -Depending on your amount of data, we recommend allowing a minor version to run for at least 24 hours before updating to the next version. -::: diff --git a/versioned_docs/version-8.1/self-managed/platform-deployment/manual.md b/versioned_docs/version-8.1/self-managed/platform-deployment/manual.md index d991380028..7cbb52a921 100644 --- a/versioned_docs/version-8.1/self-managed/platform-deployment/manual.md +++ b/versioned_docs/version-8.1/self-managed/platform-deployment/manual.md @@ -132,7 +132,7 @@ If you _have_ deployed processes or created process instances, you'll see them o ![operate-dash-with-processes](assets/operate-introduction_light.png) -To update Operate versions, visit the [guide to update Operate](../../components/operate/userguide/updating-operate.md). +To update Operate versions, visit the [guide to update guide](/guides/update-guide/introduction.md). ## Run Tasklist diff --git a/versioned_docs/version-8.1/self-managed/zeebe-deployment/operations/network-ports.md b/versioned_docs/version-8.1/self-managed/zeebe-deployment/operations/network-ports.md index 4abf3668ef..03f5c61012 100644 --- a/versioned_docs/version-8.1/self-managed/zeebe-deployment/operations/network-ports.md +++ b/versioned_docs/version-8.1/self-managed/zeebe-deployment/operations/network-ports.md @@ -55,5 +55,5 @@ Config file Environment Variables ZEEBE_BROKER_NETWORK_COMMANDAPI_PORT = 26501 ZEEBE_BROKER_NETWORK_INTERNALAPI_PORT = 26501 - ZEEBE_BROKER_NETWORK_MONITOIRNGAPI_PORT = 26501 + ZEEBE_BROKER_NETWORK_MONITORINGAPI_PORT = 26501 ``` diff --git a/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png b/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png index de3b4209e0..fc315f12bb 100644 Binary files a/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png and b/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png differ diff --git a/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack.md b/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack.md index 6eb94cb1fd..04bdeecf13 100644 --- a/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack.md +++ b/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack.md @@ -9,83 +9,84 @@ tags: - Maven --- -If you don't have special architecture requirements, we recommend using SaaS following the proposed greenfield stack. - :::caution Camunda 8 -This best practice targets Camunda 8 only! If you look for Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). +This best practice targets Camunda 8. For Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). ::: -## The greenfield stack +Our greenfield stack recommendation is a result of extensive discussions and evaluations. While not the only option, it is a solid choice if there are no specific reasons to choose an alternative. -We like to give one greenfield stack recommendation, which is the stack you can simply use if there is no reason against it. And while we went through long and detailed discussions to come to this recommendation, it _doesn't_ mean that it is necessarily superior to alternative stacks. You can still feel confident if you go down another route (see below for alternative options). +Your choice of programming language should align with your team's expertise; we suggest Java or JavaScript for their broad applicability and support, and have outlined the Java greenfield stack below with Camunda 8 SaaS. -The stack looks pretty similar in various programming language. Please use the programnming language your team is most familiar with. If in doubt, use Java or JavaScript. +## The Java greenfield stack -### The Java greenfield stack +:::caution +[Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) is currently a community-maintained project. +::: ![greenfield stack architecture diagram](deciding-about-your-stack-assets/greenfield-architecture.png) -Use the following stack: +This architecture diagram illustrates the flow of requests from a user's browser through Camunda SaaS, where workflows and decisions are orchestrated. The process then moves to the Spring Boot application, which is responsible for executing business logic, handling database interactions with PostgreSQL, and managing various components such as custom REST endpoints, BPMN/DMN definitions, and external task workers. -1. Use [Camunda 8 SaaS](https://signup.camunda.com/accounts?utm_source=docs.camunda.io&utm_medium=referral) and create a cluster there +### Why this stack? -1. Build your process solution project as a [Spring Boot](https://spring.io/projects/spring-boot) application, using the [Spring Zeebe](/docs/apis-tools/community-clients/spring.md). +- SaaS simplifies workflow engine integration. +- Spring Boot is widely adopted for Java application development. +- Flexible for both on-premise and cloud environments. -1. Use [Maven](https://maven.apache.org/) as a build tool. +Discover more in our [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or the [Spring Zeebe instructions](https://github.com/camunda-community-hub/spring-zeebe). -1. Use your favorite IDE, for example Visual Studio Code, IntelliJ or Eclipse. +### Set up the stack -1. Use [Open JDK 17](https://jdk.java.net/17/) as Java runtime. +For a Java-based setup using Camunda 8 SaaS and Spring Boot, use the following stack: -1. Model the processes with the [Camunda Modeler](https://camunda.org/download/modeler/). +#### Camunda 8 SaaS account and cluster -1. Add your process models and all Java code to the project. +If you're new to Camunda SaaS, check out our [getting started guide](/guides/introduction-to-camunda-8.md#getting-started) to set up your environment. -To run the process application _in production_: +After signing up, create a cluster by following [creating a cluster in Camunda 8](/guides/create-cluster.md), which provides step-by-step instructions on setting up a new cluster in the Camunda 8 environment. -3. Run the process application by copying the `jar` file to the server and start it with `java -jar YourProcessApplication.jar`. This is most often done via Docker. +#### Spring Boot -See our [example application](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot). +Develop your own process solutions as [Spring Boot](https://spring.io/projects/spring-boot) applications. This involves setting up a new Spring Boot project, either manually or using tools like [Spring Initializr](https://start.spring.io/). -We decided on this stack for the following reasons: +Integrate [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) into the Spring Boot project by adding necessary dependencies to the project’s pom.xml file and configuring the application to use Camunda services. -- All components are open source and easily available. -- SaaS is the easiest way to consume capabilities like a workflow engine. -- Spring Boot is currently the most adopted way of building Java applications. -- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud. +#### Maven -Take a look at the [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or follow the instructions in [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) to get started. +Use [Maven](https://maven.apache.org/) to manage the build lifecycle of the application. -## Polyglot stacks +#### IDE selection -You can develop process solutions as described with Java above also in any other programming language. Simply use the [existing language clients / SDKs](../../../apis-tools/working-with-apis-tools.md) for doing this. +Select an Integrated Development Environment (IDE) that supports Java development, Maven, and Spring Boot. Frequently used options include Visual Studio Code, IntelliJ IDEA, or Eclipse. - +Install and use OpenJDK 17 as your Java runtime environment. Download it from the [official JDK 17 download page](https://jdk.java.net/17/). -## Customize your stack +#### Modeling + +Download and use Camunda Modeler for designing and modeling business processes. Modeler is available [here](https://camunda.org/download/modeler/). + +#### Code integration -### Running Camunda 8 Self-Managed +Incorporate all Java code and BPMN process models into the Spring Boot project, ensuring that they are structured correctly and referenced properly within the application. -You can also run Camunda 8 self-managed on your own Kubernetes cluster. Details can be found in the [deployment docs](../../../self-managed/platform-deployment/overview.md). +### Run the process application: -While there [exists a Docker Compose configuration](/docs/self-managed/platform-deployment/docker/) to run Camunda 8 locally, this is not meant to be used for production, but rather to quickly startup components on a developer machine to be able to play around. +To run the process application, transfer the `jar` to the desired server. -### Modeling for executable processes +Start the application using the command `java -jar YourProcessApplication.jar`. Frequently, this deployment process is managed through Docker for ease of use. + +For a practical implementation, refer to our [example application on GitHub](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot), which demonstrates a typical setup for a Spring Boot-based process application with Camunda. + + + +## Customize your stack -We distinguish two different roles modeling in BPM projects: +### Polyglot stacks -- _Process developers_ develop an executable process implementation. Process developers implementing solutions with Camunda must use Camunda Modeler to model executable processes, edit technical attributes, and manage and version (e.g. in Git or SVN) the resulting (XML) files as part of the development project. +You can develop process solutions as described with Java above also in any other programming language, including JavaScript. Use the [existing language clients and SDKs](/apis-tools/working-with-apis-tools.md) for doing this. -- _Process analysts_ capture the operational know how about a process. For this part of the work, it is possible to use a different tool than Camunda Modeler. +### Run Camunda 8 Self-Managed -| | Camunda Modeler | Third-Party Modeler (BPMN Standard Compliant) | Third-Party Modeler (Non-Compliant to Standard) | -| ------------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | -| Roundtrip in between process analysts and developers possible | ✔ | ✔ (Carefully check level of BPMN compliance - the [Model Interchange Working Group](http://bpmn-miwg.github.io/bpmn-miwg-tools/) can serve as a first starting point | | -| Use for process analysts | ✔ | ✔ | | -| Use for process developers | ✔ | | | -| Use when | You do not have a BPMN standard compliant modeling tool already rolled out. | You already rolled out a BPMN tool with a standard compliancy sufficient for roundtrip. | Try to avoid | -| | [Download](https://camunda.org/download/modeler/) | [e.g. Cawemo](http://cawemo.com/) | | +Run Camunda 8 on your Kubernetes cluster. For local development, a [Docker Compose configuration is available](/self-managed/platform-deployment/docker.md), though not for production use. Learn more in the [deployment docs](/self-managed/platform-deployment/overview.md). diff --git a/versioned_docs/version-8.2/components/operate/userguide/updating-operate.md b/versioned_docs/version-8.2/components/operate/userguide/updating-operate.md deleted file mode 100644 index aff735c9fc..0000000000 --- a/versioned_docs/version-8.2/components/operate/userguide/updating-operate.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: updating-operate-cloud -title: Updating Operate -description: Instructions on how to update your Operate ---- - -When updating Operate versions, it is important to pay attention to few points: - -- Every Operate version, supports importing data for the current version and the previous one. For example: if you are running Operate `1.3`, your Operate imports data from Zeebe `1.2` and `1.3`. -- When wanting to update Operate version and skip multiple minor versions, make sure to import all the data from previous versions before (see below) - -## Skipping multiple minor versions - -Let's assume the following scenario: -A server running Operate version `1.0` wants to update to version `1.3`. - -We recommend to follow the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1` -2. Let Operate run for some hours\* and verify if everything works as expected -3. Repeat steps `1` and `2` while updating to version `1.2` (before you jump to `1.3`) -4. Then you should be safe to update both Operate and Zeebe to version `1.3` - -NOTE: \* Depends on your amount of data, we recommend you let each minor version run for at least 24h before updating to the next one diff --git a/versioned_docs/version-8.2/guides/update-guide/introduction.md b/versioned_docs/version-8.2/guides/update-guide/introduction.md index ac5976f662..9286fa01ff 100644 --- a/versioned_docs/version-8.2/guides/update-guide/introduction.md +++ b/versioned_docs/version-8.2/guides/update-guide/introduction.md @@ -10,6 +10,8 @@ application or server installation from one Camunda 8 version to the other. When updating from one minor version to the next, you do not need to update to each **patch** version along the way. However, do not skip **minor** versions when updating. ::: +Depending on your amount of data, run a minor version for at least 24 hours before updating to the next version. + You can find guides on how to update your Connector runtimes to a newer version of the [Connector SDK](/components/connectors/custom-built-connectors/connector-sdk.md) in the **Connectors** section. diff --git a/versioned_docs/version-8.2/self-managed/operate-deployment/updating-operate.md b/versioned_docs/version-8.2/self-managed/operate-deployment/updating-operate.md deleted file mode 100644 index c48f2e0d3f..0000000000 --- a/versioned_docs/version-8.2/self-managed/operate-deployment/updating-operate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: updating-operate -title: Updating Operate -description: "Follow these steps for a successful Operate version update." ---- - -When updating Operate versions, it's important to pay attention to a few points: - -- Every Operate version supports importing data for the current version and the previous one. For example, if you are running Operate `1.3`, Operate imports data from Zeebe `1.2` and `1.3`. -- Before updating the Operate version and skipping multiple minor versions, import all the data from previous versions. See the sections below for additional details. - -## Skipping multiple minor versions - -For example, let's assume a server running Operate version `1.0` wants to update to version `1.3`. - -Take the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1`. -2. Let Operate run for a few hours and verify if everything works as expected. -3. Repeat **Step 1** and **Step 2** to update to version `1.2`. -4. Update both Operate and Zeebe to version `1.3`. - -:::note -Depending on your amount of data, we recommend allowing a minor version to run for at least 24 hours before updating to the next version. -::: diff --git a/versioned_docs/version-8.2/self-managed/platform-deployment/manual.md b/versioned_docs/version-8.2/self-managed/platform-deployment/manual.md index 80ce5217f5..937223ee04 100644 --- a/versioned_docs/version-8.2/self-managed/platform-deployment/manual.md +++ b/versioned_docs/version-8.2/self-managed/platform-deployment/manual.md @@ -132,7 +132,7 @@ If you _have_ deployed processes or created process instances, you'll see them o ![operate-dash-with-processes](assets/operate-introduction_light.png) -To update Operate versions, visit the [guide to update Operate](../../components/operate/userguide/updating-operate.md). +To update Operate versions, visit the [guide to update guide](/guides/update-guide/introduction.md). ## Run Tasklist diff --git a/versioned_docs/version-8.2/self-managed/zeebe-deployment/operations/network-ports.md b/versioned_docs/version-8.2/self-managed/zeebe-deployment/operations/network-ports.md index 4abf3668ef..03f5c61012 100644 --- a/versioned_docs/version-8.2/self-managed/zeebe-deployment/operations/network-ports.md +++ b/versioned_docs/version-8.2/self-managed/zeebe-deployment/operations/network-ports.md @@ -55,5 +55,5 @@ Config file Environment Variables ZEEBE_BROKER_NETWORK_COMMANDAPI_PORT = 26501 ZEEBE_BROKER_NETWORK_INTERNALAPI_PORT = 26501 - ZEEBE_BROKER_NETWORK_MONITOIRNGAPI_PORT = 26501 + ZEEBE_BROKER_NETWORK_MONITORINGAPI_PORT = 26501 ``` diff --git a/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png b/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png index de3b4209e0..fc315f12bb 100644 Binary files a/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png and b/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png differ diff --git a/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack.md b/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack.md index 7ca81028c3..04bdeecf13 100644 --- a/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack.md +++ b/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack.md @@ -9,83 +9,84 @@ tags: - Maven --- -If you don't have special architecture requirements, we recommend using SaaS following the proposed greenfield stack. - :::caution Camunda 8 -This best practice targets Camunda 8 only! If you look for Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). +This best practice targets Camunda 8. For Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). ::: -## The greenfield stack +Our greenfield stack recommendation is a result of extensive discussions and evaluations. While not the only option, it is a solid choice if there are no specific reasons to choose an alternative. -We like to give one greenfield stack recommendation, which is the stack you can simply use if there is no reason against it. And while we went through long and detailed discussions to come to this recommendation, it _doesn't_ mean that it is necessarily superior to alternative stacks. You can still feel confident if you go down another route (note below for alternative options). +Your choice of programming language should align with your team's expertise; we suggest Java or JavaScript for their broad applicability and support, and have outlined the Java greenfield stack below with Camunda 8 SaaS. -The stack looks pretty similar in various programming language. Please use the programming language your team is most familiar with. If in doubt, use Java or JavaScript. +## The Java greenfield stack -### The Java greenfield stack +:::caution +[Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) is currently a community-maintained project. +::: ![greenfield stack architecture diagram](deciding-about-your-stack-assets/greenfield-architecture.png) -Use the following stack: +This architecture diagram illustrates the flow of requests from a user's browser through Camunda SaaS, where workflows and decisions are orchestrated. The process then moves to the Spring Boot application, which is responsible for executing business logic, handling database interactions with PostgreSQL, and managing various components such as custom REST endpoints, BPMN/DMN definitions, and external task workers. -1. Use [Camunda 8 SaaS](https://signup.camunda.com/accounts?utm_source=docs.camunda.io&utm_medium=referral) and create a cluster there +### Why this stack? -1. Build your process solution project as a [Spring Boot](https://spring.io/projects/spring-boot) application, using the [Spring Zeebe](/docs/apis-tools/community-clients/spring.md). +- SaaS simplifies workflow engine integration. +- Spring Boot is widely adopted for Java application development. +- Flexible for both on-premise and cloud environments. -1. Use [Maven](https://maven.apache.org/) as a build tool. +Discover more in our [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or the [Spring Zeebe instructions](https://github.com/camunda-community-hub/spring-zeebe). -1. Use your favorite IDE, for example Visual Studio Code, IntelliJ or Eclipse. +### Set up the stack -1. Use [Open JDK 17](https://jdk.java.net/17/) as Java runtime. +For a Java-based setup using Camunda 8 SaaS and Spring Boot, use the following stack: -1. Model the processes with the [Camunda Modeler](https://camunda.org/download/modeler/). +#### Camunda 8 SaaS account and cluster -1. Add your process models and all Java code to the project. +If you're new to Camunda SaaS, check out our [getting started guide](/guides/introduction-to-camunda-8.md#getting-started) to set up your environment. -To run the process application _in production_: +After signing up, create a cluster by following [creating a cluster in Camunda 8](/guides/create-cluster.md), which provides step-by-step instructions on setting up a new cluster in the Camunda 8 environment. -3. Run the process application by copying the `jar` file to the server and start it with `java -jar YourProcessApplication.jar`. This is most often done via Docker. +#### Spring Boot -Refer to our [example application](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot). +Develop your own process solutions as [Spring Boot](https://spring.io/projects/spring-boot) applications. This involves setting up a new Spring Boot project, either manually or using tools like [Spring Initializr](https://start.spring.io/). -We decided on this stack for the following reasons: +Integrate [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) into the Spring Boot project by adding necessary dependencies to the project’s pom.xml file and configuring the application to use Camunda services. -- All components are open source and easily available. -- SaaS is the easiest way to consume capabilities like a workflow engine. -- Spring Boot is currently the most adopted way of building Java applications. -- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud. +#### Maven -Take a look at the [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or follow the instructions in [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) to get started. +Use [Maven](https://maven.apache.org/) to manage the build lifecycle of the application. -## Polyglot stacks +#### IDE selection -You can develop process solutions as described with Java above also in any other programming language. Simply use the [existing language clients / SDKs](../../../apis-tools/working-with-apis-tools.md) for doing this. +Select an Integrated Development Environment (IDE) that supports Java development, Maven, and Spring Boot. Frequently used options include Visual Studio Code, IntelliJ IDEA, or Eclipse. - +Install and use OpenJDK 17 as your Java runtime environment. Download it from the [official JDK 17 download page](https://jdk.java.net/17/). -## Customize your stack +#### Modeling + +Download and use Camunda Modeler for designing and modeling business processes. Modeler is available [here](https://camunda.org/download/modeler/). + +#### Code integration -### Running Camunda 8 self-managed +Incorporate all Java code and BPMN process models into the Spring Boot project, ensuring that they are structured correctly and referenced properly within the application. -You can also run Camunda 8 self-managed on your own Kubernetes cluster. Details can be found in the [deployment docs](../../../self-managed/platform-deployment/overview.md). +### Run the process application: -While there [exists a Docker Compose configuration](/docs/self-managed/platform-deployment/docker/) to run Camunda 8 locally, this is not meant to be used for production, but rather to quickly startup components on a developer machine to be able to play around. +To run the process application, transfer the `jar` to the desired server. -### Modeling for executable processes +Start the application using the command `java -jar YourProcessApplication.jar`. Frequently, this deployment process is managed through Docker for ease of use. + +For a practical implementation, refer to our [example application on GitHub](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot), which demonstrates a typical setup for a Spring Boot-based process application with Camunda. + + + +## Customize your stack -We distinguish two different roles modeling in BPM projects: +### Polyglot stacks -- _Process developers_ develop an executable process implementation. Process developers implementing solutions with Camunda must use Camunda Modeler to model executable processes, edit technical attributes, and manage and version (e.g. in Git or SVN) the resulting (XML) files as part of the development project. +You can develop process solutions as described with Java above also in any other programming language, including JavaScript. Use the [existing language clients and SDKs](/apis-tools/working-with-apis-tools.md) for doing this. -- _Process analysts_ capture the operational know how about a process. For this part of the work, it is possible to use a different tool than Camunda Modeler. +### Run Camunda 8 Self-Managed -| | Camunda Modeler | Third-Party Modeler (BPMN Standard Compliant) | Third-Party Modeler (Non-Compliant to Standard) | -| ------------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | -| Roundtrip in between process analysts and developers possible | ✔ | ✔ (Carefully check level of BPMN compliance - the [Model Interchange Working Group](http://bpmn-miwg.github.io/bpmn-miwg-tools/) can serve as a first starting point | | -| Use for process analysts | ✔ | ✔ | | -| Use for process developers | ✔ | | | -| Use when | You do not have a BPMN standard compliant modeling tool already rolled out. | You already rolled out a BPMN tool with a standard compliancy sufficient for roundtrip. | Try to avoid | -| | [Download](https://camunda.org/download/modeler/) | [e.g. Cawemo](http://cawemo.com/) | | +Run Camunda 8 on your Kubernetes cluster. For local development, a [Docker Compose configuration is available](/self-managed/platform-deployment/docker.md), though not for production use. Learn more in the [deployment docs](/self-managed/platform-deployment/overview.md). diff --git a/versioned_docs/version-8.3/components/modeler/web-modeler/collaboration.md b/versioned_docs/version-8.3/components/modeler/web-modeler/collaboration.md index acecbd4654..a848fc92b3 100644 --- a/versioned_docs/version-8.3/components/modeler/web-modeler/collaboration.md +++ b/versioned_docs/version-8.3/components/modeler/web-modeler/collaboration.md @@ -28,7 +28,7 @@ There are four roles with different levels of access rights that can be assigned - **Commenter**: the user cannot edit folders or diagrams nor invite users, but can view and leave comments on diagrams. - **Viewer**: The user cannot edit folders or diagrams nor leave comments, but can only view diagrams. -Additionally, the **Owner** of the organization has special privileges to do administrative tasks in **super-user mode**. +Additionally, the **Owner** and **Admins** of the organization have special privileges to do administrative tasks in **super-user mode**. #### Super-user mode @@ -36,15 +36,15 @@ Additionally, the **Owner** of the organization has special privileges to do adm Super-user mode is not yet available in Web Modeler Self-Managed. ::: -Super-user mode is only available to the **Owner** of the organization and can be enabled via the user menu in Web Modeler: +Super-user mode is only available to the **Owner** and **Admins** of the organization and can be enabled via the user menu in Web Modeler:

Enable super-user mode in Web Modeler's user menu

The main purpose of this mode is to assign collaborators to orphaned projects (which have no collaborators). Ordinarily, these projects would not be accessible or visible to any users. -When the **Owner** activates super-user mode, they are temporarily granted **Project Admin** access to all projects -of the organization. This allows the **Owner** to assign collaborators to orphaned projects and gives the **Owner** +When the **Owner** or an **Admin** activates super-user mode, they are temporarily granted **Project Admin** access to all projects +of the organization. This allows them to assign collaborators to orphaned projects and gives them full access when none of the ordinary collaborators are available. ### Inviting users to projects diff --git a/versioned_docs/version-8.3/components/operate/userguide/updating-operate.md b/versioned_docs/version-8.3/components/operate/userguide/updating-operate.md deleted file mode 100644 index aff735c9fc..0000000000 --- a/versioned_docs/version-8.3/components/operate/userguide/updating-operate.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: updating-operate-cloud -title: Updating Operate -description: Instructions on how to update your Operate ---- - -When updating Operate versions, it is important to pay attention to few points: - -- Every Operate version, supports importing data for the current version and the previous one. For example: if you are running Operate `1.3`, your Operate imports data from Zeebe `1.2` and `1.3`. -- When wanting to update Operate version and skip multiple minor versions, make sure to import all the data from previous versions before (see below) - -## Skipping multiple minor versions - -Let's assume the following scenario: -A server running Operate version `1.0` wants to update to version `1.3`. - -We recommend to follow the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1` -2. Let Operate run for some hours\* and verify if everything works as expected -3. Repeat steps `1` and `2` while updating to version `1.2` (before you jump to `1.3`) -4. Then you should be safe to update both Operate and Zeebe to version `1.3` - -NOTE: \* Depends on your amount of data, we recommend you let each minor version run for at least 24h before updating to the next one diff --git a/versioned_docs/version-8.3/self-managed/operate-deployment/updating-operate.md b/versioned_docs/version-8.3/self-managed/operate-deployment/updating-operate.md deleted file mode 100644 index c48f2e0d3f..0000000000 --- a/versioned_docs/version-8.3/self-managed/operate-deployment/updating-operate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: updating-operate -title: Updating Operate -description: "Follow these steps for a successful Operate version update." ---- - -When updating Operate versions, it's important to pay attention to a few points: - -- Every Operate version supports importing data for the current version and the previous one. For example, if you are running Operate `1.3`, Operate imports data from Zeebe `1.2` and `1.3`. -- Before updating the Operate version and skipping multiple minor versions, import all the data from previous versions. See the sections below for additional details. - -## Skipping multiple minor versions - -For example, let's assume a server running Operate version `1.0` wants to update to version `1.3`. - -Take the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1`. -2. Let Operate run for a few hours and verify if everything works as expected. -3. Repeat **Step 1** and **Step 2** to update to version `1.2`. -4. Update both Operate and Zeebe to version `1.3`. - -:::note -Depending on your amount of data, we recommend allowing a minor version to run for at least 24 hours before updating to the next version. -::: diff --git a/versioned_docs/version-8.3/self-managed/operational-guides/update-guide/introduction.md b/versioned_docs/version-8.3/self-managed/operational-guides/update-guide/introduction.md index 0f0b9838e9..1ee72d83ea 100644 --- a/versioned_docs/version-8.3/self-managed/operational-guides/update-guide/introduction.md +++ b/versioned_docs/version-8.3/self-managed/operational-guides/update-guide/introduction.md @@ -10,6 +10,8 @@ application or server installation from one Camunda 8 version to the other. When updating from one minor version to the next, you do not need to update to each **patch** version along the way. However, do not skip **minor** versions when updating. ::: +Depending on your amount of data, run a minor version for at least 24 hours before updating to the next version. + :::note Versions prior to Camunda 8 are listed below and identified as Camunda Cloud versions. ::: diff --git a/versioned_docs/version-8.3/self-managed/platform-deployment/manual.md b/versioned_docs/version-8.3/self-managed/platform-deployment/manual.md index b81d48ce97..60642234d2 100644 --- a/versioned_docs/version-8.3/self-managed/platform-deployment/manual.md +++ b/versioned_docs/version-8.3/self-managed/platform-deployment/manual.md @@ -134,7 +134,7 @@ If you _have_ deployed processes or created process instances, you'll see them o ![operate-dash-with-processes](../../images/operate/operate-introduction.png) -To update Operate versions, visit the [guide to update Operate](../../components/operate/userguide/updating-operate.md). +To update Operate versions, visit the [guide to update guide](/self-managed/operational-guides/update-guide/introduction.md). ## Run Tasklist diff --git a/versioned_docs/version-8.3/self-managed/zeebe-deployment/operations/network-ports.md b/versioned_docs/version-8.3/self-managed/zeebe-deployment/operations/network-ports.md index 4abf3668ef..03f5c61012 100644 --- a/versioned_docs/version-8.3/self-managed/zeebe-deployment/operations/network-ports.md +++ b/versioned_docs/version-8.3/self-managed/zeebe-deployment/operations/network-ports.md @@ -55,5 +55,5 @@ Config file Environment Variables ZEEBE_BROKER_NETWORK_COMMANDAPI_PORT = 26501 ZEEBE_BROKER_NETWORK_INTERNALAPI_PORT = 26501 - ZEEBE_BROKER_NETWORK_MONITOIRNGAPI_PORT = 26501 + ZEEBE_BROKER_NETWORK_MONITORINGAPI_PORT = 26501 ``` diff --git a/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png b/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png index de3b4209e0..fc315f12bb 100644 Binary files a/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png and b/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-assets/greenfield-architecture.png differ diff --git a/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack.md b/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack.md index 7ca81028c3..04bdeecf13 100644 --- a/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack.md +++ b/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack.md @@ -9,83 +9,84 @@ tags: - Maven --- -If you don't have special architecture requirements, we recommend using SaaS following the proposed greenfield stack. - :::caution Camunda 8 -This best practice targets Camunda 8 only! If you look for Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). +This best practice targets Camunda 8. For Camunda 7, please refer to [Deciding about your Camunda 7 stack](../deciding-about-your-stack-c7/). ::: -## The greenfield stack +Our greenfield stack recommendation is a result of extensive discussions and evaluations. While not the only option, it is a solid choice if there are no specific reasons to choose an alternative. -We like to give one greenfield stack recommendation, which is the stack you can simply use if there is no reason against it. And while we went through long and detailed discussions to come to this recommendation, it _doesn't_ mean that it is necessarily superior to alternative stacks. You can still feel confident if you go down another route (note below for alternative options). +Your choice of programming language should align with your team's expertise; we suggest Java or JavaScript for their broad applicability and support, and have outlined the Java greenfield stack below with Camunda 8 SaaS. -The stack looks pretty similar in various programming language. Please use the programming language your team is most familiar with. If in doubt, use Java or JavaScript. +## The Java greenfield stack -### The Java greenfield stack +:::caution +[Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) is currently a community-maintained project. +::: ![greenfield stack architecture diagram](deciding-about-your-stack-assets/greenfield-architecture.png) -Use the following stack: +This architecture diagram illustrates the flow of requests from a user's browser through Camunda SaaS, where workflows and decisions are orchestrated. The process then moves to the Spring Boot application, which is responsible for executing business logic, handling database interactions with PostgreSQL, and managing various components such as custom REST endpoints, BPMN/DMN definitions, and external task workers. -1. Use [Camunda 8 SaaS](https://signup.camunda.com/accounts?utm_source=docs.camunda.io&utm_medium=referral) and create a cluster there +### Why this stack? -1. Build your process solution project as a [Spring Boot](https://spring.io/projects/spring-boot) application, using the [Spring Zeebe](/docs/apis-tools/community-clients/spring.md). +- SaaS simplifies workflow engine integration. +- Spring Boot is widely adopted for Java application development. +- Flexible for both on-premise and cloud environments. -1. Use [Maven](https://maven.apache.org/) as a build tool. +Discover more in our [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or the [Spring Zeebe instructions](https://github.com/camunda-community-hub/spring-zeebe). -1. Use your favorite IDE, for example Visual Studio Code, IntelliJ or Eclipse. +### Set up the stack -1. Use [Open JDK 17](https://jdk.java.net/17/) as Java runtime. +For a Java-based setup using Camunda 8 SaaS and Spring Boot, use the following stack: -1. Model the processes with the [Camunda Modeler](https://camunda.org/download/modeler/). +#### Camunda 8 SaaS account and cluster -1. Add your process models and all Java code to the project. +If you're new to Camunda SaaS, check out our [getting started guide](/guides/introduction-to-camunda-8.md#getting-started) to set up your environment. -To run the process application _in production_: +After signing up, create a cluster by following [creating a cluster in Camunda 8](/guides/create-cluster.md), which provides step-by-step instructions on setting up a new cluster in the Camunda 8 environment. -3. Run the process application by copying the `jar` file to the server and start it with `java -jar YourProcessApplication.jar`. This is most often done via Docker. +#### Spring Boot -Refer to our [example application](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot). +Develop your own process solutions as [Spring Boot](https://spring.io/projects/spring-boot) applications. This involves setting up a new Spring Boot project, either manually or using tools like [Spring Initializr](https://start.spring.io/). -We decided on this stack for the following reasons: +Integrate [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) into the Spring Boot project by adding necessary dependencies to the project’s pom.xml file and configuring the application to use Camunda services. -- All components are open source and easily available. -- SaaS is the easiest way to consume capabilities like a workflow engine. -- Spring Boot is currently the most adopted way of building Java applications. -- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud. +#### Maven -Take a look at the [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or follow the instructions in [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) to get started. +Use [Maven](https://maven.apache.org/) to manage the build lifecycle of the application. -## Polyglot stacks +#### IDE selection -You can develop process solutions as described with Java above also in any other programming language. Simply use the [existing language clients / SDKs](../../../apis-tools/working-with-apis-tools.md) for doing this. +Select an Integrated Development Environment (IDE) that supports Java development, Maven, and Spring Boot. Frequently used options include Visual Studio Code, IntelliJ IDEA, or Eclipse. - +Install and use OpenJDK 17 as your Java runtime environment. Download it from the [official JDK 17 download page](https://jdk.java.net/17/). -## Customize your stack +#### Modeling + +Download and use Camunda Modeler for designing and modeling business processes. Modeler is available [here](https://camunda.org/download/modeler/). + +#### Code integration -### Running Camunda 8 self-managed +Incorporate all Java code and BPMN process models into the Spring Boot project, ensuring that they are structured correctly and referenced properly within the application. -You can also run Camunda 8 self-managed on your own Kubernetes cluster. Details can be found in the [deployment docs](../../../self-managed/platform-deployment/overview.md). +### Run the process application: -While there [exists a Docker Compose configuration](/docs/self-managed/platform-deployment/docker/) to run Camunda 8 locally, this is not meant to be used for production, but rather to quickly startup components on a developer machine to be able to play around. +To run the process application, transfer the `jar` to the desired server. -### Modeling for executable processes +Start the application using the command `java -jar YourProcessApplication.jar`. Frequently, this deployment process is managed through Docker for ease of use. + +For a practical implementation, refer to our [example application on GitHub](https://github.com/camunda-community-hub/camunda-cloud-examples/tree/main/twitter-review-java-springboot), which demonstrates a typical setup for a Spring Boot-based process application with Camunda. + + + +## Customize your stack -We distinguish two different roles modeling in BPM projects: +### Polyglot stacks -- _Process developers_ develop an executable process implementation. Process developers implementing solutions with Camunda must use Camunda Modeler to model executable processes, edit technical attributes, and manage and version (e.g. in Git or SVN) the resulting (XML) files as part of the development project. +You can develop process solutions as described with Java above also in any other programming language, including JavaScript. Use the [existing language clients and SDKs](/apis-tools/working-with-apis-tools.md) for doing this. -- _Process analysts_ capture the operational know how about a process. For this part of the work, it is possible to use a different tool than Camunda Modeler. +### Run Camunda 8 Self-Managed -| | Camunda Modeler | Third-Party Modeler (BPMN Standard Compliant) | Third-Party Modeler (Non-Compliant to Standard) | -| ------------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | -| Roundtrip in between process analysts and developers possible | ✔ | ✔ (Carefully check level of BPMN compliance - the [Model Interchange Working Group](http://bpmn-miwg.github.io/bpmn-miwg-tools/) can serve as a first starting point | | -| Use for process analysts | ✔ | ✔ | | -| Use for process developers | ✔ | | | -| Use when | You do not have a BPMN standard compliant modeling tool already rolled out. | You already rolled out a BPMN tool with a standard compliancy sufficient for roundtrip. | Try to avoid | -| | [Download](https://camunda.org/download/modeler/) | [e.g. Cawemo](http://cawemo.com/) | | +Run Camunda 8 on your Kubernetes cluster. For local development, a [Docker Compose configuration is available](/self-managed/platform-deployment/docker.md), though not for production use. Learn more in the [deployment docs](/self-managed/platform-deployment/overview.md). diff --git a/versioned_docs/version-8.4/components/modeler/web-modeler/collaboration.md b/versioned_docs/version-8.4/components/modeler/web-modeler/collaboration.md index acecbd4654..a848fc92b3 100644 --- a/versioned_docs/version-8.4/components/modeler/web-modeler/collaboration.md +++ b/versioned_docs/version-8.4/components/modeler/web-modeler/collaboration.md @@ -28,7 +28,7 @@ There are four roles with different levels of access rights that can be assigned - **Commenter**: the user cannot edit folders or diagrams nor invite users, but can view and leave comments on diagrams. - **Viewer**: The user cannot edit folders or diagrams nor leave comments, but can only view diagrams. -Additionally, the **Owner** of the organization has special privileges to do administrative tasks in **super-user mode**. +Additionally, the **Owner** and **Admins** of the organization have special privileges to do administrative tasks in **super-user mode**. #### Super-user mode @@ -36,15 +36,15 @@ Additionally, the **Owner** of the organization has special privileges to do adm Super-user mode is not yet available in Web Modeler Self-Managed. ::: -Super-user mode is only available to the **Owner** of the organization and can be enabled via the user menu in Web Modeler: +Super-user mode is only available to the **Owner** and **Admins** of the organization and can be enabled via the user menu in Web Modeler:

Enable super-user mode in Web Modeler's user menu

The main purpose of this mode is to assign collaborators to orphaned projects (which have no collaborators). Ordinarily, these projects would not be accessible or visible to any users. -When the **Owner** activates super-user mode, they are temporarily granted **Project Admin** access to all projects -of the organization. This allows the **Owner** to assign collaborators to orphaned projects and gives the **Owner** +When the **Owner** or an **Admin** activates super-user mode, they are temporarily granted **Project Admin** access to all projects +of the organization. This allows them to assign collaborators to orphaned projects and gives them full access when none of the ordinary collaborators are available. ### Inviting users to projects diff --git a/versioned_docs/version-8.4/self-managed/operate-deployment/updating-operate.md b/versioned_docs/version-8.4/self-managed/operate-deployment/updating-operate.md deleted file mode 100644 index c48f2e0d3f..0000000000 --- a/versioned_docs/version-8.4/self-managed/operate-deployment/updating-operate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: updating-operate -title: Updating Operate -description: "Follow these steps for a successful Operate version update." ---- - -When updating Operate versions, it's important to pay attention to a few points: - -- Every Operate version supports importing data for the current version and the previous one. For example, if you are running Operate `1.3`, Operate imports data from Zeebe `1.2` and `1.3`. -- Before updating the Operate version and skipping multiple minor versions, import all the data from previous versions. See the sections below for additional details. - -## Skipping multiple minor versions - -For example, let's assume a server running Operate version `1.0` wants to update to version `1.3`. - -Take the steps below: - -### Progressively update - -1. Update Operate and Zeebe to version `1.1`. -2. Let Operate run for a few hours and verify if everything works as expected. -3. Repeat **Step 1** and **Step 2** to update to version `1.2`. -4. Update both Operate and Zeebe to version `1.3`. - -:::note -Depending on your amount of data, we recommend allowing a minor version to run for at least 24 hours before updating to the next version. -::: diff --git a/versioned_docs/version-8.4/self-managed/operational-guides/update-guide/introduction.md b/versioned_docs/version-8.4/self-managed/operational-guides/update-guide/introduction.md index 07143ddcff..4715d9a75c 100644 --- a/versioned_docs/version-8.4/self-managed/operational-guides/update-guide/introduction.md +++ b/versioned_docs/version-8.4/self-managed/operational-guides/update-guide/introduction.md @@ -10,6 +10,8 @@ application or server installation from one Camunda 8 version to the other. When updating from one minor version to the next, you do not need to update to each **patch** version along the way. However, do not skip **minor** versions when updating. ::: +Depending on your amount of data, run a minor version for at least 24 hours before updating to the next version. + :::note Versions prior to Camunda 8 are listed below and identified as Camunda Cloud versions. ::: diff --git a/versioned_docs/version-8.4/self-managed/platform-deployment/manual.md b/versioned_docs/version-8.4/self-managed/platform-deployment/manual.md index 9e10cfd50c..18adda8f8f 100644 --- a/versioned_docs/version-8.4/self-managed/platform-deployment/manual.md +++ b/versioned_docs/version-8.4/self-managed/platform-deployment/manual.md @@ -134,7 +134,7 @@ If you _have_ deployed processes or created process instances, you'll see them o ![operate-dash-with-processes](../../images/operate/operate-introduction.png) -To update Operate versions, visit the [guide to update Operate](/docs/self-managed/operate-deployment/updating-operate.md). +To update Operate versions, visit the [guide to update guide](/self-managed/operational-guides/update-guide/introduction.md). ## Run Tasklist diff --git a/versioned_docs/version-8.4/self-managed/zeebe-deployment/operations/network-ports.md b/versioned_docs/version-8.4/self-managed/zeebe-deployment/operations/network-ports.md index 90cf942741..1c2acae0c5 100644 --- a/versioned_docs/version-8.4/self-managed/zeebe-deployment/operations/network-ports.md +++ b/versioned_docs/version-8.4/self-managed/zeebe-deployment/operations/network-ports.md @@ -62,7 +62,7 @@ Config file Environment Variables ZEEBE_BROKER_NETWORK_COMMANDAPI_PORT = 26501 ZEEBE_BROKER_NETWORK_INTERNALAPI_PORT = 26501 - ZEEBE_BROKER_NETWORK_MONITOIRNGAPI_PORT = 26501 + ZEEBE_BROKER_NETWORK_MONITORINGAPI_PORT = 26501 ```