From f9b1f28b98032aeebc8af12c66e008c408cc9267 Mon Sep 17 00:00:00 2001 From: Christina Ausley Date: Mon, 7 Oct 2024 08:58:58 -0400 Subject: [PATCH] clean up docs typos --- docs/apis-tools/spring-zeebe-sdk/configuration.md | 2 +- docs/apis-tools/testing/connectors.md | 2 +- .../architecture/deciding-about-your-stack-c7.md | 4 ++-- .../development/invoking-services-from-the-process-c7.md | 4 ++-- docs/components/modeler/bpmn/user-tasks/user-tasks.md | 2 +- .../architecture/deciding-about-your-stack-c7.md | 2 +- .../architecture/deciding-about-your-stack-c7.md | 4 ++-- .../development/invoking-services-from-the-process-c7.md | 2 +- .../components/modeler/bpmn/user-tasks/user-tasks.md | 2 +- .../architecture/deciding-about-your-stack-c7.md | 4 ++-- .../development/invoking-services-from-the-process-c7.md | 4 ++-- .../components/modeler/bpmn/user-tasks/user-tasks.md | 2 +- .../architecture/deciding-about-your-stack-c7.md | 4 ++-- .../development/invoking-services-from-the-process-c7.md | 4 ++-- .../components/modeler/bpmn/user-tasks/user-tasks.md | 2 +- .../version-8.5/apis-tools/spring-zeebe-sdk/configuration.md | 2 +- .../architecture/deciding-about-your-stack-c7.md | 4 ++-- .../development/invoking-services-from-the-process-c7.md | 4 ++-- .../components/modeler/bpmn/user-tasks/user-tasks.md | 2 +- 19 files changed, 28 insertions(+), 28 deletions(-) diff --git a/docs/apis-tools/spring-zeebe-sdk/configuration.md b/docs/apis-tools/spring-zeebe-sdk/configuration.md index 7ef0ae2c5f..b4bfe5f0bf 100644 --- a/docs/apis-tools/spring-zeebe-sdk/configuration.md +++ b/docs/apis-tools/spring-zeebe-sdk/configuration.md @@ -170,7 +170,7 @@ public void handleJobFoo(final JobClient client, final ActivatedJob job) { } ``` -Ideally, you **don't** use blocking behavior like `send().join()`, as this is a blocking call to wait for the issues command to be executed on the workflow engine. While this is very straightforward to use and produces easy-to-read code, blocking code is limited in terms of scalability. +Ideally, you **don't** use blocking behavior like `send().join()`, as this is a blocking call to wait for the issued command to be executed on the workflow engine. While this is very straightforward to use and produces easy-to-read code, blocking code is limited in terms of scalability. This is why the worker above showed a different pattern (using `exceptionally`). Often, you might also want to use the `whenComplete` callback: diff --git a/docs/apis-tools/testing/connectors.md b/docs/apis-tools/testing/connectors.md index 80ac6ea8a7..0355263e2d 100644 --- a/docs/apis-tools/testing/connectors.md +++ b/docs/apis-tools/testing/connectors.md @@ -197,7 +197,7 @@ public class MyProcessTest { :::tip You might need to wrap the invocation of the Connector in a retry loop, for example, by using [Awaitility](http://www.awaitility.org/). -There can be a delay between verifying that the Connnectors event is active and opening the Connectors inbound subscription. +There can be a delay between verifying that the Connectors event is active and opening the Connectors inbound subscription. ::: ## Custom Connectors diff --git a/docs/components/best-practices/architecture/deciding-about-your-stack-c7.md b/docs/components/best-practices/architecture/deciding-about-your-stack-c7.md index 0c0f34cf47..787506396a 100644 --- a/docs/components/best-practices/architecture/deciding-about-your-stack-c7.md +++ b/docs/components/best-practices/architecture/deciding-about-your-stack-c7.md @@ -18,7 +18,7 @@ This best practice targets Camunda 7.x only! If you look for Camunda 8, please r ## The Java greenfield stack -The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglott environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). +The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglot environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). Use the following stack: @@ -135,7 +135,7 @@ Create your **development project** | Application point of view on process engine | Remote Server | Library | Library | | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote | | Programming language | Polyglot (Java, Node.js, C#, ...) | Java | Java | -| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. | +| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. | | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) | In essence, the general recommendation is: diff --git a/docs/components/best-practices/development/invoking-services-from-the-process-c7.md b/docs/components/best-practices/development/invoking-services-from-the-process-c7.md index 99f14460cc..4e05898330 100644 --- a/docs/components/best-practices/development/invoking-services-from-the-process-c7.md +++ b/docs/components/best-practices/development/invoking-services-from-the-process-c7.md @@ -47,7 +47,7 @@ Using external tasks comes with the following advantages: - **Temporal decoupling**: The pattern can replace a message queue between the service task (the "consumer") and the service implementation (the "provider"). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide. -- **Polyglott architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. +- **Polyglot architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually. @@ -121,7 +121,7 @@ One advantage of using Java delegates is that, if you develop in Java, this is a ### General recommendation -In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweights the following downsides of external tasks: +In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweighs the following downsides of external tasks: - A slightly increased complexity for Java projects, because they have to handle separate Java clients. - A slightly increased overhead compared to Java delegates, as all communication with the engine is remote, even if it runs in the same Java VM. diff --git a/docs/components/modeler/bpmn/user-tasks/user-tasks.md b/docs/components/modeler/bpmn/user-tasks/user-tasks.md index e00ed2cf75..b8ad444565 100644 --- a/docs/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/docs/components/modeler/bpmn/user-tasks/user-tasks.md @@ -49,7 +49,7 @@ the value of the `assignee` must be the user's **unique identifier**. The unique identifier depends on the authentication method used to login to Tasklist: - Camunda 8 (login with email, Google, GitHub): `email` -- Default Basic Auth (elasticsearch): `username` +- Default Basic Auth (Elasticsearch): `username` - IAM: `username` These assignees are not related to user restrictions, which is related to the visibility of the task in Tasklist for Self-Managed. For more information, see [Tasklist Authentication](/self-managed/tasklist-deployment/tasklist-authentication.md). diff --git a/versioned_docs/version-1.3/components/best-practices/architecture/deciding-about-your-stack-c7.md b/versioned_docs/version-1.3/components/best-practices/architecture/deciding-about-your-stack-c7.md index 85a6b364cb..bd509851cc 100644 --- a/versioned_docs/version-1.3/components/best-practices/architecture/deciding-about-your-stack-c7.md +++ b/versioned_docs/version-1.3/components/best-practices/architecture/deciding-about-your-stack-c7.md @@ -133,7 +133,7 @@ Create your **development project** | Application point of view on process engine | Remote Server | Library | Library | | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote | | Programming language | Polyglot (Java, NodeJs, C#, ...) | Java | Java | -| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. | +| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. | | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) | In essence, the general recommendation is: diff --git a/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-c7.md b/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-c7.md index 14637eb79a..efb5ae9af8 100644 --- a/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-c7.md +++ b/versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-c7.md @@ -18,7 +18,7 @@ This best practice targets Camunda 7.x only! If you look for Camunda 8, please r ## The Java greenfield stack -The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglott environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). +The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglot environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). Use the following stack: @@ -135,7 +135,7 @@ Create your **development project** | Application point of view on process engine | Remote Server | Library | Library | | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote | | Programming language | Polyglot (Java, Node.js, C#, ...) | Java | Java | -| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. | +| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. | | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) | In essence, the general recommendation is: diff --git a/versioned_docs/version-8.2/components/best-practices/development/invoking-services-from-the-process-c7.md b/versioned_docs/version-8.2/components/best-practices/development/invoking-services-from-the-process-c7.md index eb28764fff..0502baf58e 100644 --- a/versioned_docs/version-8.2/components/best-practices/development/invoking-services-from-the-process-c7.md +++ b/versioned_docs/version-8.2/components/best-practices/development/invoking-services-from-the-process-c7.md @@ -47,7 +47,7 @@ Using external tasks comes with the following advantages: - **Temporal decoupling**: The pattern can replace a message queue between the service task (the "consumer") and the service implementation (the "provider"). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide. -- **Polyglott architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. +- **Polyglot architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually. diff --git a/versioned_docs/version-8.2/components/modeler/bpmn/user-tasks/user-tasks.md b/versioned_docs/version-8.2/components/modeler/bpmn/user-tasks/user-tasks.md index 9c29b26a56..61ddcbffd2 100644 --- a/versioned_docs/version-8.2/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/versioned_docs/version-8.2/components/modeler/bpmn/user-tasks/user-tasks.md @@ -48,7 +48,7 @@ the value of the `assignee` must be the user's **unique identifier**. The unique identifier depends on the authentication method used to login to Tasklist: - Camunda 8 (login with email, Google, GitHub): `email` -- Default Basic Auth (elasticsearch): `username` +- Default Basic Auth (Elasticsearch): `username` - IAM: `username` :::note diff --git a/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-c7.md b/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-c7.md index 0c0f34cf47..787506396a 100644 --- a/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-c7.md +++ b/versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-c7.md @@ -18,7 +18,7 @@ This best practice targets Camunda 7.x only! If you look for Camunda 8, please r ## The Java greenfield stack -The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglott environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). +The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglot environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). Use the following stack: @@ -135,7 +135,7 @@ Create your **development project** | Application point of view on process engine | Remote Server | Library | Library | | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote | | Programming language | Polyglot (Java, Node.js, C#, ...) | Java | Java | -| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. | +| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. | | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) | In essence, the general recommendation is: diff --git a/versioned_docs/version-8.3/components/best-practices/development/invoking-services-from-the-process-c7.md b/versioned_docs/version-8.3/components/best-practices/development/invoking-services-from-the-process-c7.md index 99f14460cc..4e05898330 100644 --- a/versioned_docs/version-8.3/components/best-practices/development/invoking-services-from-the-process-c7.md +++ b/versioned_docs/version-8.3/components/best-practices/development/invoking-services-from-the-process-c7.md @@ -47,7 +47,7 @@ Using external tasks comes with the following advantages: - **Temporal decoupling**: The pattern can replace a message queue between the service task (the "consumer") and the service implementation (the "provider"). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide. -- **Polyglott architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. +- **Polyglot architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually. @@ -121,7 +121,7 @@ One advantage of using Java delegates is that, if you develop in Java, this is a ### General recommendation -In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweights the following downsides of external tasks: +In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweighs the following downsides of external tasks: - A slightly increased complexity for Java projects, because they have to handle separate Java clients. - A slightly increased overhead compared to Java delegates, as all communication with the engine is remote, even if it runs in the same Java VM. diff --git a/versioned_docs/version-8.3/components/modeler/bpmn/user-tasks/user-tasks.md b/versioned_docs/version-8.3/components/modeler/bpmn/user-tasks/user-tasks.md index 9c29b26a56..61ddcbffd2 100644 --- a/versioned_docs/version-8.3/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/versioned_docs/version-8.3/components/modeler/bpmn/user-tasks/user-tasks.md @@ -48,7 +48,7 @@ the value of the `assignee` must be the user's **unique identifier**. The unique identifier depends on the authentication method used to login to Tasklist: - Camunda 8 (login with email, Google, GitHub): `email` -- Default Basic Auth (elasticsearch): `username` +- Default Basic Auth (Elasticsearch): `username` - IAM: `username` :::note diff --git a/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-c7.md b/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-c7.md index 0c0f34cf47..787506396a 100644 --- a/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-c7.md +++ b/versioned_docs/version-8.4/components/best-practices/architecture/deciding-about-your-stack-c7.md @@ -18,7 +18,7 @@ This best practice targets Camunda 7.x only! If you look for Camunda 8, please r ## The Java greenfield stack -The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglott environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). +The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglot environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). Use the following stack: @@ -135,7 +135,7 @@ Create your **development project** | Application point of view on process engine | Remote Server | Library | Library | | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote | | Programming language | Polyglot (Java, Node.js, C#, ...) | Java | Java | -| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. | +| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. | | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) | In essence, the general recommendation is: diff --git a/versioned_docs/version-8.4/components/best-practices/development/invoking-services-from-the-process-c7.md b/versioned_docs/version-8.4/components/best-practices/development/invoking-services-from-the-process-c7.md index 99f14460cc..4e05898330 100644 --- a/versioned_docs/version-8.4/components/best-practices/development/invoking-services-from-the-process-c7.md +++ b/versioned_docs/version-8.4/components/best-practices/development/invoking-services-from-the-process-c7.md @@ -47,7 +47,7 @@ Using external tasks comes with the following advantages: - **Temporal decoupling**: The pattern can replace a message queue between the service task (the "consumer") and the service implementation (the "provider"). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide. -- **Polyglott architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. +- **Polyglot architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually. @@ -121,7 +121,7 @@ One advantage of using Java delegates is that, if you develop in Java, this is a ### General recommendation -In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweights the following downsides of external tasks: +In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweighs the following downsides of external tasks: - A slightly increased complexity for Java projects, because they have to handle separate Java clients. - A slightly increased overhead compared to Java delegates, as all communication with the engine is remote, even if it runs in the same Java VM. diff --git a/versioned_docs/version-8.4/components/modeler/bpmn/user-tasks/user-tasks.md b/versioned_docs/version-8.4/components/modeler/bpmn/user-tasks/user-tasks.md index cd7d69034e..b475a31143 100644 --- a/versioned_docs/version-8.4/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/versioned_docs/version-8.4/components/modeler/bpmn/user-tasks/user-tasks.md @@ -66,7 +66,7 @@ the value of the `assignee` must be the user's **unique identifier**. The unique identifier depends on the authentication method used to login to Tasklist: - Camunda 8 (login with email, Google, GitHub): `email` -- Default Basic Auth (elasticsearch): `username` +- Default Basic Auth (Elasticsearch): `username` - IAM: `username` These assignees are not related to user restrictions, which is related to the visibility of the task in Tasklist for Self-Managed. For more information, see [Tasklist Authentication](/self-managed/tasklist-deployment/tasklist-authentication.md). diff --git a/versioned_docs/version-8.5/apis-tools/spring-zeebe-sdk/configuration.md b/versioned_docs/version-8.5/apis-tools/spring-zeebe-sdk/configuration.md index f146dfcc1f..4e39d88af5 100644 --- a/versioned_docs/version-8.5/apis-tools/spring-zeebe-sdk/configuration.md +++ b/versioned_docs/version-8.5/apis-tools/spring-zeebe-sdk/configuration.md @@ -166,7 +166,7 @@ public void handleJobFoo(final JobClient client, final ActivatedJob job) { } ``` -Ideally, you **don't** use blocking behavior like `send().join()`, as this is a blocking call to wait for the issues command to be executed on the workflow engine. While this is very straightforward to use and produces easy-to-read code, blocking code is limited in terms of scalability. +Ideally, you **don't** use blocking behavior like `send().join()`, as this is a blocking call to wait for the issued command to be executed on the workflow engine. While this is very straightforward to use and produces easy-to-read code, blocking code is limited in terms of scalability. This is why the worker above showed a different pattern (using `exceptionally`). Often, you might also want to use the `whenComplete` callback: diff --git a/versioned_docs/version-8.5/components/best-practices/architecture/deciding-about-your-stack-c7.md b/versioned_docs/version-8.5/components/best-practices/architecture/deciding-about-your-stack-c7.md index 0c0f34cf47..787506396a 100644 --- a/versioned_docs/version-8.5/components/best-practices/architecture/deciding-about-your-stack-c7.md +++ b/versioned_docs/version-8.5/components/best-practices/architecture/deciding-about-your-stack-c7.md @@ -18,7 +18,7 @@ This best practice targets Camunda 7.x only! If you look for Camunda 8, please r ## The Java greenfield stack -The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglott environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). +The greenfield stack is pretty similar for various languages. This section described the currently a recommendation for Java developers. If you use different programming languages (like .NET or JavaScript), we recommend looking at Camunda 8, which supports polyglot environments better. The greenfield recommendation has recently changed. So if the recommendation below is surprising to you, you might want to check [this blog post](https://blog.bernd-ruecker.com/moving-from-embedded-to-remote-workflow-engines-8472992cc371). Use the following stack: @@ -135,7 +135,7 @@ Create your **development project** | Application point of view on process engine | Remote Server | Library | Library | | Possible communication types with services | Remote | Java InVM, Remote | Java InVM, Remote | | Programming language | Polyglot (Java, Node.js, C#, ...) | Java | Java | -| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to seperate engine installation from application development. | +| Use when | **Default**, if there is no reason against it. Especially if your architecture or applications are not Java based. | You want a single deployment including the engine. | You use a supported application server and prefer to separate engine installation from application development. | | | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#embedded-process-engine) | [Learn More](https://docs.camunda.org/manual/latest/introduction/architecture/#shared-container-managed-process-engine) | In essence, the general recommendation is: diff --git a/versioned_docs/version-8.5/components/best-practices/development/invoking-services-from-the-process-c7.md b/versioned_docs/version-8.5/components/best-practices/development/invoking-services-from-the-process-c7.md index 99f14460cc..d46abdcd87 100644 --- a/versioned_docs/version-8.5/components/best-practices/development/invoking-services-from-the-process-c7.md +++ b/versioned_docs/version-8.5/components/best-practices/development/invoking-services-from-the-process-c7.md @@ -47,7 +47,7 @@ Using external tasks comes with the following advantages: - **Temporal decoupling**: The pattern can replace a message queue between the service task (the "consumer") and the service implementation (the "provider"). It can eliminate the need for operating a dedicated message bus while keeping the decoupling that messaging would provide. -- **Polyglott architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. +- **Poyglot architectures**: The pattern can be used to integrate .NET based services, for example, when it might not be that easy to write Java delegates to call them. Service implementations are possible in any language that can be used to interact with a REST API. - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually. @@ -121,7 +121,7 @@ One advantage of using Java delegates is that, if you develop in Java, this is a ### General recommendation -In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweights the following downsides of external tasks: +In general, we _recommend to use external tasks_ to apply a general architecture and mindset, that allows to [leverage Camunda 8 easier](/guides/migrating-from-camunda-7/migration-readiness.md#prepare-for-smooth-migrations). This typically outweighs the following downsides of external tasks: - A slightly increased complexity for Java projects, because they have to handle separate Java clients. - A slightly increased overhead compared to Java delegates, as all communication with the engine is remote, even if it runs in the same Java VM. diff --git a/versioned_docs/version-8.5/components/modeler/bpmn/user-tasks/user-tasks.md b/versioned_docs/version-8.5/components/modeler/bpmn/user-tasks/user-tasks.md index 176bfaddd9..7f7d2d4881 100644 --- a/versioned_docs/version-8.5/components/modeler/bpmn/user-tasks/user-tasks.md +++ b/versioned_docs/version-8.5/components/modeler/bpmn/user-tasks/user-tasks.md @@ -49,7 +49,7 @@ the value of the `assignee` must be the user's **unique identifier**. The unique identifier depends on the authentication method used to login to Tasklist: - Camunda 8 (login with email, Google, GitHub): `email` -- Default Basic Auth (elasticsearch): `username` +- Default Basic Auth (Elasticsearch): `username` - IAM: `username` These assignees are not related to user restrictions, which is related to the visibility of the task in Tasklist for Self-Managed. For more information, see [Tasklist Authentication](/self-managed/tasklist-deployment/tasklist-authentication.md).