16 files changed, 392 insertions, 34 deletions
diff --git a/docs/CBA/index.rst b/docs/CBA/index.rst
index c7b219f5c..43317e6e5 100644
--- a/docs/CBA/index.rst
+++ b/docs/CBA/index.rst
@@ -2,8 +2,8 @@
 .. http://creativecommons.org/licenses/by/4.0
 .. Copyright (C) 2019 IBM.
 
-Controller Blueprint Archived Tool(CBA)
-----------------------------------------
+Controller Blueprint Archived Designer Tool(CBA)
+------------------------------------------------
 .. toctree::
    :maxdepth: 1
    
diff --git a/docs/CBA/resourceassignment.rst b/docs/CBA/resourceassignment.rst
index be8b08e25..eec6ba368 100644
--- a/docs/CBA/resourceassignment.rst
+++ b/docs/CBA/resourceassignment.rst
@@ -4,9 +4,6 @@
 
 Resource Assignment 
 ===================
-.. toctree::
-   :maxdepth: 1
-   
    
 Component executor:
 ===================
diff --git a/docs/bluePrintsProcessor.rst b/docs/bluePrintsProcessor.rst
index a687d50be..911f99945 100644
--- a/docs/bluePrintsProcessor.rst
+++ b/docs/bluePrintsProcessor.rst
@@ -11,6 +11,8 @@ Blueprints Processor
    
 Micro service to Manage Controller Blueprint Models, such as Resource Dictionary, Service Models, Velocity Templates etc,  which will serve service for Controller Design Studio and Controller runtimes.
 
+This microservice is used to deploy Controller Blueprint Archive file in Run time database. This also helps to test the Valid Blueprint.
+
 Architecture:
 ==============
 
@@ -18,4 +20,54 @@ Architecture:
 
 .. |image0| image:: images/blueprintprocessor.jpg
    :height: 600px
-   :width: 800px
-\ No newline at end of file
+   :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.
+
+Check out the CDS' code:
+
+Check out the latest code from Gerrit: https://gerrit.onap.org/r/#/admin/projects/ccsdk/cds
+
+Build CDS locally:
+In the checked out directory, type
+
+    mvn clean install -DskipTests=true -Dmaven.test.skip=true -Dmaven.javadoc.skip=true -Dadditionalparam=-Xdoclint:none
+	
+Create the needed Docker images:
+
+The Blueprints Processor microservice project has a module, called distribution, that provides a docker-compose.yaml file that can be used to spin up Docker containers to run this microservice.
+
+The first step is to create any custom image needed, by building the distribution module.  From the CDS home directory (where the code was checked out), navigate to the module:
+
+    cd ms/blueprintsprocessor/distribution/
+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:
+
+    cd src/main/dc/
+	
+From there, start the containers:
+
+    docker-compose up -d
+This will spin the Docker containers declared inside the docker-compose.yaml file in the background.
+
+
+To verify the logs generated by docker-composer, type:
+
+    docker-compose logs -f
+	
+	
+Testing the environment:
+========================
+
+Point your browser to http://localhost:8000/api/v1/execution-service/ping (please note that the port is 8000, not 8080)
+
+To authenticate, use ccsdkapps / ccsdkapps as login / password.
+\ No newline at end of file
diff --git a/docs/controllerBlueprintStudioProcessor.rst b/docs/controllerBlueprintStudioProcessor.rst
index fc9112296..5c67d6c1d 100644
--- a/docs/controllerBlueprintStudioProcessor.rst
+++ b/docs/controllerBlueprintStudioProcessor.rst
@@ -5,6 +5,28 @@
 Controller Blueprints Studio Processor
 ======================================
 
-.. toctree::
-   :maxdepth: 1
-   :titlesonly:
-\ No newline at end of file
+The Controller Blueprint Archive is the overall service design, fully model-driven, intent based package needed for SELF SERVICE provisioning and configuration management automation.
+
+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.
+
+The actionName, under the actionIdentifiers refers to the name of a Workflow (see workflow)
+
+The content of the payload is what is fully dynamic / model driven.
+
+The first top level element will always be either $actionName-request for a request or $actionName-response for a response.
+
+Then the content within this element is fully based on the workflow input and output.
+
+
+Enrichment:
+===========
+
+Helps to generate complete valid CBA file.
+
+  
+   
+\ No newline at end of file
diff --git a/docs/datadictionary/capabilitytable.JPG b/docs/datadictionary/capabilitytable.JPG
new file mode 100644
index 000000000..7db4715ea
--- /dev/null
+++ b/docs/datadictionary/capabilitytable.JPG
diff --git a/docs/datadictionary/index.rst b/docs/datadictionary/index.rst
index 83c6e47b8..a7e78564f 100644
--- a/docs/datadictionary/index.rst
+++ b/docs/datadictionary/index.rst
@@ -9,37 +9,74 @@ Resource Definition
 
 Introduction:
 =============
-A Resource Definition defines a specifc resource that can be resolved using the bellow supported sources.
+A data dictionary models the how a specific resource can be resolved.
 
-A Resource Definition can support multiple sources.
+A resource is a variable/parameter in the context of the service. It can be anything, but it should not be confused with SDC or Openstack resources.
 
-The main goal of Resource Definition is to define generic entity that could be shared accross services.
+A data dictionary can have multiple sources to handle resolution in different ways.
 
+The main goal of data dictionary is to define re-usable entity that could be shared.
 
-Resolution sources:
-===================
+Creation of data dictionaries is a standalone activity, separated from the blueprint design.
 
-   * Input
-   * Default
-   * DB
-   * REST
-   * Capability
 
-Artifacts:
-==========
+As part of modelling a data dictionary entry, the following generic information should be provided:
 
-   * artifact-mapping-resource
-   * artifact-template-velocity
-   * artifact-directed-graph
+|image0|
 
-Node type:
-==========
-	
-   * component-resource-resolution
-   * component-jython-executor
-   * component-netconf-executor
-   * component-restconf-executor
+.. |image0| image:: media/image0.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
 
-Data type:
-==========
-   * vnf-netconf-device
-\ No newline at end of file
+Bellow are properties that all the resource source have will have
+
+The modeling does allow for data translation between external capability and CDS for both input and output key mapping.
+
+|image1|
+
+.. |image1| image:: media/image0.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
+
+Example:
+========
+
+vf-module-model-customization-uuid and vf-module-label are two data dictionaries. A SQL table, VF_MODULE_MODEL, exist to correlate them.
+
+Here is how input-key-mapping, output-key-mapping and key-dependencies can be used:
+
+vf-module-label data dictionary  
+
+{
+  "name" : "vf-module-label",
+  "tags" : "vf-module-label",
+  "updated-by" : "adetalhouet",
+  "property" : {
+    "description" : "vf-module-label",
+    "type" : "string"
+  },
+  "sources" : {
+    "primary-db" : {
+      "type" : "source-primary-db",
+      "properties" : {
+        "type" : "SQL",
+        "query" : "select sdnctl.VF_MODULE_MODEL.vf_module_label as vf_module_label from sdnctl.VF_MODULE_MODEL where sdnctl.VF_MODULE_MODEL.customization_uuid=:customizationid",
+        "input-key-mapping" : {
+          "customizationid" : "vf-module-model-customization-uuid"
+        },
+        "output-key-mapping" : {
+          "vf-module-label" : "vf_module_label"
+        },
+        "key-dependencies" : [ "vf-module-model-customization-uuid" ]
+      }
+    }
+  }
+}
+
+
+Resource source:
+================
+
+Defines the contract to resolve a resource.
+
+A resource source is modeled, following http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#DEFN_ENTITY_NODE_TYPE, and derives from the https://wiki.onap.org/display/DW/Modeling+Concepts#ModelingConcepts-NodeResourceSource
+\ No newline at end of file
diff --git a/docs/datadictionary/media/image0.JPG b/docs/datadictionary/media/image0.JPG
new file mode 100644
index 000000000..074d20076
--- /dev/null
+++ b/docs/datadictionary/media/image0.JPG
diff --git a/docs/datadictionary/media/image1.JPG b/docs/datadictionary/media/image1.JPG
new file mode 100644
index 000000000..a27502a75
--- /dev/null
+++ b/docs/datadictionary/media/image1.JPG
diff --git a/docs/datadictionary/resourcesource.rst b/docs/datadictionary/resourcesource.rst
new file mode 100644
index 000000000..fffeec313
--- /dev/null
+++ b/docs/datadictionary/resourcesource.rst
@@ -0,0 +1,110 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2019 IBM.
+
+Resource Source 
+---------------
+
+Input:
+======
+Expects the value to be provided as input to the request.
+
+source-input:
+
+{
+  "description": "This is Input Resource Source Node Type",
+  "version": "1.0.0",
+  "properties": {},
+  "derived_from": "tosca.nodes.ResourceSource"
+}
+
+
+Default:
+========
+Expects the value to be defaulted in the model itself.
+
+source-default:
+
+{
+  "description": "This is Default Resource Source Node Type",
+  "version": "1.0.0",
+  "properties": {},
+  "derived_from": "tosca.nodes.ResourceSource"
+}
+
+
+sql:
+====
+
+Expects the SQL query to be modeled; that SQL query can be parameterized, and the parameters be other resources resolved through other means. If that's the case, this data dictionary definition will have to define key-dependencies along with input-key-mapping.
+
+CDS is currently deployed along the side of SDNC, hence the primary database connection provided by the framework is to SDNC database.
+
+|image0|
+
+.. |image0| image:: image0.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
+
+.. toctree::
+   :maxdepth: 1  
+
+	sourceprimarydb
+	
+Connection to a specific database can be expressed through the endpoint-selector property, which refers to a macro defining the information about the database the connect to. Understand TOSCA Macro in the context of CDS.
+
+.. toctree::
+   :maxdepth: 1 
+
+	dbsystem
+
+
+REST:
+=====
+
+Expects the URI along with the VERB and the payload, if needed.
+
+CDS is currently deployed along the side of SDNC, hence the default rest connection provided by the framework is to SDNC MDSAL.
+
+|image1|
+
+.. |image1| image:: image1.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
+
+.. toctree::
+   :maxdepth: 1
+   
+   rest
+
+Connection to a specific REST system can be expressed through the endpoint-selector property, which refers to a macro defining the information about the REST system the connect to. Understand TOSCA Macro in the context of CDS.
+
+Few ways are available to authenticate to the REST system:
+
+	* token-auth
+	* basic-auth
+	* ssl-basic-auth
+	
+For source code of Authentication click below link:
+
+.. toctree::
+   :maxdepth: 1
+   
+   auth
+
+Capability:
+===========
+
+Expects a script to be provided.
+
+|image2|
+
+.. |image2| image:: image2.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
+   
+   
+.. toctree::
+   :maxdepth: 1   
+
+	source-capability   
diff --git a/docs/datadictionary/restauth.rst b/docs/datadictionary/restauth.rst
new file mode 100644
index 000000000..40c179375
--- /dev/null
+++ b/docs/datadictionary/restauth.rst
@@ -0,0 +1,42 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2019 IBM.
+
+
+Resource Rest Authentication 
+----------------------------
+
+token-auth:
+
+"dsl_definitions": {
+  "dynamic-rest-source": {
+    "type" : "token-auth",
+    "url" : "http://localhost:32778",
+    "token" : "Token 0123456789abcdef0123456789abcdef01234567"
+  }
+}
+
+basic-auth:
+
+"dsl_definitions": {
+  "dynamic-rest-source": {
+    "type" : "basic-auth",
+    "url" : "http://localhost:32778",
+    "username" : "bob",
+    "password": "marley"
+ }
+}
+
+ssl-basic-auth:
+
+"dsl_definitions": {
+  "dynamic-rest-source": {
+    "type" : "ssl-basic-auth",
+    "url" : "http://localhost:32778",
+    "keyStoreInstance": "JKS or PKCS12",
+    "sslTrust": "trusture",
+    "sslTrustPassword": "trustore password",
+    "sslKey": "keystore",
+    "sslKeyPassword: "keystore password"
+ }
+}
+\ No newline at end of file
diff --git a/docs/datadictionary/resttable.JPG b/docs/datadictionary/resttable.JPG
new file mode 100644
index 000000000..568ad0a9f
--- /dev/null
+++ b/docs/datadictionary/resttable.JPG
diff --git a/docs/datadictionary/sqltable.JPG b/docs/datadictionary/sqltable.JPG
new file mode 100644
index 000000000..15d246743
--- /dev/null
+++ b/docs/datadictionary/sqltable.JPG
diff --git a/docs/index.rst b/docs/index.rst
index 8db565a37..5f3902687 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -13,6 +13,24 @@ The system is designed to be self service, which means that users, not just prog
 Self service is a completely new way of delivering services.  It removes the dependence on code releases and the delays they cause and puts the control of services into the hands of the service providers.  They can change a model and its parameters and create a new service without writing a single line of code.  
 This makes SERVICE PROVIDER(S) more responsive to its customers and able to deliver products that more closely match the needs of its customers.
 
+Modeling Concept:
+=================
+In Dublin release, the CDS community has contributed a framework to automate the resolution of resources for instantiation and any config provisioning operation, such as day0, day1 or day2 configuration.
+
+The content of the CBA Package is driven from a catalog of reusable data dictionary, component and workflow, delivering a reusable and simplified self service experience.
+
+TOSCA based JSON formatted model following standard: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html
+
+Most of the TOSCA modeled entity presented in the bellow documentation can be found here: https://github.com/onap/ccsdk-cds/tree/master/components/model-catalog/definition-type/starter-type
+
+Tosca Model Reference: 
+
+|image0|
+
+.. |image0| image:: media/image0.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
+
 Design tools:
 =============
 .. toctree::
@@ -38,6 +56,13 @@ The Controller Design Studio is composed of two major components:
 	* The Run Time (or backend)  
 The GUI handles direct user input and allows for displaying both design time and run time activities.  For design time, it allows for the creation of controller blueprint, from selecting the DGs to be included, to incorporating the artifact templates, to adding necessary components.  For run time, it allows the user to direct the system to resolve the unresolved elements of the controller blueprint and download the resulting configuration into a VNF.  At a more basic level, it allows for creation of data dictionaries, capabilities catalogs, and controller blueprint, the basic elements that are used to generate a configuration. The essential function of the Controller Design Studio is to create and populate a controller blueprint, create a configuration file from this Controller blueprint, and download this configuration file (configlet) to a VNF/PNF.
 
+|image0|
+
+.. |image0| image:: media/CDS_architecture.jpg
+   :height: 4.43750in
+   :width: 7.88889in
+
+
 Resource assignment:
 =====================
 .. toctree::
diff --git a/docs/media/CDS_architecture.JPG b/docs/media/CDS_architecture.JPG
new file mode 100644
index 000000000..c8528ac1e
--- /dev/null
+++ b/docs/media/CDS_architecture.JPG
diff --git a/docs/media/image0.jpg b/docs/media/image0.jpg
new file mode 100644
index 000000000..dce3cee25
--- /dev/null
+++ b/docs/media/image0.jpg
diff --git a/docs/resourceassignment.rst b/docs/resourceassignment.rst
new file mode 100644
index 000000000..be8b08e25
--- /dev/null
+++ b/docs/resourceassignment.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.
+
+Resource Assignment 
+===================
+.. toctree::
+   :maxdepth: 1
+   
+   
+Component executor:
+===================
+Workflow:
+=========
+
+A workflow defines an overall action to be taken for the service; it can be composed of a set of sub-actions to execute. Currently, workflows are backed by Directed Graph engine.
+
+A CBA can have as many workflow as needed.
+
+Template:
+=========
+
+A template is an artifact.
+
+A template is parameterized and each parameter must be defined in a corresponding mapping file.
+
+In order to know which mapping correlate to which template, the file name must start with an artifact-prefix, serving as identifier to the overall template + mapping.
+
+The requirement is as follow:
+
+${artifact-prefix}-template
+${artifact-prefix}-mapping
+
+A template can represent anything, such as device config, payload to interact with 3rd party systems, resource-accumulator template, etc...
+
+Mapping:
+========
+Defines the contract of each resource to be resolved. Each placeholder in the template must have a corresponding mapping definition.
+
+A mapping is comprised of:
+
+- name
+- required / optional
+- type (support complex type)
+- dictionary-name
+- dictionary-source
+
+Dependencies:
+=============
+
+This allows to make sure given resources get resolved prior the resolution of the resources defining the dependency.
+The dictionary fields reference to a specific data dictionary.
+
+Resource accumulator:
+=====================
+
+In order to resolve HEAT environment variables, resource accumulator templates are being in used for Dublin.
+
+These templates are specific to the pre-instantiation scenario, and relies on GR-API within SDNC.
+
+It is composed of the following sections:
+
+resource-accumulator-resolved-data: defines all the resources that can be resolved directly from the context. It expresses a direct mapping between the name of the resource and its value.
+
+capability-data: defines what capability to use to create a specific resource, along with the ingredients required to invoke the capability and the output mapping.
+
+- Scripts
+- Library
+- NetconfClient
+
+In order to facilitate NETCONF interaction within scripts, a python NetconfClient binded to our Kotlin implementation is made available. This NetconfClient can be used when using the netconf-component-executor.
+
+The client can be find here: https://github.com/onap/ccsdk-apps/blob/master/components/scripts/python/ccsdk_netconf/netconfclient.py
+\ No newline at end of file