Update naming

Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com>

tutorials/workflow/python/challenges-tips/versioning_workflow.py

@@ -13,9 +13,25 @@ def versioning_workflow_1(ctx: wf.DaprWorkflowContext, order_item: str):
     
     return result_a + result_b
 
+@wf_runtime.activity(name='activity_a')
+def activity_a(ctx: wf.WorkflowActivityContext, order_item: str) -> int:
+    """
+    This activity processes the order item and returns an integer result.
+    """
+    print(f'activity_a: Received input: {order_item}.', flush=True)
+    return 10
+
+@wf_runtime.activity(name='activity_b')
+def activity_b(ctx: wf.WorkflowActivityContext, order_item: str) -> int:
+    """
+    This activity processes the order item and returns another integer result.
+    """
+    print(f'activity_b: Received input: {order_item}.', flush=True)
+    return 20
+
 """
 This is the updated version of the workflow.
-The input for activity_b has changed from orderItem (string) to resultA (int).
+The input for activity_b has changed from order_item (string) to result_a (int).
 If there are in-flight workflow instances that were started with the previous version
 of this workflow, these will fail when the new version of the workflow is deployed 
 and the workflow name remains the same, since the runtime parameters do not match with the persisted state.
@@ -29,4 +45,20 @@ def versioning_workflow_2(ctx: wf.DaprWorkflowContext, order_item: str):
     result_a = yield ctx.call_activity(activity_a, input=order_item)
     result_b = yield ctx.call_activity(activity_b, input=result_a)
     
-    return result_a + result_b
+    return result_a + result_b
+
+@wf_runtime.activity(name='activity_a')
+def activity_a(ctx: wf.WorkflowActivityContext, order_item: str) -> int:
+    """
+    This activity processes the order item and returns an integer result.
+    """
+    print(f'activity_a: Received input: {order_item}.', flush=True)
+    return 10
+
+@wf_runtime.activity(name='activity_b')
+def activity_b(ctx: wf.WorkflowActivityContext, number: int) -> int:
+    """
+    This activity processes a number and returns another integer result.
+    """
+    print(f'activity_b: Received input: {number}.', flush=True)
+    return number + 10

tutorials/workflow/python/child-workflows/README.md

@@ -4,7 +4,7 @@ This tutorial demonstrates how a workflow can call child workflows that are part
 
 ## Inspect the code
 
-Open the `ParentWorkflow.cs` file in the `tutorials/workflow/python/child-workflows/child_workflows` folder. This file contains the definition for the workflows and activities.
+Open the `parent_child_workflow.py` file in the `tutorials/workflow/python/child-workflows/child_workflows` folder. This file contains the definition for the workflows and activities.
 
 The parent workflow iterates over the input array and schedules an instance of the `child_workflow` for each of the input elements. The `child_workflow` is a basic task-chaining workflow that contains a sequence of two activities. When all of the instances of the `child_workflow` complete, then the `parent_workflow` finishes.
 

tutorials/workflow/python/child-workflows/childworkflows.http

@@ -1,6 +1,6 @@
 @apphost=http://localhost:5259
 
-### Start the ParentWorkflow workflow
+### Start the parent_workflow
 # @name startWorkflowRequest
 POST {{ apphost }}/start
 Content-Type: application/json

tutorials/workflow/python/external-system-interaction/README.md

@@ -74,7 +74,7 @@ graph LR
 
     ```json
     {
-        "id": "{{orderId}}",
+        "id": "b7dd836b-e913-4446-9912-d400befebec5",
         "description": "Rubber ducks",
         "quantity": 100,
         "total_price": 500
@@ -92,7 +92,7 @@ graph LR
     The app logs should look similar to the following:
 
     ```text
-   == APP - externalevents == Received order: Order { Id = b7dd836b-e913-4446-9912-d400befebec5, Description = Rubber ducks, Quantity = 100, TotalPrice = 500 }.
+   == APP - externalevents == Received order: Order { id = b7dd836b-e913-4446-9912-d400befebec5, description = Rubber ducks, quantity = 100, total_price = 500.0 }.
     ```
 
 6. Use the POST request in the [`externalevents.http`](./externalevents.http) file to send an `approval-event` to the workflow, or use this cURL command:
@@ -108,7 +108,7 @@ graph LR
 
     ```json
     {
-        "order_id": "{{instanceId}}",
+        "order_id": "b7dd836b-e913-4446-9912-d400befebec5",
         "is_approved": true
     }
     ```

tutorials/workflow/python/external-system-interaction/external_events/app.py

@@ -14,6 +14,8 @@ app = FastAPI(lifespan=lifespan)
 
 @app.post("/start", status_code=status.HTTP_202_ACCEPTED)
 async def start_workflow(order: Order):
+    print(f"Received order: {order}")
+
     """
     The DaprWorkflowClient is the API to manage workflows.
     Here it is used to schedule a new workflow instance.

tutorials/workflow/python/fan-out-fan-in/README.md

@@ -76,11 +76,11 @@ graph LR
     The expected app logs are as follows:
 
     ```text
-    == APP - fanoutfanin == GetWordLength: Received input: word.
-    == APP - fanoutfanin == GetWordLength: Received input: is.
-    == APP - fanoutfanin == GetWordLength: Received input: the.
-    == APP - fanoutfanin == GetWordLength: Received input: shortest.
-    == APP - fanoutfanin == GetWordLength: Received input: which.
+    == APP - fanoutfanin == get_word_length: Received input: word.
+    == APP - fanoutfanin == get_word_length: Received input: is.
+    == APP - fanoutfanin == get_word_length: Received input: the.
+    == APP - fanoutfanin == get_word_length: Received input: shortest.
+    == APP - fanoutfanin == get_word_length: Received input: which.
     ```
 
     > Note that the order of the logs may vary.

tutorials/workflow/python/fan-out-fan-in/fanoutfanin.http

@@ -1,6 +1,6 @@
 @apphost=http://localhost:5256
 
-### Start the FanOutFanIn workflow
+### Start the fanoutfanin_workflow
 # @name startWorkflowRequest
 POST {{ apphost }}/start
 Content-Type: application/json

tutorials/workflow/python/monitor-pattern/README.md

@@ -62,13 +62,13 @@ graph LR
     The expected app logs are as follows:
 
     ```text
-    == APP - monitor == CheckStatus: Received input: 0.
-    == APP - monitor == CheckStatus: Received input: 1.
-    == APP - monitor == CheckStatus: Received input: 2.
-    == APP - monitor == CheckStatus: Received input: 3.
+    == APP - monitor == check_status: Received input: 0.
+    == APP - monitor == check_status: Received input: 1.
+    == APP - monitor == check_status: Received input: 2.
+    == APP - monitor == check_status: Received input: 3.
     ```
 
-    *Note that the number of app log statements can vary due to the randomization in the `CheckStatus` activity.*
+    *Note that the number of app log statements can vary due to the randomization in the `check_status` activity.*
 
 5. Use the GET request in the [`monitor.http`](./monitor.http) file to get the status of the workflow, or use this cURL command:
 
@@ -84,6 +84,6 @@ graph LR
     "\"Status is healthy after checking 3 times.\""
     ```
 
-    *The actual number of checks can vary since some randomization is used in the `CheckStatus` activity.*
+    *The actual number of checks can vary since some randomization is used in the `check_status` activity.*
 
 6. Stop the Dapr Multi-App run process by pressing `Ctrl+C`.

tutorials/workflow/python/monitor-pattern/monitor.http

@@ -1,6 +1,6 @@
 @apphost=http://localhost:5257
 
-### Start the Monitor workflow
+### Start the monitor workflow
 # @name startWorkflowRequest
 @counter=0
 POST {{ apphost }}/start/{{counter}}

tutorials/workflow/python/resiliency-and-compensation/README.md

@@ -59,7 +59,7 @@ graph LR
     --url http://localhost:5264/start/1
     ```
 
-    When the workflow input is `1`, the `MinusOne` activity will subtract `1` resulting in a `0`. This value is passed to the `Division` activity, which will throw an error because the divisor is `0`. The `Division` activity will be retried three times but all will fail the same way as the divisor has not changed. Finally the compensation action `PlusOne` will be executed, increasing the value back to `1` before returning the result.
+    When the workflow input is `1`, the `minus_one` activity will subtract `1` resulting in a `0`. This value is passed to the `division` activity, which will throw an error because the divisor is `0`. The `division` activity will be retried three times but all will fail the same way as the divisor has not changed. Finally the compensation action `plus_one` will be executed, increasing the value back to `1` before returning the result.
 
     The app logs should output the following:
 

tutorials/workflow/python/resiliency-and-compensation/resiliency_and_compensation/app.py

@@ -12,12 +12,12 @@ async def lifespan(app: FastAPI):
 
 app = FastAPI(lifespan=lifespan)
 
-@app.post("/start/{input}", status_code=status.HTTP_202_ACCEPTED)
-async def start_workflow(input: int):
+@app.post("/start/{wf_input}", status_code=status.HTTP_202_ACCEPTED)
+async def start_workflow(wf_input: int):
     wf_client = wf.DaprWorkflowClient()
     instance_id = wf_client.schedule_new_workflow(
             workflow=resiliency_and_compensation_workflow,
-            input=input
+            input=wf_input
         )
     return {"instance_id": instance_id}
 

tutorials/workflow/python/task-chaining/README.md

@@ -58,9 +58,9 @@ graph LR
     The input for the workflow is a string with the value `This`. The expected app logs are as follows:
 
     ```text
-    == APP - chaining == Activity1: Received input: This.
-    == APP - chaining == Activity2: Received input: This is.
-    == APP - chaining == Activity3: Received input: This is task.
+    == APP - chaining == activity1: Received input: This.
+    == APP - chaining == activity2: Received input: This is.
+    == APP - chaining == activity3: Received input: This is task.
     ```
 
 5. Use the GET request in the [`chaining.http`](./chaining.http) file to get the status of the workflow, or use this cURL command:

tutorials/workflow/python/task-chaining/chaining.http

@@ -1,6 +1,6 @@
 @apphost=http://localhost:5255
 
-### Start the TaskChaining workflow
+### Start the task_chaining workflow
 # @name startWorkflowRequest
 POST {{ apphost }}/start