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

Merge branch 'v1.12' into issue_3567

This commit is contained in:
Hannah Hunter 2023-09-18 12:14:17 -04:00 committed by GitHub
parent adbe4f7503 02f56a6a7e
commit 7186316808
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 245 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
daprdocs/content/en/operations/components/certification-lifecycle.md
View File

@ -48,6 +48,12 @@ All components start at the Alpha stage.
- The component contains a record of the conformance test result reviewed and approved by Dapr maintainers with specific components-contrib version
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases
{{% alert title="Note" color="primary" %}}
A component may skip the Beta stage and conformance test requirement per the discretion of the Maintainer if:
- The component is a binding
- The certification tests are comprehensive
{{% /alert %}}
### Stable
- The component must have component [certification tests](#certification-tests) validating functionality and resiliency

1
daprdocs/content/en/operations/support/support-preview-features.md
View File

@ -15,7 +15,6 @@ For CLI there is no explicit opt-in, just the version that this was first made a
| Feature | Description | Setting | Documentation | Version introduced |
| --- | --- | --- | --- | --- |
| **App Middleware** | Allow middleware components to be executed when making service-to-service calls | N/A | [App Middleware]({{<ref "middleware.md#app-middleware" >}}) | v1.9 |
| **Streaming for HTTP service invocation** | Enables (partial) support for using streams in HTTP service invocation; see below for more details. | `ServiceInvocationStreaming` | [Details]({{< ref "support-preview-features.md#streaming-for-http-service-invocation" >}}) | v1.10 |
| **Pluggable components** | Allows creating self-hosted gRPC-based components written in any language that supports gRPC. The following component APIs are supported: State stores, Pub/sub, Bindings | N/A | [Pluggable components concept]({{<ref "components-concept#pluggable-components" >}})| v1.9 |
| **Multi-App Run** | Configure multiple Dapr applications from a single configuration file and run from a single command | `dapr run -f` | [Multi-App Run]({{< ref multi-app-dapr-run.md >}}) | v1.10 |

69
daprdocs/content/en/reference/api/metadata_api.md
View File

@ -75,6 +75,7 @@ Name | Type
---- | ---- | -----------
id | string | Application ID
runtimeVersion | string | Version of the Dapr runtime
enabledFeatures | string[] | List of features enabled by Dapr Configuration, see https://docs.dapr.io/operations/configuration/preview-features/
actors | [Metadata API Response Registered Actor](#metadataapiresponseactor)[] | A json encoded array of registered actors metadata.
extended.attributeName | string | List of custom attributes as key-value pairs, where key is the attribute name.
components | [Metadata API Response Component](#metadataapiresponsecomponent)[] | A json encoded array of loaded components metadata.
@ -111,14 +112,14 @@ Name | Type | Description
pubsubname | string | Name of the pub/sub.
topic | string | Topic name.
metadata | object | Metadata associated with the subscription.
rules | [Metadata API Response Subscription Rules](metadataapiresponsesubscriptionrules)[] | List of rules associated with the subscription.
rules | [Metadata API Response Subscription Rules](#metadataapiresponsesubscriptionrules)[] | List of rules associated with the subscription.
deadLetterTopic | string | Dead letter topic name.
<a id="metadataapiresponsesubscriptionrules"></a>**Metadata API Response Subscription Rules**
Name | Type | Description
---- | ---- | -----------
match | string | CEL expression to match the message.
match | string | CEL expression to match the message, see https://docs.dapr.io/developing-applications/building-blocks/pubsub/howto-route-messages/#common-expression-language-cel
path | string | Path to route the message if the match expression is true.
<a id="metadataapiresponseappconnectionproperties"></a>**Metadata API Response AppConnectionProperties**
@ -143,15 +144,13 @@ healthThreshold | integer | Max number of failed health probes before the app is
### Examples
Note: This example is based on the Actor sample provided in the [Dapr SDK for Python](https://github.com/dapr/python-sdk/tree/master/examples/demo_actor).
```shell
curl http://localhost:3500/v1.0/metadata
```
```json
{
"id": "demo-actor",
"id": "myApp",
"runtimeVersion": "1.12.0",
"enabledFeatures": [
"ServiceInvocationStreaming"
@ -178,6 +177,27 @@ curl http://localhost:3500/v1.0/metadata
]
}
],
"httpEndpoints": [
{
"name": "my-backend-api"
}
],
"subscriptions": [
{
"pubsubname": "pubsub",
"topic": "orders",
"deadLetterTopic": "",
"metadata": {
"ttlInSeconds": "30"
},
"rules": [
{
"match": "%!s(<nil>)",
"path": "orders"
}
]
}
],
"extended": {
"appCommand": "uvicorn --port 3000 demo_actor_service:app",
"appPID": "98121",
@ -187,7 +207,12 @@ curl http://localhost:3500/v1.0/metadata
"appConnectionProperties": {
"port": 3000,
"protocol": "http",
"channelAddress": "127.0.0.1"
"channelAddress": "127.0.0.1",
"health": {
"healthProbeInterval": "5s",
"healthProbeTimeout": "500ms",
"healthThreshold": 3
}
}
}
```
@ -236,8 +261,6 @@ Code | Description
### Examples
Note: This example is based on the Actor sample provided in the [Dapr SDK for Python](https://github.com/dapr/python-sdk/tree/master/examples/demo_actor).
Add a custom attribute to the metadata endpoint:
```shell
@ -248,7 +271,7 @@ Get the metadata information to confirm your custom attribute was added:
```json
{
"id": "demo-actor",
"id": "myApp",
"runtimeVersion": "1.12.0",
"enabledFeatures": [
"ServiceInvocationStreaming"
@ -275,6 +298,27 @@ Get the metadata information to confirm your custom attribute was added:
]
}
],
"httpEndpoints": [
{
"name": "my-backend-api"
}
],
"subscriptions": [
{
"pubsubname": "pubsub",
"topic": "orders",
"deadLetterTopic": "",
"metadata": {
"ttlInSeconds": "30"
},
"rules": [
{
"match": "%!s(<nil>)",
"path": "orders"
}
]
}
],
"extended": {
"myDemoAttribute": "myDemoAttributeValue",
"appCommand": "uvicorn --port 3000 demo_actor_service:app",
@ -285,7 +329,12 @@ Get the metadata information to confirm your custom attribute was added:
"appConnectionProperties": {
"port": 3000,
"protocol": "http",
"channelAddress": "127.0.0.1"
"channelAddress": "127.0.0.1",
"health": {
"healthProbeInterval": "5s",
"healthProbeTimeout": "500ms",
"healthThreshold": 3
}
}
}
```

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

@ -48,6 +48,7 @@ This component supports **output binding** with the following operations:
- `topology`
- `deploy-process`
- `deploy-resource`
- `create-instance`
- `cancel-instance`
- `set-variables`
@ -123,9 +124,13 @@ The response values are:
#### deploy-process
The `deploy-process` operation deploys a single process to Zeebe.
Deprecated alias of 'deploy-resource'.
To perform a `deploy-process` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
#### deploy-resource
The `deploy-resource` operation deploys a single resource to Zeebe. A resource can be a process (BPMN) or a decision and a decision requirement (DMN).
To perform a `deploy-resource` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
```json
{
@ -133,41 +138,105 @@ To perform a `deploy-process` operation, invoke the Zeebe command binding with a
"metadata": {
"fileName": "products-process.bpmn"
},
"operation": "deploy-process"
"operation": "deploy-resource"
}
```
The metadata parameters are:
- `fileName` - the name of the process file
- `fileName` - the name of the resource file
##### Response
The binding returns a JSON with the following response:
{{< tabs "BPMN" "DMN" >}}
{{% codetab %}}
```json
{
"key": 2251799813687320,
"processes": [
"key": 2251799813685252,
"deployments": [
{
"bpmnProcessId": "products-process",
"version": 3,
"processDefinitionKey": 2251799813685895,
"resourceName": "products-process.bpmn"
"Metadata": {
"Process": {
"bpmnProcessId": "products-process",
"version": 2,
"processDefinitionKey": 2251799813685251,
"resourceName": "products-process.bpmn"
}
}
}
]
}
```
{{% /codetab %}}
{{% codetab %}}
```json
{
"key": 2251799813685253,
"deployments": [
{
"Metadata": {
"Decision": {
"dmnDecisionId": "products-approval",
"dmnDecisionName": "Products approval",
"version": 1,
"decisionKey": 2251799813685252,
"dmnDecisionRequirementsId": "Definitions_0c98xne",
"decisionRequirementsKey": 2251799813685251
}
}
},
{
"Metadata": {
"DecisionRequirements": {
"dmnDecisionRequirementsId": "Definitions_0c98xne",
"dmnDecisionRequirementsName": "DRD",
"version": 1,
"decisionRequirementsKey": 2251799813685251,
"resourceName": "products-approval.dmn"
}
}
}
]
}
```
{{% /codetab %}}
{{< /tabs >}}
The response values are:
- `key` - the unique key identifying the deployment
- `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
process definition
- `version` - the assigned process version
- `processDefinitionKey` - the assigned key, which acts as a unique identifier for this process
- `resourceName` - the resource name from which this process was parsed
- `deployments` - a list of deployed resources, e.g. processes
- `metadata` - deployment metadata, each deployment has only one metadata
- `process`- metadata of a deployed process
- `bpmnProcessId` - the bpmn process ID, as parsed during deployment; together with the version forms a unique identifier for a specific
process definition
- `version` - the assigned process version
- `processDefinitionKey` - the assigned key, which acts as a unique identifier for this process
- `resourceName` - the resource name from which this process was parsed
- `decision` - metadata of a deployed decision
- `dmnDecisionId` - the dmn decision ID, as parsed during deployment; together with the versions forms a unique identifier for a specific
decision
- `dmnDecisionName` - the dmn name of the decision, as parsed during deployment
- `version` - the assigned decision version
- `decisionKey` - the assigned decision key, which acts as a unique identifier for this decision
- `dmnDecisionRequirementsId` - the dmn ID of the decision requirements graph that this decision is part of, as parsed during deployment
- `decisionRequirementsKey` - the assigned key of the decision requirements graph that this decision is part of
- `decisionRequirements` - metadata of a deployed decision requirements
- `dmnDecisionRequirementsId` - the dmn decision requirements ID, as parsed during deployment; together with the versions forms a unique
identifier for a specific decision
- `dmnDecisionRequirementsName` - the dmn name of the decision requirements, as parsed during deployment
- `version` - the assigned decision requirements version
- `decisionRequirementsKey` - the assigned decision requirements key, which acts as a unique identifier for this decision requirements
- `resourceName` - the resource name from which this decision requirements was parsed
#### create-instance
@ -176,10 +245,19 @@ specified either using its unique key (as returned by the `deploy-process` opera
Note that only processes with none start events can be started through this command.
##### By BPMN process ID
Typically, process creation and execution are decoupled. This means that the command creates a new process instance and immediately responds with
the process instance id. The execution of the process occurs after the response is sent. However, there are use cases that need to collect the results
of a process when its execution is complete. By defining the `withResult` property, the command allows to "synchronously" execute processes and receive
the results via a set of variables. The response is sent when the process execution is complete.
For more information please visit the [official documentation](https://docs.camunda.io/docs/components/concepts/process-instance-creation/).
To perform a `create-instance` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
{{< tabs "By BPMN process ID" "By process definition key" "Synchronous execution" >}}
{{% codetab %}}
```json
{
"data": {
@ -194,19 +272,9 @@ To perform a `create-instance` operation, invoke the Zeebe command binding with
}
```
The data parameters are:
{{% /codetab %}}
- `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
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 process definition key
To perform a `create-instance` operation, invoke the Zeebe command binding with a `POST` method, and the following JSON body:
{{% codetab %}}
```json
{
@ -222,14 +290,46 @@ To perform a `create-instance` operation, invoke the Zeebe command binding with
}
```
{{% /codetab %}}
{{% codetab %}}
```json
{
"data": {
"bpmnProcessId": "products-process",
"variables": {
"productId": "some-product-id",
"productName": "some-product-name",
"productKey": "some-product-key"
},
"withResult": true,
"requestTimeout": "30s",
"fetchVariables": ["productId"]
},
"operation": "create-instance"
}
```
{{% /codetab %}}
{{< /tabs >}}
The data parameters are:
- `bpmnProcessId` - the BPMN process ID of the process definition to instantiate
- `processDefinitionKey` - the unique key identifying 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
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
- `withResult` - (optional, default: false) if set to true, the process will be instantiated and executed synchronously
- `requestTimeout` - (optional, only used if withResult=true) timeout the request will be closed if the process is not completed before the
requestTimeout. If requestTimeout = 0, uses the generic requestTimeout configured in the gateway.
- `fetchVariables` - (optional, only used if withResult=true) list of names of variables to be included in `variables` property of the response.
If empty, all visible variables in the root scope will be returned.
##### Response
@ -240,7 +340,8 @@ The binding returns a JSON with the following response:
"processDefinitionKey": 2251799813685895,
"bpmnProcessId": "products-process",
"version": 3,
"processInstanceKey": 2251799813687851
"processInstanceKey": 2251799813687851,
"variables": "{\"productId\":\"some-product-id\"}"
}
```
@ -250,6 +351,8 @@ The response values are:
- `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
- `variables` - (optional, only if withResult=true was used in the request) JSON document consists of visible variables in the root scope;
returned as a serialized JSON document
#### cancel-instance
@ -262,7 +365,6 @@ To perform a `cancel-instance` operation, invoke the Zeebe command binding with
"data": {
"processInstanceKey": 2251799813687851
},
"metadata": {},
"operation": "cancel-instance"
}
```
@ -291,7 +393,6 @@ To perform a `set-variables` operation, invoke the Zeebe command binding with a
"productKey": "some-product-key"
}
},
"metadata": {},
"operation": "set-variables"
}
```
@ -334,7 +435,6 @@ To perform a `resolve-incident` operation, invoke the Zeebe command binding with
"data": {
"incidentKey": 2251799813686123
},
"metadata": {},
"operation": "resolve-incident"
}
```
@ -355,14 +455,17 @@ To perform a `publish-message` operation, invoke the Zeebe command binding with
```json
{
"messageName": "",
"correlationKey": "2",
"timeToLive": "1m",
"variables": {
"productId": "some-product-id",
"productName": "some-product-name",
"productKey": "some-product-key"
}
"data": {
"messageName": "product-message",
"correlationKey": "2",
"timeToLive": "1m",
"variables": {
"productId": "some-product-id",
"productName": "some-product-name",
"productKey": "some-product-key"
},
},
"operation": "publish-message"
}
```
@ -408,9 +511,9 @@ To perform a `activate-jobs` operation, invoke the Zeebe command binding with a
"productId",
"productName",
"productKey"
]
],
"requestTimeout": "30s"
},
"metadata": {},
"operation": "activate-jobs"
}
```
@ -423,6 +526,8 @@ The data parameters are:
- `workerName` - (optional, default: `default`) the name of the worker activating the jobs, mostly used for logging purposes
- `fetchVariables` - (optional) a list of variables to fetch as the job variables; if empty, all visible variables at the time of activation for the
scope of the job will be returned
- `requestTimeout` - (optional) the request will be completed when at least one job is activated or after the requestTimeout. If the requestTimeout = 0,
a default timeout is used. If the requestTimeout < 0, long polling is disabled and the request is completed immediately, even when no job is activated.
##### Response
@ -431,7 +536,19 @@ The binding returns a JSON with the following response:
```json
[
{
"key": 2251799813685267,
"type": "fetch-products",
"processInstanceKey": 2251799813685260,
"bpmnProcessId": "products",
"processDefinitionVersion": 1,
"processDefinitionKey": 2251799813685249,
"elementId": "Activity_test",
"elementInstanceKey": 2251799813685266,
"customHeaders": "{\"process-header-1\":\"1\",\"process-header-2\":\"2\"}",
"worker": "test",
"retries": 1,
"deadline": 1694091934039,
"variables":"{\"productId\":\"some-product-id\"}"
}
]
```
@ -450,7 +567,7 @@ The response values are:
- `worker` - the name of the worker which activated this job
- `retries` - the amount of retries left to this job (should always be positive)
- `deadline` - when the job can be activated again, sent as a UNIX epoch timestamp
- `variables` - JSON document, computed at activation time, consisting of all visible variables to the task scope
- `variables` - computed at activation time, consisting of all visible variables to the task scope; returned as a serialized JSON document
#### complete-job
@ -468,7 +585,6 @@ To perform a `complete-job` operation, invoke the Zeebe command binding with a `
"productKey": "some-product-key"
}
},
"metadata": {},
"operation": "complete-job"
}
```
@ -495,9 +611,14 @@ To perform a `fail-job` operation, invoke the Zeebe command binding with a `POST
"data": {
"jobKey": 2251799813685739,
"retries": 5,
"errorMessage": "some error occurred"
"errorMessage": "some error occurred",
"retryBackOff": "30s",
"variables": {
"productId": "some-product-id",
"productName": "some-product-name",
"productKey": "some-product-key"
}
},
"metadata": {},
"operation": "fail-job"
}
```
@ -506,8 +627,14 @@ The data parameters are:
- `jobKey` - the unique job identifier, as obtained when activating the job
- `retries` - the amount of retries the job should have left
- `errorMessage ` - (optional) an message describing why the job failed this is particularly useful if a job runs out of retries and an
- `errorMessage ` - (optional) a message describing why the job failed this is particularly useful if a job runs out of retries and an
incident is raised, as it this message can help explain why an incident was raised
- `retryBackOff` - (optional) the back-off timeout for the next retry
- `variables` - (optional) JSON document that will instantiate the variables at the local scope of the
job's associated task; 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
@ -526,7 +653,6 @@ To perform a `update-job-retries` operation, invoke the Zeebe command binding wi
"jobKey": 2251799813686172,
"retries": 10
},
"metadata": {},
"operation": "update-job-retries"
}
```
@ -554,7 +680,6 @@ To perform a `throw-error` operation, invoke the Zeebe command binding with a `P
"errorCode": "product-fetch-error",
"errorMessage": "The product could not be fetched"
},
"metadata": {},
"operation": "throw-error"
}
```

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

@ -48,6 +48,8 @@ spec:
value: "productId, productName, productKey"
- name: autocomplete
value: "true"
- name: retryBackOff
value: "30s"
- name: direction
value: "input"
```
@ -70,6 +72,7 @@ spec:
| `pollThreshold` | N | Input | Set the threshold of buffered activated jobs before polling for new jobs, i.e. threshold * maxJobsActive. Defaults to 0.3 | `"0.3"` |
| `fetchVariables` | N | Input | A list of variables to fetch as the job variables; if empty, all visible variables at the time of activation for the scope of the job will be returned | `"productId"`, `"productName"`, `"productKey"` |
| `autocomplete` | N | Input | Indicates if a job should be autocompleted or not. If not set, all jobs will be auto-completed by default. Disable it if the worker should manually complete or fail the job with either a business error or an incident | `"true"`, `"false"` |
| `retryBackOff` | N | Input | The back-off timeout for the next retry if a job fails | `15s` |
| `direction` | N | Input | The direction of the binding | `"input"` |
## Binding support
@ -121,6 +124,7 @@ original data type so that it can be converted back to the equivalent data type
| 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 |
| X-Zeebe-Autocomplete | bool | The autocomplete status that is defined in the binding metadata |
## Related links