dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update Zeebe to version 1.0 (#1486) 

* Update Zeebe to version 1.0

* Supported Release Info and Upgrade Path for v1.2 (#1494)

* Supported Release Info and Upgrade Path for v1.2

* Update support-release-policy.md

* Update daprdocs/content/en/operations/support/support-release-policy.md

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Add documentation for the job related metadata and custom headers

* Adding K8s versions table (#1521)

* Adding table of kubernetes versions

* Updating intro

* Fix incorrect postgresql connection string example (#1524)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Update docs on using Codespaces with Dapr repos (#1522)

* Update docs on using Codespaces with Dapr repos

* Move codespaces.md under the Contributing topic

* Update daprdocs/content/en/contributing/codespaces.md

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Fix two typos (#1526)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Update chinese content (#1527)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Updated to fix deprecated helm chart location (#1528)

The `https://kubernetes-charts.storage.googleapis.com/` location is no longer used, so this change updates this, the command to install, and the missing update step that will cause the install to fail if an update was never done after adding the location.

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* nr_consul_typo fixed malformed yaml (#1532)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Fix typo in azure-keyvault-managed-identity.md (#1541)

* Fix custom middleware sample code interface implementation error (#1539)

Fix custom middleware sample code interface implementation error, interface function declare error.

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Fix the file name of secrets json (#1546)

* Tech writing touch-ups (#1555)

* Tech writing touch-ups (#1556)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Tech writing touch-ups (#1557)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Tech writing touch-ups (#1558)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Tech writing touch-ups (#1560)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Tech writing touch-ups (#1559)

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

* Ignore intellij link that isn't resolvable (#1564)

* Update issue templates (#1563)

* Update issue templates

* Add needs-triage

* Updating PubSub documentation to remove slave wording (#1565)

* Updating PubSub documentation to remove slave

Bitnami has updated their Redis Helm chart to change redis-slave to redis-replicas. I am updating the documentation for PubSub to reflect this change and avoid confusion for any readers.

* Removing more instances of Redis slave naming

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>

Co-authored-by: Aaron Crawfis <Aaron.Crawfis@microsoft.com>
Co-authored-by: Bernd Verst <berndverst@users.noreply.github.com>
Co-authored-by: Mark Fussell <mfussell@microsoft.com>
Co-authored-by: Zonciu Liang <zonciu@zonciu.com>
Co-authored-by: Simon Leet <31784195+CodeMonkeyLeet@users.noreply.github.com>
Co-authored-by: Maarten Mulders <mthmulders@users.noreply.github.com>
Co-authored-by: Newbe36524 <newbe36524@qq.com>
Co-authored-by: Steven Jenkins De Haro <20492442+StevenJDH@users.noreply.github.com>
Co-authored-by: Abdulaziz Elsheikh <abdulaziz.elsheikh@gmail.com>
Co-authored-by: Antonio Fiumanò <antoniofiumano@outlook.com>
Co-authored-by: li1234yun <li1234yun@163.com>
Co-authored-by: greenie-msft <56556602+greenie-msft@users.noreply.github.com>
Co-authored-by: voipengineer <voipengineer@users.noreply.github.com>
Co-authored-by: Evan Simkowitz <esimkowitz@users.noreply.github.com>
This commit is contained in:
Christian Kaps 2021-06-16 22:47:29 +02:00 committed by GitHub
parent 2a25c20812
commit ca63a62768
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 86 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
daprdocs/content/en/reference/components-reference/supported-bindings/_index.md
View File

@ -79,7 +79,7 @@ Table captions:
| [Azure SignalR]({{< ref signalr.md >}}) | | ✅ | Alpha | v1 | 1.0 |
| [Azure Storage Queues]({{< ref storagequeues.md >}}) | ✅ | ✅ | GA | v1 | 1.0 |
### Zeebe (Camunda)
### Zeebe (Camunda Cloud)
| Name | Input<br>Binding | Output<br>Binding | Status | Component version | Since |
|------|:----------------:|:-----------------:|--------| --------- | ---------- |

108
daprdocs/content/en/reference/components-reference/supported-bindings/zeebe-command.md
View File

@ -45,7 +45,7 @@ spec:
This component supports **output binding** with the following operations:
- `topology`
- `deploy-workflow`
- `deploy-process`
- `create-instance`
- `cancel-instance`
- `set-variables`
@ -66,7 +66,7 @@ https://stage.docs.zeebe.io/reference/grpc.html
The `topology` operation obtains the current topology of the cluster the gateway is part of.
To perform a `topology` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `topology` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -120,28 +120,25 @@ The response values are:
- `replicationFactor` - configured replication factor for this cluster
- `gatewayVersion` - gateway version
#### deploy-workflow
#### deploy-process
The `deploy-workflow` operation deploys a single workflow to Zeebe.
The `deploy-process` operation deploys a single process to Zeebe.
To perform a `deploy-workflow` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `deploy-process` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
"data": "YOUR_FILE_CONTENT",
"metadata": {
"fileName": "products-process.bpmn",
"fileType": "bpmn"
"fileName": "products-process.bpmn"
},
"operation": "deploy-workflow"
"operation": "deploy-process"
}
```
The metadata parameters are:
- `fileName` - the name of the workflow file
- `fileType` - (optional) the type of the file 'bpmn' or 'file'. If no type was given, the default will be recognized based on the file extension
'bpmn' for file extension .bpmn, for all other files it will be set to 'file'
- `fileName` - the name of the process file
##### Response
@ -150,11 +147,11 @@ The binding returns a JSON with the following response:
```json
{
"key": 2251799813687320,
"workflows": [
"processes": [
{
"bpmnProcessId": "products-process",
"version": 3,
"workflowKey": 2251799813685895,
"processDefinitionKey": 2251799813685895,
"resourceName": "products-process.bpmn"
}
]
@ -164,23 +161,23 @@ The binding returns a JSON with the following response:
The response values are:
- `key` - the unique key identifying the deployment
- `workflows` - a list of deployed workflows
- `processes` - a list of deployed processes
- `bpmnProcessId` - the bpmn process ID, as parsed during deployment; together with the version forms a unique identifier for a specific
workflow definition
process definition
- `version` - the assigned process version
- `workflowKey` - the assigned key, which acts as a unique identifier for this workflow
- `resourceName` - the resource name from which this workflow was parsed
- `processDefinitionKey` - the assigned key, which acts as a unique identifier for this process
- `resourceName` - the resource name from which this process was parsed
#### create-instance
The `create-instance` operation creates and starts an instance of the specified workflow. The workflow definition to use to create the instance can be
specified either using its unique key (as returned by the `deploy-workflow` operation), or using the BPMN process ID and a version.
The `create-instance` operation creates and starts an instance of the specified process. The process definition to use to create the instance can be
specified either using its unique key (as returned by the `deploy-process` operation), or using the BPMN process ID and a version.
Note that only workflows with none start events can be started through this command.
Note that only processes with none start events can be started through this command.
##### By BPMN process ID
To perform a `create-instance` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `create-instance` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -198,22 +195,22 @@ To perform a `create-instance` operation, invoke the Zeebe command binding with
The data parameters are:
- `bpmnProcessId` - the BPMN process ID of the workflow definition to instantiate
- `bpmnProcessId` - the BPMN process ID of the process definition to instantiate
- `version` - (optional, default: latest version) the version of the process to instantiate
- `variables` - (optional) JSON document that will instantiate the variables for the root variable scope of the
workflow instance; it must be a JSON object, as variables will be mapped in a
process instance; it must be a JSON object, as variables will be mapped in a
key-value fashion. e.g. { "a": 1, "b": 2 } will create two variables, named "a" and
"b" respectively, with their associated values. [{ "a": 1, "b": 2 }] would not be a
valid argument, as the root of the JSON document is an array and not an object
##### By workflow key
##### By process definition key
To perform a `create-instance` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `create-instance` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
"data": {
"workflowKey": 2251799813685895,
"processDefinitionKey": 2251799813685895,
"variables": {
"productId": "some-product-id",
"productName": "some-product-name",
@ -226,44 +223,43 @@ To perform a `create-instance` operation, invoke the Zeebe command binding with
The data parameters are:
- `workflowKey` - the unique key identifying the workflow definition to instantiate
- `variables` - (optional) JSON document that will instantiate the variables for the root variable scope of the
workflow instance; it must be a JSON object, as variables will be mapped in a
- `processDefinitionKey` - the unique key identifying the process definition to instantiate
- `variables` - (optional) JSON document that will instantiate the variables for the root variable scope of the
process instance; it must be a JSON object, as variables will be mapped in a
key-value fashion. e.g. { "a": 1, "b": 2 } will create two variables, named "a" and
"b" respectively, with their associated values. [{ "a": 1, "b": 2 }] would not be a
valid argument, as the root of the JSON document is an array and not an object
##### Response
The binding returns a JSON with the following response:
```json
{
"workflowKey": 2251799813685895,
"processDefinitionKey": 2251799813685895,
"bpmnProcessId": "products-process",
"version": 3,
"workflowInstanceKey": 2251799813687851
"processInstanceKey": 2251799813687851
}
```
The response values are:
- `workflowKey` - the key of the workflow definition which was used to create the workflow instance
- `bpmnProcessId` - the BPMN process ID of the workflow definition which was used to create the workflow instance
- `version` - the version of the workflow definition which was used to create the workflow instance
- `workflowInstanceKey` - the unique identifier of the created workflow instance
- `processDefinitionKey` - the key of the process definition which was used to create the process instance
- `bpmnProcessId` - the BPMN process ID of the process definition which was used to create the process instance
- `version` - the version of the process definition which was used to create the process instance
- `processInstanceKey` - the unique identifier of the created process instance
#### cancel-instance
The `cancel-instance` operation cancels a running workflow instance.
The `cancel-instance` operation cancels a running process instance.
To perform a `cancel-instance` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `cancel-instance` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
"data": {
"workflowInstanceKey": 2251799813687851
"processInstanceKey": 2251799813687851
},
"metadata": {},
"operation": "cancel-instance"
@ -272,7 +268,7 @@ To perform a `cancel-instance` operation, invoke the Zeebe command binding with
The data parameters are:
- `workflowInstanceKey` - the workflow instance key
- `processInstanceKey` - the process instance key
##### Response
@ -280,9 +276,9 @@ The binding does not return a response body.
#### set-variables
The `set-variables` operation creates or updates variables for an element instance (e.g. workflow instance, flow element instance).
The `set-variables` operation creates or updates variables for an element instance (e.g. process instance, flow element instance).
To perform a `set-variables` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `set-variables` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -301,7 +297,7 @@ To perform a `set-variables` operation, invoke the Zeebe command binding with a
The data parameters are:
- `elementInstanceKey` - the unique identifier of a particular element; can be the workflow instance key (as
- `elementInstanceKey` - the unique identifier of a particular element; can be the process instance key (as
obtained during instance creation), or a given element, such as a service task (see elementInstanceKey on the job message)
- `local` - (optional, default: `false`) if true, the variables will be merged strictly into the local scope (as indicated by
elementInstanceKey); this means the variables is not propagated to upper scopes.
@ -330,7 +326,7 @@ The response values are:
The `resolve-incident` operation resolves an incident.
To perform a `resolve-incident` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `resolve-incident` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -354,7 +350,7 @@ The binding does not return a response body.
The `publish-message` operation publishes a single message. Messages are published to specific partitions computed from their correlation keys.
To perform a `publish-message` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `publish-message` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -398,7 +394,7 @@ The response values are:
The `activate-jobs` operation iterates through all known partitions round-robin and activates up to the requested maximum and streams them back to
the client as they are activated.
To perform a `activate-jobs` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `activate-jobs` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -443,12 +439,12 @@ The response values are:
- `key` - the key, a unique identifier for the job
- `type` - the type of the job (should match what was requested)
- `workflowInstanceKey` - the job's workflow instance key
- `bpmnProcessId` - the bpmn process ID of the job workflow definition
- `workflowDefinitionVersion` - the version of the job workflow definition
- `workflowKey` - the key of the job workflow definition
- `processInstanceKey` - the job's process instance key
- `bpmnProcessId` - the bpmn process ID of the job process definition
- `processDefinitionVersion` - the version of the job process definition
- `processDefinitionKey` - the key of the job process definition
- `elementId` - the associated task element ID
- `elementInstanceKey` - the unique key identifying the associated task, unique within the scope of the workflow instance
- `elementInstanceKey` - the unique key identifying the associated task, unique within the scope of the process instance
- `customHeaders` - a set of custom headers defined during modelling; returned as a serialized JSON document
- `worker` - the name of the worker which activated this job
- `retries` - the amount of retries left to this job (should always be positive)
@ -459,7 +455,7 @@ The response values are:
The `complete-job` operation completes a job with the given payload, which allows completing the associated service task.
To perform a `complete-job` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `complete-job` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -491,7 +487,7 @@ The `fail-job` operation marks the job as failed; if the retries argument is pos
worker could try again to process it. If it is zero or negative however, an incident will be raised, tagged with the given errorMessage, and the
job will not be activatable until the incident is resolved.
To perform a `fail-job` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `fail-job` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -521,7 +517,7 @@ The binding does not return a response body.
The `update-job-retries` operation updates the number of retries a job has left. This is mostly useful for jobs that have run out of retries, should the
underlying problem be solved.
To perform a `update-job-retries` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `update-job-retries` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -546,9 +542,9 @@ The binding does not return a response body.
#### throw-error
The `throw-error` operation throw an error to indicate that a business error is occurred while processing the job. The error is identified
by an error code and is handled by an error catch event in the workflow with the same error code.
by an error code and is handled by an error catch event in the process with the same error code.
To perform a `throw-error` operation, invoke the Zeebe command binding with a `POST` method and the following JSON body:
To perform a `throw-error` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{

39
daprdocs/content/en/reference/components-reference/supported-bindings/zeebe-jobworker.md
View File

@ -73,14 +73,16 @@ This component supports **input** binding interfaces.
### Input binding
The Zeebe workflow engine handles the workflow state as also workflow variables which can be passed
on workflow instantiation or which can be updated or created during workflow execution. These variables
#### Variables
The Zeebe process engine handles the process state as also process variables which can be passed
on process instantiation or which can be updated or created during process execution. These variables
can be passed to a registered job worker by defining the variable names as comma-separated list in
the `fetchVariables` metadata field. The workflow engine will then pass these variables with its current
the `fetchVariables` metadata field. The process engine will then pass these variables with its current
values to the job worker implementation.
If the binding will register three variables `productId`, `productName` and `productKey` then the service will
be called with the following JSON:
If the binding will register three variables `productId`, `productName` and `productKey` then the worker will
be called with the following JSON body:
```json
{
@ -90,10 +92,35 @@ be called with the following JSON:
}
```
Note: if the `fetchVariables` metadata field will not be passed, all process variables will be passed to the worker.
#### Headers
The Zeebe process engine has the ability to pass custom task headers to a job worker. These headers can be defined for every
[service task](https://stage.docs.zeebe.io/bpmn-workflows/service-tasks/service-tasks.html). Task headers will be passed
by the binding as metadata (HTTP headers) to the job worker.
The binding will also pass the following job related variables as metadata. The values will be passed as string. The table contains also the
original data type so that it can be converted back to the equivalent data type in the used programming language for the worker.
| Metadata | Data type | Description |
|------------------------------------|-----------|-------------------------------------------------------------------------------------------------|
| X-Zeebe-Job-Key | int64 | The key, a unique identifier for the job |
| X-Zeebe-Job-Type | string | The type of the job (should match what was requested) |
| X-Zeebe-Process-Instance-Key | int64 | The job's process instance key |
| X-Zeebe-Bpmn-Process-Id | string | The bpmn process ID of the job process definition |
| X-Zeebe-Process-Definition-Version | int32 | The version of the job process definition |
| X-Zeebe-Process-Definition-Key | int64 | The key of the job process definition |
| X-Zeebe-Element-Id | string | The associated task element ID |
| X-Zeebe-Element-Instance-Key | int64 | The unique key identifying the associated task, unique within the scope of the process instance |
| X-Zeebe-Worker | string | The name of the worker which activated this job |
| X-Zeebe-Retries | int32 | The amount of retries left to this job (should always be positive) |
| X-Zeebe-Deadline | int64 | When the job can be activated again, sent as a UNIX epoch timestamp |
## Related links
- [Basic schema for a Dapr component]({{< ref component-schema >}})
- [Bindings building block]({{< ref bindings >}})
- [How-To: Trigger application with input binding]({{< ref howto-triggers.md >}})
- [How-To: Use bindings to interface with external resources]({{< ref howto-bindings.md >}})
- [Bindings API reference]({{< ref bindings_api.md >}})
- [Bindings API reference]({{< ref bindings_api.md >}})