aboutsummaryrefslogtreecommitdiffstats
path: root/docs/modelingconcepts/artifact-type.rst
diff options
context:
space:
mode:
authorJakobKrieg <jakob.krieg@bcmsolutions.de>2020-08-04 20:46:50 +0200
committerJakobKrieg <jakob.krieg@bcmsolutions.de>2020-08-04 20:46:59 +0200
commit7c3f39504a14c056d860e09ece970ccde349053f (patch)
tree47817becf6b1a3e481dfd6230c4f15d4f719bd2a /docs/modelingconcepts/artifact-type.rst
parent4a01363c4634a62946d6f2befe00cbf2d9872d90 (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.rst186
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"
+ }