Add stndDefined domain docs

Change-Id: If61d0b649907c18e2c82ab5a6fa8617edee11e7d
Signed-off-by: Michal Banka <michal.banka@nokia.com>
Issue-ID: DCAEGEN2-2702

5 files changed, 56 insertions, 12 deletions

diff --git a/docs/sections/apis/ves-hv/index.rst b/docs/sections/apis/ves-hv/index.rst
index c3ccfa0c..c82391d4 100644
--- a/docs/sections/apis/ves-hv/index.rst
+++ b/docs/sections/apis/ves-hv/index.rst
@@ -41,7 +41,7 @@ Payload is binary-encoded, using Google Protocol Buffers (GPB) representation of
 .. literalinclude:: VesEvent.proto
     :language: protobuf
 
-HV-VES makes routing decisions based mostly on the content of the **Domain** parameter in the VES Common Event Header.
+HV-VES makes routing decisions based on the content of the **domain** field or **stndDefinedNamespace** field in case of stndDefined events.
 
 The PROTO file, which contains the VES CommonEventHeader, comes with a binary-type Payload (eventFields) parameter, where domain-specific
 data should be placed. Domain-specific data are encoded as well with GPB. A domain-specific PROTO file is required to decode the data.
@@ -49,15 +49,15 @@ data should be placed. Domain-specific data are encoded as well with GPB. A doma
 API towards DMaaP
 =================
 
-HV-VES Collector forwards incoming messages to a particular DMaaP Kafka topic based on the domain and configuration. Every Kafka record is comprised of a key and a value. In case of HV-VES:
+HV-VES Collector forwards incoming messages to a particular DMaaP Kafka topic based on the domain (or stndDefinedNamespace) and configuration. Every Kafka record is comprised of a key and a value. In case of HV-VES:
 
 - **Kafka record key** is a GPB-encoded `CommonEventHeader`.
 - **Kafka record value** is a GPB-encoded `VesEvent` (`CommonEventHeader` and domain-specific `eventFields`).
 
 In both cases raw bytes might be extracted using ``org.apache.kafka.common.serialization.ByteArrayDeserializer``. The resulting bytes might be further passed to ``parseFrom`` methods included in classes generated from GPB definitions. WTP is not used here - it is only used in communication between PNF/VNF and the collector.
 
-By default, **HV-VES** will use routing defined in **k8s-hv-ves.yaml-template** in **dcaegen2/platform/blueprints project**.
-Currently there is one domain->topic mapping defined: perf3gpp->HV_VES_PERF3GPP
+By default, **HV-VES** will use routing defined in **k8s-hv-ves.yaml-template** in **dcaegen2/platform/blueprints project** when deployed using Cloudify.
+In case of Helm deployment routing is defined in values.yaml file in HV-VES Helm Chart.
 
 
 .. _supported_domains:
@@ -65,7 +65,10 @@ Currently there is one domain->topic mapping defined: perf3gpp->HV_VES_PERF3GPP
 Supported domains
 =================
 
-As for now **HV-VES** supports only **perf3gpp** domain
+Domains that are currently supported by HV-VES:
+
+- perf3gpp - basic domain to Kafka topic mapping
+- stndDefined - specific routing, when event has this domain, then stndDefinedNamespace field value is mapped to Kafka topic
 
 For domains descriptions, see :ref:`domains_supported_by_hvves`
 
diff --git a/docs/sections/apis/ves-hv/supported-domains.rst b/docs/sections/apis/ves-hv/supported-domains.rst
index 68d5d226..3e24f2a9 100644
--- a/docs/sections/apis/ves-hv/supported-domains.rst
+++ b/docs/sections/apis/ves-hv/supported-domains.rst
@@ -84,7 +84,29 @@ Each row of the table corresponds to one field where a choice is to be made. For
 .. note:: *MeasResult.p* can be used to reduce the event size when more than half of the values in the event are zero values, and these values are not sent to ONAP. Only non-zero values are sent, together with their *MeasInfo.MeasTypes* index (*MeasResult.p*).
 
 
-
-
-
-
+.. _stndDefined_domain:
+
+stndDefined domain
+------------------
+
+The purpose of 'stndDefined' domain was to allow collection of events defined by standard organizations using HV-VES,
+and providing them for consumption by analytics applications running on top of DCAE platform.
+
+All events, except those with 'stndDefined' domain, are routed to DMaaP topics based on domain value. Events with
+'stndDefined' domain are sent to proper topic basing on field 'stndDefinedNamespace'.
+
+This is the only difference from standard event routing, specific for 'stndDefined' domain. As in every other event
+routing value is being mapped for specific Kafka topic. Mappings to Kafka topics are located in HV-VES Helm Chart
+values.yaml file. Four of them are by default available in HV-VES:
+
++-------------+--------------------------------+--------------------------------------+
+| Domain      | StndDefinedNamespace           | Kafka topic                          |
++=============+================================+======================================+
+| stndDefined | ves-3gpp-fault-supervision     | SEC_3GPP_FAULTSUPERVISION_OUTPUT     |
++-------------+--------------------------------+--------------------------------------+
+| stndDefined | ves-3gpp-provisioning          | SEC_3GPP_PROVISIONING_OUTPUT         |
++-------------+--------------------------------+--------------------------------------+
+| stndDefined | ves-3gpp-heartbeat             | SEC_3GPP_HEARTBEAT_OUTPUT            |
++-------------+--------------------------------+--------------------------------------+
+| stndDefined | ves-3gpp-performance-assurance | SEC_3GPP_PERFORMANCEASSURANCE_OUTPUT |
++-------------+--------------------------------+--------------------------------------+
diff --git a/docs/sections/services/ves-hv/design.rst b/docs/sections/services/ves-hv/design.rst
index 579b4acf..899b0c05 100644
--- a/docs/sections/services/ves-hv/design.rst
+++ b/docs/sections/services/ves-hv/design.rst
@@ -15,8 +15,8 @@ HV-VES follows the VES-JSON schema as much as possible.
 
 - HV-VES uses a Google Protocol Buffers (GPB, proto files) representation of the VES Common Header.
 - The proto files use most encoding-effective types defined by GPB to cover Common Header fields.
-- HV-VES makes routing decisions based mostly on the content of the **Domain** parameter.
-- HV-VES allows to embed Payload of different types (by default perf3gpp domain is included).
+- HV-VES makes routing decisions based on the content of the **domain** field or **stndDefinedNamespace** field in case of stndDefined events.
+- HV-VES allows to embed Payload of different types (by default perf3gpp and stndDefined domains are included).
 
 Analytics applications impacts
 
@@ -36,6 +36,11 @@ This domain-specific proto has to be shared with analytics applications - HV-VES
 In order to support the RT-PM use-case, HV-VES uses a **perf3gpp** domain proto file. Within this domain, high volume data are expected to be reported to HV-VES collector.
 Additional domains can be defined based on existing VES domains (like Fault, Heartbeat) or completely new domains. New domains can be added when needed.
 
+There is also **stndDefined** domain supported by default in HV-VES. Events with this domain are expected to contain
+data payload described by OpenAPI schemas. HV-VES doesn't decode payload of stndDefined events thus it does not contain
+specific **stndDefined** proto files. The only difference of **stndDefined** domain is its specific routing. More
+details of stndDefined routing: :ref:`_stndDefined_domain`.
+
 GPB proto files are backwards compatible, and a new domain can be added without affecting existing systems.
 
 Analytics applications have to be equipped with the new domain-specific proto file as well.
diff --git a/docs/sections/services/ves-hv/resources/dynamic-configuration.json b/docs/sections/services/ves-hv/resources/dynamic-configuration.json
index 0a1cd89d..40521ab9 100644
--- a/docs/sections/services/ves-hv/resources/dynamic-configuration.json
+++ b/docs/sections/services/ves-hv/resources/dynamic-configuration.json
@@ -22,6 +22,20 @@
         "bootstrap_servers": "message-router-kafka:9092",
         "topic_name": "HV_VES_HEARTBEAT"
       }
+    },
+    "ves-3gpp-fault-supervision": {
+      "type": "kafka",
+      "kafka_info": {
+        "bootstrap_servers": "message-router-kafka:9092",
+        "topic_name": "SEC_3GPP_FAULTSUPERVISION_OUTPUT"
+      }
+    },
+    "ves-3gpp-heartbeat": {
+      "type": "kafka",
+      "kafka_info": {
+        "bootstrap_servers": "message-router-kafka:9092",
+        "topic_name": "SEC_3GPP_HEARTBEAT_OUTPUT"
+      }
     }
   }
 }
diff --git a/docs/sections/services/ves-hv/run-time-configuration.rst b/docs/sections/services/ves-hv/run-time-configuration.rst
index bac68ecf..c2352c7e 100644
--- a/docs/sections/services/ves-hv/run-time-configuration.rst
+++ b/docs/sections/services/ves-hv/run-time-configuration.rst
@@ -35,7 +35,7 @@ Routing
 
 For every JSON key-object pair defined in **"stream_publishes"**, the key is used as domain and related object is used to setup Kafka's bootstrap servers and Kafka topic **for this domain**.
 
-When receiving a VES Event from client, collector checks if domain from the event corresponds to any domain from Routing and publishes this event into related topic. If there is no match, the event is dropped. If there are two routes from the same domain to different topics, then it is undefined which route is used.
+When receiving a VES Event from client, collector checks if domain (or stndDefinedNamespace when domain is 'stndDefined') from the event corresponds to any domain from Routing and publishes this event into related topic. If there is no match, the event is dropped. If there are two routes from the same domain to different topics, then it is undefined which route is used.
 
 For more information, see :ref:`supported_domains`.