diff options
Diffstat (limited to 'docs/microservices')
| -rw-r--r-- | docs/microservices/bluePrintsProcessorMS.rst | 8 | ||||
| -rw-r--r-- | docs/microservices/controllerBlueprintStudioProcessorMS.rst | 13 | ||||
| -rw-r--r-- | docs/microservices/expression.rst | 45 | ||||
| -rw-r--r-- | docs/microservices/images/blueprintprocessor.jpg | bin | 0 -> 47208 bytes | |||
| -rw-r--r-- | docs/microservices/workflow.rst | 73 |
5 files changed, 132 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/expression.rst b/docs/microservices/expression.rst new file mode 100644 index 000000000..38a7d624c --- /dev/null +++ b/docs/microservices/expression.rst @@ -0,0 +1,45 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 +.. International License. http://creativecommons.org/licenses/by/4.0 +.. Copyright (C) 2019 IBM. + +Expression +========== + +TOSCA provides for a set of functions to reference elements within the template or to retrieve runtime values. + +Below is a list of supported expressions + +get_input +--------- + +The get_input function is used to retrieve the values of properties declared within the inputs section of a TOSCA Service Template. + +http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454178 + +get_property +------------ + +The get_property function is used to retrieve property values between modelable entities defined in the same service template. + +http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454178 + +get_attribute +------------- + +The get_attribute function is used to retrieve the values of named attributes declared by the referenced node or relationship template name. + +http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454179 + +get_operation_output +-------------------- + +The get_operation_output function is used to retrieve the values of variables exposed / exported from an interface operation. + +http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454180 + +get_artifact +------------ + +The get_artifact function is used to retrieve artifact location between modelable entities defined in the same service template. + +http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454182 diff --git a/docs/microservices/images/blueprintprocessor.jpg b/docs/microservices/images/blueprintprocessor.jpg Binary files differnew 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 |
