dapr
diff --git a/‎daprdocs/content/en/_index.md‎
Lines changed: 7 additions & 0 deletions b/‎daprdocs/content/en/_index.md‎
Lines changed: 7 additions & 0 deletions
diff --git a/‎daprdocs/content/en/concepts/configuration-concept.md‎
Lines changed: 19 additions & 7 deletions b/‎daprdocs/content/en/concepts/configuration-concept.md‎
Lines changed: 19 additions & 7 deletions
diff --git a/‎daprdocs/content/en/concepts/overview.md‎
Lines changed: 1 addition & 1 deletion b/‎daprdocs/content/en/concepts/overview.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎daprdocs/content/en/contributing/roadmap.md‎
Lines changed: 2 additions & 40 deletions b/‎daprdocs/content/en/contributing/roadmap.md‎
Lines changed: 2 additions & 40 deletions
diff --git a/‎daprdocs/content/en/developing-applications/building-blocks/actors/actors-overview.md‎
Lines changed: 1 addition & 1 deletion b/‎daprdocs/content/en/developing-applications/building-blocks/actors/actors-overview.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎daprdocs/content/en/developing-applications/building-blocks/jobs/howto-schedule-and-handle-triggered-jobs.md‎
Lines changed: 71 additions & 4 deletions b/‎daprdocs/content/en/developing-applications/building-blocks/jobs/howto-schedule-and-handle-triggered-jobs.md‎
Lines changed: 71 additions & 4 deletions
diff --git a/‎daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-non-dapr-endpoints.md‎
Lines changed: 3 additions & 5 deletions b/‎daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-non-dapr-endpoints.md‎
Lines changed: 3 additions & 5 deletions
diff --git a/‎daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md‎
Lines changed: 19 additions & 2 deletions b/‎daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md‎
Lines changed: 19 additions & 2 deletions
diff --git a/‎daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md‎
Lines changed: 3 additions & 3 deletions b/‎daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md‎
Lines changed: 3 additions & 3 deletions
diff --git a/‎daprdocs/content/en/developing-applications/integrations/Diagrid/diagrid-conductor.md‎
Lines changed: 0 additions & 2 deletions b/‎daprdocs/content/en/developing-applications/integrations/Diagrid/diagrid-conductor.md‎
Lines changed: 0 additions & 2 deletions
@@ -87,6 +87,13 @@ you tackle the challenges that come with building microservices and keeps your c
       <a href="{{< ref contributing >}}" class="stretched-link"></a>
     </div>
   </div>
+  <div class="card">
+    <div class="card-body">
+      <h5 class="card-title"><b>Roadmap</b></h5>
+      <p class="card-text">Learn about Dapr's roadmap and change process.</p>
+      <a href="{{< ref roadmap.md >}}" class="stretched-link"></a>
+    </div>
+  </div>
 </div>
 
 
 
@@ -6,9 +6,13 @@ weight: 400
 description: "Change the behavior of Dapr application sidecars or globally on Dapr control plane system services"
 ---
 
-Dapr configurations are settings and policies that enable you to change both the behavior of individual Dapr applications, or the global behavior of the Dapr control plane system services. For example, you can set an ACL policy on the application sidecar configuration which indicates which methods can be called from another application, or on the Dapr control plane configuration you can change the certificate renewal period for all certificates that are deployed to application sidecar instances.
+With Dapr configurations, you use settings and policies to change:
+- The behavior of individual Dapr applications
+- The global behavior of the Dapr control plane system services
 
-Configurations are defined and deployed as a YAML file. An application configuration example is shown below, which demonstrates an example of setting a tracing endpoint for where to send the metrics information, capturing all the sample traces.
+For example, set a sampling rate policy on the application sidecar configuration to indicate which methods can be called from another application. If you set a policy on the Dapr control plane configuration, you can change the certificate renewal period for all certificates that are deployed to application sidecar instances.
+
+Configurations are defined and deployed as a YAML file. In the following application configuration example, a tracing endpoint is set for where to send the metrics information, capturing all the sample traces.
 
 ```yaml
 apiVersion: dapr.io/v1alpha1
@@ -23,9 +27,11 @@ spec:
       endpointAddress: "http://localhost:9411/api/v2/spans"
 ```
 
-This configuration configures tracing for metrics recording. It can be loaded in local self-hosted mode by editing the default configuration file called `config.yaml` file in your `.dapr` directory, or by applying it to your Kubernetes cluster with kubectl/helm.
+The above YAML configures tracing for metrics recording. You can load it in local self-hosted mode by either:
+- Editing the default configuration file called `config.yaml` file in your `.dapr` directory, or 
+- Applying it to your Kubernetes cluster with `kubectl/helm`.
 
-Here is an example of the Dapr control plane configuration called `daprsystem` in the `dapr-system` namespace.
+The following example shows the Dapr control plane configuration called `daprsystem` in the `dapr-system` namespace.
 
 ```yaml
 apiVersion: dapr.io/v1alpha1
@@ -40,8 +46,14 @@ spec:
     allowedClockSkew: "15m"
 ```
 
-Visit [overview of Dapr configuration options]({{<ref "configuration-overview.md">}}) for a list of the configuration options.
+By default, there is a single configuration file called `daprsystem` installed with the Dapr control plane system services. This configuration file applies global control plane settings and is set up when Dapr is deployed to Kubernetes.
+
+[Learn more about configuration options.]({{< ref "configuration-overview.md" >}})
 
-{{% alert title="Note" color="primary" %}}
-Dapr application and control plane configurations should not be confused with the configuration building block API that enables applications to retrieve key/value data from configuration store components. Read the [Configuration building block]({{< ref configuration-api-overview >}}) for more information.
+{{% alert title="Important" color="warning" %}}
+Dapr application and control plane configurations should not be confused with the [configuration building block API]({{< ref configuration-api-overview >}}), which enables applications to retrieve key/value data from configuration store components. 
 {{% /alert %}}
+
+## Next steps
+
+{{< button text="Learn more about configuration" page="configuration-overview" >}}
@@ -108,7 +108,7 @@ Deploying and running a Dapr-enabled application into your Kubernetes cluster is
 
 ### Clusters of physical or virtual machines
 
-The Dapr control plane services can be deployed in high availability (HA) mode to clusters of physical or virtual machines in production. In the diagram below, the Actor `Placement` and security `Sentry` services are started on three different VMs to provide HA control plane. In order to provide name resolution using DNS for the applications running in the cluster, Dapr uses [Hashicorp Consul service]({{< ref setup-nr-consul >}}), also running in HA mode.  
+The Dapr control plane services can be deployed in high availability (HA) mode to clusters of physical or virtual machines in production. In the diagram below, the Actor `Placement` and security `Sentry` services are started on three different VMs to provide HA control plane. In order to provide name resolution using DNS for the applications running in the cluster, Dapr uses multicast DNS by default, but can also optionally support [Hashicorp Consul service]({{< ref setup-nr-consul >}}).  
 
 <img src="/images/overview-vms-hosting.png" width=1200 alt="Architecture diagram of Dapr control plane and Consul deployed to VMs in high availability mode">
 
 
@@ -2,47 +2,9 @@
 type: docs
 title: "Dapr Roadmap"
 linkTitle: "Roadmap"
-description: "The Dapr Roadmap is a tool to help with visibility into investments across the Dapr project"
+description: "The Dapr Roadmap gives the community visibility into the different priorities of the projecs"
 weight: 30
 no_list: true
 ---
 
-
-Dapr encourages the community to help with prioritization. A GitHub project board is available to view and provide feedback on proposed issues and track them across development.
-
-[<img src="/images/roadmap.png" alt="Screenshot of the Dapr Roadmap board" width=500 >](https://aka.ms/dapr/roadmap)
-
-{{< button text="View the backlog" link="https://aka.ms/dapr/roadmap" color="primary" >}}
-<br />
-
-Please vote by adding a 👍 on the GitHub issues for the feature capabilities you would most like to see Dapr support. This will help the Dapr maintainers understand which features will provide the most value.
-
-Contributions from the community is also welcomed. If there are features on the roadmap that you are interested in contributing to, please comment on the GitHub issue and include your solution proposal.
-
-{{% alert title="Note" color="primary" %}}
-The Dapr roadmap includes issues only from the v1.2 release and onwards. Issues closed and released prior to v1.2 are not included.
-{{% /alert %}}
-
-## Stages
-
-The Dapr Roadmap progresses through the following stages:
-
-{{< cardpane >}}
-{{< card title="**[📄 Backlog](https://github.com/orgs/dapr/projects/52#column-14691591)**" >}}
-  Issues (features) that need 👍 votes from the community to prioritize. Updated by Dapr maintainers.
-{{< /card >}}
-{{< card title="**[⏳ Planned (Committed)](https://github.com/orgs/dapr/projects/52#column-14561691)**" >}}
-  Issues with a proposal and/or targeted release milestone. This is where design proposals are discussed and designed.
-{{< /card >}}
-{{< card title="**[👩‍💻 In Progress (Development)](https://github.com/orgs/dapr/projects/52#column-14561696)**" >}}
- Implementation specifics have been agreed upon and the feature is under active development.
-{{< /card >}}
-{{< /cardpane >}}
-{{< cardpane >}}
-{{< card title="**[☑ Done](https://github.com/orgs/dapr/projects/52#column-14561700)**" >}}
- The feature capability has been completed and is scheduled for an upcoming release.
-{{< /card >}}
-{{< card title="**[✅ Released](https://github.com/orgs/dapr/projects/52#column-14659973)**" >}}
- The feature is released and available for use.
-{{< /card >}}
-{{< /cardpane >}}
+See [this document](https://github.com/dapr/community/blob/master/roadmap.md) to view the Dapr project's roadmap.
@@ -104,7 +104,7 @@ The Dapr actor runtime provides a simple turn-based access model for accessing a
 
 ### State
 
-Transactional state stores can be used to store actor state. To specify which state store to use for actors, specify value of property `actorStateStore` as `true` in the state store component's metadata section. Actors state is stored with a specific scheme in transactional state stores, allowing for consistent querying. Only a single state store component can be used as the state store for all actors. Read the [state API reference]({{< ref state_api.md >}}) and the [actors API reference]({{< ref actors_api.md >}}) to learn more about state stores for actors.
+Transactional state stores can be used to store actor state. Regardless of whether you intend to store any state in your actor, you must specify a value for property `actorStateStore` as `true` in the state store component's metadata section. Actors state is stored with a specific scheme in transactional state stores, allowing for consistent querying. Only a single state store component can be used as the state store for all actors. Read the [state API reference]({{< ref state_api.md >}}) and the [actors API reference]({{< ref actors_api.md >}}) to learn more about state stores for actors.
 
 ### Actor timers and reminders
 
 
@@ -94,6 +94,75 @@ In this example, at trigger time, which is `@every 1s` according to the `Schedul
 
 At the trigger time, the `prodDBBackupHandler` function is called, executing the desired business logic for this job at trigger time. For example:
 
+#### HTTP
+
+When you create a job using Dapr's Jobs API, Dapr will automatically assume there is an endpoint available at 
+`/job/<job-name>`. For instance, if you schedule a job named `test`, Dapr expects your application to listen for job 
+events at `/job/test`. Ensure your application has a handler set up for this endpoint to process the job when it is 
+triggered. For example:
+
+*Note: The following example is in Go but applies to any programming language.*
+
+```go
+
+func main() {
+    ...
+    http.HandleFunc("/job/", handleJob)
+	http.HandleFunc("/job/<job-name>", specificJob)
+    ...
+}
+
+func specificJob(w http.ResponseWriter, r *http.Request) {
+    // Handle specific triggered job
+}
+
+func handleJob(w http.ResponseWriter, r *http.Request) {
+    // Handle the triggered jobs
+}
+```
+
+#### gRPC
+
+When a job reaches its scheduled trigger time, the triggered job is sent back to the application via the following 
+callback function:
+
+*Note: The following example is in Go but applies to any programming language with gRPC support.*
+
+```go
+import rtv1 "github.com/dapr/dapr/pkg/proto/runtime/v1"
+...
+func (s *JobService) OnJobEventAlpha1(ctx context.Context, in *rtv1.JobEventRequest) (*rtv1.JobEventResponse, error) {
+    // Handle the triggered job
+}
+```
+
+This function processes the triggered jobs within the context of your gRPC server. When you set up the server, ensure that 
+you register the callback server, which will invoke this function when a job is triggered:
+
+```go
+...
+js := &JobService{}
+rtv1.RegisterAppCallbackAlphaServer(server, js)
+```
+
+In this setup, you have full control over how triggered jobs are received and processed, as they are routed directly 
+through this gRPC method.
+
+#### SDKs
+
+For SDK users, handling triggered jobs is simpler. When a job is triggered, Dapr will automatically route the job to the 
+event handler you set up during the server initialization. For example, in Go, you'd register the event handler like this:
+
+```go
+...
+if err = server.AddJobEventHandler("prod-db-backup", prodDBBackupHandler); err != nil {
+    log.Fatalf("failed to register job event handler: %v", err)
+}
+```
+
+Dapr takes care of the underlying routing. When the job is triggered, your `prodDBBackupHandler` function is called with
+the triggered job data. Here’s an example of handling the triggered job:
+
 ```go
 // ...
 
@@ -103,11 +172,9 @@ func prodDBBackupHandler(ctx context.Context, job *common.JobEvent) error {
 	if err := json.Unmarshal(job.Data, &jobData); err != nil {
 		// ...
 	}
-	decodedPayload, err := base64.StdEncoding.DecodeString(jobData.Value)
-	// ...
 
 	var jobPayload api.DBBackup
-	if err := json.Unmarshal(decodedPayload, &jobPayload); err != nil {
+	if err := json.Unmarshal(job.Data, &jobPayload); err != nil {
 		// ...
 	}
 	fmt.Printf("job %d received:\n type: %v \n typeurl: %v\n value: %v\n extracted payload: %v\n", jobCount, job.JobType, jobData.TypeURL, jobData.Value, jobPayload)
@@ -146,4 +213,4 @@ dapr run --app-id=distributed-scheduler \
 ## Next steps
 
 - [Learn more about the Scheduler control plane service]({{< ref "concepts/dapr-services/scheduler.md" >}})
-- [Jobs API reference]({{< ref jobs_api.md >}})
+- [Jobs API reference]({{< ref jobs_api.md >}})
@@ -38,11 +38,9 @@ The diagram below is an overview of how Dapr's service invocation works when inv
 <img src="/images/service-invocation-overview-non-dapr-endpoint.png" width=800 alt="Diagram showing the steps of service invocation to non-Dapr endpoints">
 
 1. Service A makes an HTTP call targeting Service B, a non-Dapr endpoint. The call goes to the local Dapr sidecar.
-2. Dapr discovers Service B's location using the `HTTPEndpoint` or FQDN URL.
-3. Dapr forwards the message to Service B.
-4. Service B runs its business logic code.
-5. Service B sends a response to Service A's Dapr sidecar.
-6. Service A receives the response.
+2. Dapr discovers Service B's location using the `HTTPEndpoint` or FQDN URL then forwards the message to Service B.
+3. Service B sends a response to Service A's Dapr sidecar.
+4. Service A receives the response.
 
 ## Using an HTTPEndpoint resource or FQDN URL for non-Dapr endpoints
 There are two ways to invoke a non-Dapr endpoint when communicating either to Dapr applications or non-Dapr applications. A Dapr application can invoke a non-Dapr endpoint by providing one of the following:
 
@@ -106,8 +106,25 @@ Want to skip the quickstarts? Not a problem. You can try out the workflow buildi
 
 ## Limitations
 
-- **State stores:** As of the 1.12.0 beta release of Dapr Workflow, using the NoSQL databases as a state store results in limitations around storing internal states. For example, CosmosDB has a maximum single operation item limit of only 100 states in a single request.
-- **Horizontal scaling:** As of the 1.12.0 beta release of Dapr Workflow, if you scale out Dapr sidecars or your application pods to more than 2, then the concurrency of the workflow execution drops. It is recommended to test with 1 or 2 instances, and no more than 2.
+- **State stores:** Due to underlying limitations in some database choices, more commonly NoSQL databases, you might run into limitations around storing internal states. For example, CosmosDB has a maximum single operation item limit of only 100 states in a single request.
+- **Horizontal scaling:** As of the 1.12.0 beta release of Dapr Workflow, it is recommended to use a maximum of two instances of Dapr per workflow application. This limitation is resolved in Dapr 1.14.x when enabling the scheduler service.
+
+To enable the scheduler service to work for Dapr Workflows, make sure you're using Dapr 1.14.x or later and assign the following configuration to your app:
+
+```yaml
+apiVersion: dapr.io/v1alpha1
+kind: Configuration
+metadata:
+  name: schedulerconfig
+spec:
+  tracing:
+    samplingRate: "1"
+  features:
+    - name: SchedulerReminders
+      enabled: true
+```
+
+See more info about [enabling preview features]({{<ref preview-features>}}).
 
 ## Watch the demo
 
 
@@ -749,7 +749,7 @@ def status_monitor_workflow(ctx: wf.DaprWorkflowContext, job: JobStatus):
             ctx.call_activity(send_alert, input=f"Job '{job.job_id}' is unhealthy!")
         next_sleep_interval = 5  # check more frequently when unhealthy
 
-    yield ctx.create_timer(fire_at=ctx.current_utc_datetime + timedelta(seconds=next_sleep_interval))
+    yield ctx.create_timer(fire_at=ctx.current_utc_datetime + timedelta(minutes=next_sleep_interval))
 
     # restart from the beginning with a new JobStatus input
     ctx.continue_as_new(job)
@@ -896,7 +896,7 @@ func StatusMonitorWorkflow(ctx *workflow.WorkflowContext) (any, error) {
 	}
 	if status == "healthy" {
 		job.IsHealthy = true
-		sleepInterval = time.Second * 60
+		sleepInterval = time.Minutes * 60
 	} else {
 		if job.IsHealthy {
 			job.IsHealthy = false
@@ -905,7 +905,7 @@ func StatusMonitorWorkflow(ctx *workflow.WorkflowContext) (any, error) {
 				return "", err
 			}
 		}
-		sleepInterval = time.Second * 5
+		sleepInterval = time.Minutes * 5
 	}
 	if err := ctx.CreateTimer(sleepInterval).Await(nil); err != nil {
 		return "", err
 
@@ -26,6 +26,4 @@ By studying past resource behavior, recommend application resource optimization
 
 The application graph facilitates collaboration between dev and ops by providing a dynamic overview of your services and infrastructure components.
 
-Try out [Conductor Free](https://www.diagrid.io/pricing), ideal for individual developers building and testing Dapr applications on Kubernetes.
-
 {{< button text="Learn more about Diagrid Conductor" link="https://www.diagrid.io/conductor" >}}
Original file line number	Diff line number	Diff line change
`@@ -749,7 +749,7 @@ def status_monitor_workflow(ctx: wf.DaprWorkflowContext, job: JobStatus):`
`749`	`749`	`ctx.call_activity(send_alert, input=f"Job '{job.job_id}' is unhealthy!")`
`750`	`750`	`next_sleep_interval = 5 # check more frequently when unhealthy`
`751`	`751`
`752`		`- yield ctx.create_timer(fire_at=ctx.current_utc_datetime + timedelta(seconds=next_sleep_interval))`
	`752`	`+ yield ctx.create_timer(fire_at=ctx.current_utc_datetime + timedelta(minutes=next_sleep_interval))`
`753`	`753`
`754`	`754`	`# restart from the beginning with a new JobStatus input`
`755`	`755`	`ctx.continue_as_new(job)`
`@@ -896,7 +896,7 @@ func StatusMonitorWorkflow(ctx *workflow.WorkflowContext) (any, error) {`
`896`	`896`	`}`
`897`	`897`	`if status == "healthy" {`
`898`	`898`	`job.IsHealthy = true`
`899`		`- sleepInterval = time.Second * 60`
	`899`	`+ sleepInterval = time.Minutes * 60`
`900`	`900`	`} else {`
`901`	`901`	`if job.IsHealthy {`
`902`	`902`	`job.IsHealthy = false`
`@@ -905,7 +905,7 @@ func StatusMonitorWorkflow(ctx *workflow.WorkflowContext) (any, error) {`
`905`	`905`	`return "", err`
`906`	`906`	`}`
`907`	`907`	`}`
`908`		`- sleepInterval = time.Second * 5`
	`908`	`+ sleepInterval = time.Minutes * 5`
`909`	`909`	`}`
`910`	`910`	`if err := ctx.CreateTimer(sleepInterval).Await(nil); err != nil {`
`911`	`911`	`return "", err`