From b10deffbafcb21bddf9d144dc39cdcf93cf2fab7 Mon Sep 17 00:00:00 2001 From: Bilgin Ibryam Date: Mon, 12 May 2025 09:08:05 +0100 Subject: [PATCH] Fix for workflow mgmt api call rendering Signed-off-by: Bilgin Ibryam --- .../howto-invoke-discover-services.md | 2 +- .../workflow/howto-manage-workflow.md | 28 +++++++++---------- .../multi-app-dapr-run/multi-app-template.md | 2 +- .../kubernetes/kubernetes-dapr-shared.md | 2 +- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md index 9466fd4d3b1..4416242e003 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md +++ b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md @@ -413,7 +413,7 @@ dapr invoke --app-id checkout --method checkout/100 You can also append a query string or a fragment to the end of the URL and Dapr will pass it through unchanged. This means that if you need to pass some additional arguments in your service invocation that aren't part of a payload or the path, you can do so by appending a `?` to the end of the URL, followed by the key/value pairs separated by `=` signs and delimited by `&`. For example: ```bash -curl 'http://dapr-app-id:checkout@localhost:3602/checkout/100?basket=1234&key=abc` -X POST +curl 'http://dapr-app-id:checkout@localhost:3602/checkout/100?basket=1234&key=abc' -X POST ``` ### Namespaces diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/howto-manage-workflow.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/howto-manage-workflow.md index c9e847ebe15..36db5f68060 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/howto-manage-workflow.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/howto-manage-workflow.md @@ -320,8 +320,8 @@ Manage your workflow using HTTP calls. The example below plugs in the properties To start your workflow with an ID `12345678`, run: -```http -POST http://localhost:3500/v1.0/workflows/dapr/OrderProcessingWorkflow/start?instanceID=12345678 +```shell +curl -X POST "http://localhost:3500/v1.0/workflows/dapr/OrderProcessingWorkflow/start?instanceID=12345678" ``` Note that workflow instance IDs can only contain alphanumeric characters, underscores, and dashes. @@ -330,16 +330,16 @@ Note that workflow instance IDs can only contain alphanumeric characters, unders To terminate your workflow with an ID `12345678`, run: -```http -POST http://localhost:3500/v1.0/workflows/dapr/12345678/terminate +```shell +curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/terminate" ``` ### Raise an event For workflow components that support subscribing to external events, such as the Dapr Workflow engine, you can use the following "raise event" API to deliver a named event to a specific workflow instance. -```http -POST http://localhost:3500/v1.0/workflows///raiseEvent/ +```shell +curl -X POST "http://localhost:3500/v1.0/workflows///raiseEvent/" ``` > An `eventName` can be any function. @@ -348,14 +348,14 @@ POST http://localhost:3500/v1.0/workflows///r To plan for down-time, wait for inputs, and more, you can pause and then resume a workflow. To pause a workflow with an ID `12345678` until triggered to resume, run: -```http -POST http://localhost:3500/v1.0/workflows/dapr/12345678/pause +```shell +curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/pause" ``` To resume a workflow with an ID `12345678`, run: -```http -POST http://localhost:3500/v1.0/workflows/dapr/12345678/resume +```shell +curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/resume" ``` ### Purge a workflow @@ -364,16 +364,16 @@ The purge API can be used to permanently delete workflow metadata from the under Only workflow instances in the COMPLETED, FAILED, or TERMINATED state can be purged. If the workflow is in any other state, calling purge returns an error. -```http -POST http://localhost:3500/v1.0/workflows/dapr/12345678/purge +```shell +curl -X POST "http://localhost:3500/v1.0/workflows/dapr/12345678/purge" ``` ### Get information about a workflow To fetch workflow information (outputs and inputs) with an ID `12345678`, run: -```http -GET http://localhost:3500/v1.0/workflows/dapr/12345678 +```shell +curl -X GET "http://localhost:3500/v1.0/workflows/dapr/12345678" ``` Learn more about these HTTP calls in the [workflow API reference guide]({{< ref workflow_api.md >}}). diff --git a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md index 87012d7aac6..2392c4fd90c 100644 --- a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md +++ b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md @@ -305,7 +305,7 @@ The properties for the Multi-App Run template align with the `dapr run -k` CLI f | `appMaxConcurrency` | N | The concurrency level of the application; default is unlimited | | | `placementHostAddress` | N | Comma separated list of addresses for Dapr placement servers | `127.0.0.1:50057,127.0.0.1:50058` | | `schedulerHostAddress` | N | Dapr Scheduler Service host address | `127.0.0.1:50006` | -| `appSSL` | N | Enable https when Dapr invokes the application | | +| `appSSL` | N | Enable HTTPS when Dapr invokes the application | | | `maxBodySize` | N | Max size of the request body in MB. Set the value using size units (e.g., `16Mi` for 16MB). The default is `4Mi` | `16Mi` | | `readBufferSize` | N | Max size of the HTTP read buffer in KB. This also limits the maximum size of HTTP headers. Set the value using size units, for example `32Ki` will support headers up to 32KB . Default is `4Ki` for 4KB | `32Ki` | | `enableAppHealthCheck` | N | Enable the app health check on the application | `true`, `false` | diff --git a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md index 4bef59fe6e1..9839e129633 100644 --- a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md +++ b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md @@ -36,7 +36,7 @@ No matter which deployment approach you choose, it is important to understand th {{% /alert %}} -### `DeamonSet`(Per-node) +### `DaemonSet`(Per-node) With Kubernetes `DaemonSet`, you can define applications that need to be deployed once per node in the cluster. This enables applications that are running on the same node to communicate with local Dapr APIs, no matter where the Kubernetes `Scheduler` schedules your workload.