4 files changed, 87 insertions, 7 deletions
diff --git a/docs/microservices/bluePrintsProcessorMS.rst b/docs/microservices/bluePrintsProcessorMS.rst
index 911f99945..3f308138f 100644
--- a/docs/microservices/bluePrintsProcessorMS.rst
+++ b/docs/microservices/bluePrintsProcessorMS.rst
@@ -14,7 +14,7 @@ Micro service to Manage Controller Blueprint Models, such as Resource Dictionary
 This microservice is used to deploy Controller Blueprint Archive file in Run time database. This also helps to test the Valid Blueprint.
 
 Architecture:
-==============
+-------------
 
 |image0|
 
@@ -23,7 +23,7 @@ Architecture:
    :width: 800px
    
 Running Blueprints Processor Microservice Locally:
-==================================================
+--------------------------------------------------
 
 The purpose of this page is to show how to run the Blueprints Processor microservice locally, using the docker-compose.yaml file provided in the project.
 
@@ -48,7 +48,7 @@ Build it using the Maven profile called Docker:
     mvn clean install -Pdocker
 	
 Start Docker containers using docker-composer:
-==============================================
+----------------------------------------------
 
 Navigate to the docker-compose file in the distribution module:
 
@@ -66,7 +66,7 @@ To verify the logs generated by docker-composer, type:
 	
 	
 Testing the environment:
-========================
+------------------------
 
 Point your browser to http://localhost:8000/api/v1/execution-service/ping (please note that the port is 8000, not 8080)
 
diff --git a/docs/microservices/controllerBlueprintStudioProcessorMS.rst b/docs/microservices/controllerBlueprintStudioProcessorMS.rst
index 5c67d6c1d..683b6943d 100644
--- a/docs/microservices/controllerBlueprintStudioProcessorMS.rst
+++ b/docs/microservices/controllerBlueprintStudioProcessorMS.rst
@@ -10,7 +10,7 @@ The Controller Blueprint Archive is the overall service design, fully model-driv
 The CBA is .zip file which is saved in Controller Blueprint Database.
 
 Dynamic API:
-===========
+------------
 
 The nature of the API request and response is meant to be model driven and dynamic. They both share the same definition.
 
@@ -22,11 +22,18 @@ The first top level element will always be either $actionName-request for a requ
 
 Then the content within this element is fully based on the workflow input and output.
 
+.. toctree::
+   :maxdepth: 1
+   
+   dynamicapi
 
 Enrichment:
-===========
+-----------
 
 Helps to generate complete valid CBA file.
 
-  
+.. toctree::
+   :maxdepth: 1
+   
+   enrichment
    
 \ No newline at end of file
diff --git a/docs/microservices/images/blueprintprocessor.jpg b/docs/microservices/images/blueprintprocessor.jpg
new file mode 100644
index 000000000..c618e0e32
--- /dev/null
+++ b/docs/microservices/images/blueprintprocessor.jpg
diff --git a/docs/microservices/workflow.rst b/docs/microservices/workflow.rst
new file mode 100644
index 000000000..b74a49d2b
--- /dev/null
+++ b/docs/microservices/workflow.rst
@@ -0,0 +1,73 @@
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2019 IBM.
+
+Workflow
+========
+
+A workflow defines an overall action to be taken on the service, hence is an entry-point for the run-time execution of the CBA package.
+
+A workflow also defines inputs and outputs that will defined the payload contract of the request and response (see Dynamic API)
+
+A workflow can be composed of one or multiple sub-actions to execute.
+
+A CBA package can have as many workflows as needed.
+
+Single action
+-------------
+
+The workflow is directly backed by a node_template of type tosca.nodes.Component
+
+Multiple sub-actions
+--------------------
+The workflow is backed by Directed Graph engine, node_template of type dg-generic, and are imperative workflows.
+
+A DG used as workflow for CDS is composed of multiple execute nodes; each individual execute node refers to a plugin, that is a node_template of type tosca.nodes.Component.
+
+Below the properties of a workflow:
+
+
+
+Workflow Example
+----------------
+
+.. code:: json
+
+print("
+{
+  "workflow": {
+    "resource-assignment": {                                <- workflow-name
+      "inputs": {
+        "vnf-id": {                                         <- static inputs
+          "required": true,
+          "type": "string"
+        },
+        "resource-assignment-properties": {                    <- dynamic inputs
+          "required": true,
+          "type": "dt-resource-assignment-properties"
+        }
+      },
+      "steps": {
+        "call-resource-assignment": {                       <- step-name
+          "description": "Resource Assignment Workflow",
+          "target": "resource-assignment-process"           <- node_template targeted by the step
+        }
+      },
+      "outputs": {
+        "template-properties": {                            <- output
+          "type": "json",                                   <- complex type
+          "value": {
+            "get_attribute": [                              <- uses expression to retrieve attribute from context
+              "resource-assignment",
+              "assignment-params"
+            ]
+          }
+        }
+      }
+    }
+  }
+}
+")
+
+
+TOSCA definition: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454203
+\ No newline at end of file