aboutsummaryrefslogtreecommitdiffstats
path: root/docs/modelingconcepts/artifact-type.rst
blob: 3dda2c4eda328836b1a99d27303f4e15cb726939 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
.. This work is a derivative of https://wiki.onap.org/display/DW/Modeling+Concepts#Concepts-1386016968
.. This work is licensed under a 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.jpg
         :width: 500pt
         :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"
         }