orkes-io · dougsillars · Apr 4, 2022 · Apr 1, 2022 · Apr 4, 2022
diff --git a/blog/2022-03-30-Conductor-SDKs.md b/blog/2022-03-30-Conductor-SDKs.md
@@ -49,6 +49,14 @@ Conductor already has Python and Golang SDKs.  These have been dramatically impr
 
 The Clojure SDK was created by the Orkes team, and the C-Sharp SDK has been contributed by Sean McAdams.  They feature all of the same great features as the Java, Python and Golang SDKs already launched (and now re-launched).
 
+## The announcement
+
+We announced our GitHub repo and our planning around Conductor SDKs at our [Meetup](https://www.meetup.com/san-francisco-microservices-orchestration-meetup-group/). Here's the video of our CTO Boney:
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/9Fzmu1NP_bg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+
+
+
 ## What's next?
 
 Over the coming weeks, we'll be working to improve the documentation and sample applications for all of the SDKs.  We'll also continue work on the JavaScript SDK.

diff --git a/docs/codelab/orderfulfillment.md b/docs/codelab/orderfulfillment.md
@@ -1,5 +1,9 @@
-# Order Fulfillment Codelab part 1
+---
+displayed_sidebar:     orderfulfillment
+---
 
+# Creating a Workflow and task
+# Order Fulfillment Codelab part 1
 Bob's Widgets has just moved out of Bob's garage, and he's hired you to overhaul the shipping and fulfillment process.  Everything today is manual and you think that building an automated workflow to efficiently get the orders out to the growing customer base is the best way to scale the system (and save your team from going insane).
 
 You've heard of Netflix Conductor, and have read about the flexibility of a microservice-based architecture. You are pretty sure that building small modular applications and wiring them into a Conductor workflow is the way to go. You know that the initial workflow will be really simple (these widgets don't ship themselves, you know!), but will quickly grow in complexity as the company grows.

diff --git a/docs/codelab/orderfulfillment2.md b/docs/codelab/orderfulfillment2.md
@@ -1,3 +1,7 @@
+---
+displayed_sidebar:     orderfulfillment
+---
+# Building and Deploying a Worker
 # Order Fulfillment Codelab part 2
 
 You're running order fulfillment at Bob's Widgets, and it's totally manual.  You're working with Conductor to create workflows and work to better automate the system.

diff --git a/docs/codelab/orderfulfillment3.md b/docs/codelab/orderfulfillment3.md
@@ -1,3 +1,7 @@
+---
+displayed_sidebar:     orderfulfillment
+---
+# Running the Workflow
 # Order Fulfillment Codelab part 3
 
 You're running order fulfillment at Bob's Widgets, and it's totally manual.  You're working with Conductor to create workflows and work to better automate the system.

diff --git a/docs/codelab/orderfulfillment4.md b/docs/codelab/orderfulfillment4.md
@@ -1,3 +1,7 @@
+---
+displayed_sidebar:     orderfulfillment
+---
+# HTTP Task addition
 # Order Fulfillment Codelab part 4
 
 You're running order fulfillment at Bob's Widgets, and when you started, it was 100% manual.  In parts 1-3 of the codelab, you got a shipping workflow up and running, but there's still a lot of room for improvement.

diff --git a/docs/codelab/orderfulfillment5.md b/docs/codelab/orderfulfillment5.md
@@ -1,3 +1,4 @@
+# Dealing with workflow failure
 # Order Fulfillment Codelab part 5
 
 You're running order fulfillment at Bob's Widgets, and when you started, it was 100% manual.  
@@ -240,128 +241,3 @@ Now, we have instrumented our Workflow to tell us when there is a failure- in rd
 
 Now that we have some notification of workflow failures, we can continue with our automation of our shipping workflow.  At this point, we're going to make a bigger change to the workflow - adding additional inputs that might break the current workflow.  So we'll create a new version of the workflow.
 
-## Versioning
-
-Until now, all of the changes have been made on the same workflow - as the changes have been improvements - but have not materially changed the workflow in any way.
-
-When a large change is made, a new version of the same workflow can be created.  Versions are integer based, so we've been working on V1, meaning that this next version will be V2.   
-
-What is great about versioning is that *both* workflows can be live and in production at once. If some of your users are not ready to upgrade to the latest version of your workflow - they can remain on the older version indefinitely - while others are are the newer version(s).  Additionally, during a migration - any workflows running on V1 will remain on V1 - and only new workflows will move to the V2 version - ensuring that the user experience of your workflows never break.
-
-
-## Big changes
-
-The biggest issue with your widget order fulfillment is that customers can only order one widget at a time. The suggestion from Bob was "just run the app a bunch of times" - and today - if there are multiple iorders, the workflow is just called multiple times.  
-
-We can do better, and in V2, we'll accept the address parameters AND the number of widgets parameter.
-
-```
-{
-  "numberOfWidgets": "12",
-  "name": "Bob McBobFace",
-  "street": "21 Bob Lane",
-  "city": "Bobville",
-  "state": "OR",
-  "zip": "53111"
-}
-```
-
-There are 2 places we will use the ```numberOfWidgets``` param.  
-
-1. We'll create a loop that calls the ```widget_shipping``` task to create ```numberOfWidgets``` labels for shipping.
-2. We'll update the HTTP Task that reorders widgets to not order one (currently hardcoded into the API call), but to reorder as many as are being shipped out.
-
-## Do/While Loop
-
-for developers, a [Do/While](/content/docs/reference-docs/do-while-task) loop should be pretty familiar.  It basically continues to repeat a set of tasks until a certain criteria is met.
-
-Here's what our Do/While task (called ```shipping_loop```) looks like:
-
-```json
- {
-      "name": "shipping_loop",
-      "taskReferenceName": "shipping_loop_ref",
-      "inputParameters": {
-        "orderCount": "${workflow.input.numberOfWidgets}"
-      },
-      "type": "DO_WHILE",
-      "decisionCases": {},
-      "defaultCase": [],
-      "forkTasks": [],
-      "startDelay": 0,
-      "joinOn": [],
-      "optional": false,
-      "defaultExclusiveJoinTask": [],
-      "asyncComplete": false,
-      "loopCondition": "if($.shipping_loop_ref['iteration'] < $.orderCount) { true; } else { false; }",
-      "loopOver": [
-        {
-          "name": "widget_shipping",
-          "taskReferenceName": "widget_shipping",
-          "inputParameters": {
-            "name": "${workflow.input.name}",
-            "street": "${workflow.input.street}",
-            "city": "${workflow.input.city}",
-            "state": "${workflow.input.state}",
-            "zip": "${workflow.input.zip}"
-          },
-          "type": "SIMPLE",
-          "decisionCases": {},
-          "defaultCase": [],
-          "forkTasks": [],
-          "startDelay": 0,
-          "joinOn": [],
-          "optional": false,
-          "defaultExclusiveJoinTask": [],
-          "asyncComplete": false,
-          "loopOver": []
-        }
-      ]
-    },
-```
-
-The ```loopCondition``` says that as long as the iterator of the loop (indexed at zero) is less than the number of widgets ordered - run the loop.
-
-This will create the shipping label and tracking number for each widget.  
-
-## Updating the reorder
-
-Since our workflow can now process more than one widget at a time, we must update our replenishment order with the number of widgets ordered. IN version 1, we had hardcoded the re-order value to one.  Now, we can use the workflow input variable ```numberOfWidgets``` to correctly update the order:
-
-```json
-{
-    "name": "reorder_widgets",
-    "taskReferenceName": "reorder_widgets_ref",
-    "inputParameters": {
-    "http_request": {
-        "uri": "http://restfuldemo.herokuapp.com/appendorder",
-        "method": "POST",
-        "body": {
-        "item": "widget",
-        "count": "${workflow.input.numberOfWidgets}"
-        },
-        "connectionTimeOut": 5000,
-        "readTimeOut": 5000
-    }
-},
-```
-
-Finally, in the output of the workflow, version one reported the address and tracking number for the one order.  We really need a JSON report of *all the orders*.  Luckily, the Do-While task creates a summary output for each task that runs inside the loop, so we can just reference the output from the loop.
-
-```json
-  "workflowOutput": {
-    "orderDetails": "${shipping_loop_ref.output}",
-    "reorder": "${reorder_widgets_ref.output.response.body}"
-  },
-```
-
-> NOTE: The workflow only terminates through the 2 terminate tasks ```terminate_success``` and ```terminate_failure```, so the ```workflowOutput``` must be updated for both tasks.  The workflow will never actually call the ```outputParameters```, but it does not hurt to update that parameter as well.
-
-
-Now, our order fulfillment operation is up and running - handling errors moderately well, updating the inventory order, and handling multiple orders per transaction.
-
-In the last section of this tutorial, we will add one more feature - using Dynamic forks to support shipping to multiple addresses.
-
-
-
-
diff --git a/docs/codelab/orderfulfillment5_5.md b/docs/codelab/orderfulfillment5_5.md
@@ -0,0 +1,136 @@
+# Versioning and Do/While loop
+# Order Fulfillment Codelab part 5.5
+
+
+Now that we have some notification of workflow failures, we can continue with our automation of our shipping workflow.  At this point, we're going to make a bigger change to the workflow - adding additional inputs that might break the current workflow.  So we'll create a new version of the workflow.
+
+## Versioning
+
+Until now, all of the changes have been made on the same workflow - as the changes have been improvements - but have not materially changed the workflow in any way.
+
+When a large change is made, a new version of the same workflow can be created.  Versions are integer based, so we've been working on V1, meaning that this next version will be V2.   
+
+What is great about versioning is that *both* workflows can be live and in production at once. If some of your users are not ready to upgrade to the latest version of your workflow - they can remain on the older version indefinitely - while others are are the newer version(s).  Additionally, during a migration - any workflows running on V1 will remain on V1 - and only new workflows will move to the V2 version - ensuring that the user experience of your workflows never break.
+
+
+## Big changes
+
+The biggest issue with your widget order fulfillment is that customers can only order one widget at a time. The suggestion from Bob was "just run the app a bunch of times" - and today - if there are multiple iorders, the workflow is just called multiple times.  
+
+We can do better, and in V2, we'll accept the address parameters AND the number of widgets parameter.
+
+```
+{
+  "numberOfWidgets": "12",
+  "name": "Bob McBobFace",
+  "street": "21 Bob Lane",
+  "city": "Bobville",
+  "state": "OR",
+  "zip": "53111"
+}
+```
+
+There are 2 places we will use the ```numberOfWidgets``` param.  
+
+1. We'll create a loop that calls the ```widget_shipping``` task to create ```numberOfWidgets``` labels for shipping.
+2. We'll update the HTTP Task that reorders widgets to not order one (currently hardcoded into the API call), but to reorder as many as are being shipped out.
+
+## Do/While Loop
+
+for developers, a [Do/While](/content/docs/reference-docs/do-while-task) loop should be pretty familiar.  It basically continues to repeat a set of tasks until a certain criteria is met.
+
+Here's what our Do/While task (called ```shipping_loop```) looks like:
+
+```json
+ {
+      "name": "shipping_loop",
+      "taskReferenceName": "shipping_loop_ref",
+      "inputParameters": {
+        "orderCount": "${workflow.input.numberOfWidgets}"
+      },
+      "type": "DO_WHILE",
+      "decisionCases": {},
+      "defaultCase": [],
+      "forkTasks": [],
+      "startDelay": 0,
+      "joinOn": [],
+      "optional": false,
+      "defaultExclusiveJoinTask": [],
+      "asyncComplete": false,
+      "loopCondition": "if($.shipping_loop_ref['iteration'] < $.orderCount) { true; } else { false; }",
+      "loopOver": [
+        {
+          "name": "widget_shipping",
+          "taskReferenceName": "widget_shipping",
+          "inputParameters": {
+            "name": "${workflow.input.name}",
+            "street": "${workflow.input.street}",
+            "city": "${workflow.input.city}",
+            "state": "${workflow.input.state}",
+            "zip": "${workflow.input.zip}"
+          },
+          "type": "SIMPLE",
+          "decisionCases": {},
+          "defaultCase": [],
+          "forkTasks": [],
+          "startDelay": 0,
+          "joinOn": [],
+          "optional": false,
+          "defaultExclusiveJoinTask": [],
+          "asyncComplete": false,
+          "loopOver": []
+        }
+      ]
+    },
+```
+
+The ```loopCondition``` says that as long as the iterator of the loop (indexed at zero) is less than the number of widgets ordered - run the loop.
+
+This will create the shipping label and tracking number for each widget.  
+
+Our new workflow now appears as :
+
+<p align="center"><img src="/content/img/codelab/of5_5_loopworkflow.png" alt="adding the do-while loop" width="800" style={{paddingBottom: 40, paddingTop: 40}} /></p>
+
+
+## Updating the reorder
+
+Since our workflow can now process more than one widget at a time, we must update our replenishment order with the number of widgets ordered. IN version 1, we had hardcoded the re-order value to one.  Now, we can use the workflow input variable ```numberOfWidgets``` to correctly update the ```count``` parameter of the reorder:
+
+```json
+{
+    "name": "reorder_widgets",
+    "taskReferenceName": "reorder_widgets_ref",
+    "inputParameters": {
+    "http_request": {
+        "uri": "http://restfuldemo.herokuapp.com/appendorder",
+        "method": "POST",
+        "body": {
+        "item": "widget",
+        "count": "${workflow.input.numberOfWidgets}"
+        },
+        "connectionTimeOut": 5000,
+        "readTimeOut": 5000
+    }
+},
+```
+
+Finally, in the output of the workflow, version one reported the address and tracking number for the one order.  We really need a JSON report of *all the orders*.  Luckily, the Do-While task creates a summary output for each task that runs inside the loop, so we can just reference the output from the loop.
+
+```json
+  "workflowOutput": {
+    "orderDetails": "${shipping_loop_ref.output}",
+    "reorder": "${reorder_widgets_ref.output.response.body}"
+  },
+```
+
+> NOTE: The workflow only terminates through the 2 terminate tasks ```terminate_success``` and ```terminate_failure```, so the ```workflowOutput``` must be updated for both tasks.  The workflow will never actually call the ```outputParameters```, but it does not hurt to update that parameter as well.
+
+
+Now, our order fulfillment operation is up and running - handling errors moderately well, updating the inventory order, and handling multiple orders per transaction.
+
+In the last section of this tutorial, we will add one more feature - using Dynamic forks to support shipping to multiple addresses.
+
+
+
+