Add stndDefined domain docs
Change-Id: If61d0b649907c18e2c82ab5a6fa8617edee11e7d
Signed-off-by: Michal Banka <michal.banka@nokia.com>
Issue-ID: DCAEGEN2-2702
diff --git a/docs/sections/services/ves-hv/design.rst b/docs/sections/services/ves-hv/design.rst
index 579b4ac..899b0c0 100644
--- a/docs/sections/services/ves-hv/design.rst
+++ b/docs/sections/services/ves-hv/design.rst
@@ -15,8 +15,8 @@
- 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 @@
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 0a1cd89..40521ab 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 bac68ec..c2352c7 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 @@
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`.