diff options
author | 2020-08-04 20:46:50 +0200 | |
---|---|---|
committer | 2020-08-04 20:46:59 +0200 | |
commit | 7c3f39504a14c056d860e09ece970ccde349053f (patch) | |
tree | 47817becf6b1a3e481dfd6230c4f15d4f719bd2a /docs/modelingconcepts/artifact-type.rst | |
parent | 4a01363c4634a62946d6f2befe00cbf2d9872d90 (diff) |
Adding Modeling Concepts documentation from COnfluence to RDT
Issue-ID: CCSDK-2615
Change-Id: Ib5dfaecc96e8fac1dda07aa6c13aba5ded81efee
Signed-off-by: JakobKrieg <jakob.krieg@bcmsolutions.de>
Diffstat (limited to 'docs/modelingconcepts/artifact-type.rst')
-rw-r--r-- | docs/modelingconcepts/artifact-type.rst | 186 |
1 files changed, 186 insertions, 0 deletions
diff --git a/docs/modelingconcepts/artifact-type.rst b/docs/modelingconcepts/artifact-type.rst new file mode 100644 index 000000000..15a968e18 --- /dev/null +++ b/docs/modelingconcepts/artifact-type.rst @@ -0,0 +1,186 @@ +.. This work is a derivative of https://wiki.onap.org/display/DW/Modeling+Concepts#Concepts-1386016968 by IBM +.. used under Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright (C) 2020 Deutsche Telekom AG. + +.. _artifact_type: + +Artifact Type +------------------------------------- + +Represents the **type of a artifact**, used to **identify** the +**implementation** of the functionality supporting this type of artifact. + +`TOSCA definition <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454213>`_ + +This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSCA node for all artifact. + +.. code-block:: JSON + :caption: **tosca.artifacts.Implementation** + + { + "description": "TOSCA base type for implementation artifacts", + "version": "1.0.0", + "derived_from": "tosca.artifacts.Root" + } + +**Bellow is a list of supported artifact types** + +.. tabs:: + + .. tab:: Velocity + + **artifact-template-velocity** + + Represents an Apache Velocity template. + + Apache Velocity allow to insert **logic** (if / else / loops / etc) when processing the output of a template/text. + + File must have **.vtl** extension. + + The **template** can represent anything, such as device config, payload to interact with 3rd party systems, + :ref:`resource-accumulator template`, etc... + + Often a template will be **parameterized**, and each **parameter** + must be defined within an mapping file (see 'Mapping' in this tab). + + `Velocity reference document <http://velocity.apache.org/engine/1.7/user-guide.html>`_ + + `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-template-velocity.json>`_ + is the TOSCA artifact type: + + .. code-block:: JSON + :caption: **artifact-template-velocity** + + { + "description": "TOSCA base type for implementation artifacts", + "version": "1.0.0", + "derived_from": "tosca.artifacts.Root" + } + + .. tab:: Jinja + + **artifact-template-jinja** + + Represents an Jinja template. + + Jinja template allow to insert **logic** (if / else / loops / etc) when processing the output of a template/text. + + File must have **.jinja** extension. + + The **template** can represent **anything**, such as device config, + payload to interact with 3rd party systems, :ref:`resource-accumulator template`, etc... + + Often a template will be parameterized, and each parameter must be defined within an :ref:`mapping file`. + + `Jinja reference document <https://jinja.palletsprojects.com/en/2.10.x/>`_ + + `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-template-jinja.json>`_ + is the TOSCA artifact type: + + .. code-block:: JSON + :caption: **artifact-template-jinja** + + { + "description": " Jinja Template used for Configuration", + "version": "1.0.0", + "file_ext": [ + "jinja" + ], + "derived_from": "tosca.artifacts.Implementation" + } + + .. tab:: Mapping + + **artifact-mapping-resource** + + This type is meant to represent **mapping** files defining the **contract of each resource** to be resolved. + + Each **parameter** in a template **must** have a corresponding mapping definition, + modeled using datatype-resource-assignment (see :ref:`data_type`-> resources-asignment). + + Hence the mapping file is meant to be a list of entries defined using datatype-resource-assignment + (see :ref:`data_type`-> resources-asignment). + + File must have **.json** extension. + + The **template** can represent **anything**, such as device config, + payload to interact with 3rd party systems, resource-accumulator template, etc... + + `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-mapping-resource.json>`_ + is the TOSCA artifact type: + + .. code-block:: JSON + :caption: **artifact-mapping-resource** + + { + "description": "Resource Mapping File used along with Configuration template", + "version": "1.0.0", + "file_ext": [ + "json" + ], + "derived_from": "tosca.artifacts.Implementation" + } + + The mapping file basically contains a reference to the data dictionary to use + to resolve a particular resource. + + The data dictionary defines the HOW and the mapping defines the WHAT. + + **Relation between data dictionary, mapping and template.** + + Below are two examples using color coding to help understand the relationships. + + In orange is the information regarding the template. As mentioned before, + template is part of the blueprint itself, and for the blueprint to know what template to use, + the name has to match. + + In green is the relationship between the value resolved within the template, + and how it's mapped coming from the blueprint. + + In blue is the relationship between a resource mapping to a data dictionary. + + In red is the relationship between the resource name to be resolved and the HEAT environment variables. + + The key takeaway here is that whatever the value is for each color, it has to match all across. + This means both right and left hand side are equivalent; it's all on the designer to express + the modeling for the service. That said, best practice is example 1. + + .. image:: ../media/dd_mapping_template_rel.png + :scale: 100 % + :align: center + + .. tab:: Directed Graph + + **artifact-directed-graph** + + Represents a directed graph. + + This is to represent a **workflow**. + + File must have **.xml** extension. + + Here is the list of executors currently supported (see here for explanation and full potential list: + `Service Logic Interpreter Nodes <https://wiki.onap.org/display/DW/Service+Logic+Interpreter+Nodes>`_ + + * execute + * block + * return + * break + * exit + + `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-directed-graph.json>`_ + is the TOSCA artifact type: + + .. code-block:: json + :caption: **artifact-directed-graph** + + { + "description": "Directed Graph File", + "version": "1.0.0", + "file_ext": [ + "json", + "xml" + ], + "derived_from": "tosca.artifacts.Implementation" + } |