Update NBINotifications docs 88/97188/13
authorThierry Jiao <thierry.jiao@orange.com>
Thu, 12 Aug 2021 08:32:14 +0000 (10:32 +0200)
committerguillaume.lambert <guillaume.lambert@orange.com>
Thu, 26 Aug 2021 07:37:03 +0000 (09:37 +0200)
Updates the illustration "Example:service-create workflow" and the
description

Signed-off-by: Thierry Jiao <thierry.jiao@orange.com>
Change-Id: Icfb5da8d9ac489e790a4530694c73550bf837a29

docs/developer-guide.rst
docs/images/TransportPCE-nbinotifications-service-example.jpg

index 7380ac54bd61411e01cf0b6d455aaebad9c3eea9..2e3389c4dcd314057d6a0c1ba9db16db3177a3f8 100644 (file)
@@ -1452,13 +1452,17 @@ odl-transportpce-nbinotifications
 ---------------------------------
 
 This feature allows TransportPCE application to write and read notifications stored in topics of a Kafka server.
-When the feature is called to write notification to a Kafka server, it will serialize the notification
-into JSON format and then will publish it in a topic of the server.
-When the feature is called to read notifications from a Kafka server, it will retrieve it from
-the topic of the server and will deserialize it.
+It is basically composed of two kinds of elements. First are the 'publishers' that are in charge of sending a notification to
+a Kafka server. To protect and only allow specific classes to send notifications, each publisher
+is dedicated to an authorized class.
+Then are the 'subscribers' that are in charge of reading notifications from a Kafka server.
+So when the feature is called to write notification to a Kafka server, it will serialize the notification
+into JSON format and then will publish it in a topic of the server via a publisher.
+And when the feature is called to read notifications from a Kafka server, it will retrieve it from
+the topic of the server via a subscriber and will deserialize it.
 
 For now, when the REST RPC service-create is called to create a bidirectional end-to-end service,
-depending on the success or the fail of the creation, the feature will notify the progression of
+depending on the success or the fail of the creation, the feature will notify the result of
 the creation to a Kafka server. The topics that store these notifications are named after the connection type
 (service, infrastructure, roadm-line). For instance, if the RPC service-create is called to create an
 infrastructure connection, the service notifications related to this connection will be stored in
@@ -1471,20 +1475,12 @@ progress of a service creation.
    :alt: Example of service notifications using the feature nbinotifications in TransportPCE
 
 
-Depending of the success of the service creation, different notifications will be published
+Depending on the status of the service creation, two kinds of notifications can be published
 to the topic 'service' of the Kafka server.
 
+If the service was correctly implemented, the following notification will be published :
 
--  **ServiceCreate request received** : Indicates that TransportPCE received an RPC request service-create
-   and started the process of creation. The notification contains all information concerning
-   the new service to create.
 
-
-If the service was correctly implemented, these notifications will be published :
-
-
--  **PCE calculation done OK !** : Indicates that the PCE calculation requested by the service-create
-   was successful. It also contains all information concerning the new service to create.
 -  **Service implemented !** : Indicates that the service was successfully implemented.
    It also contains all information concerning the new service.
 
@@ -1492,12 +1488,13 @@ If the service was correctly implemented, these notifications will be published
 Otherwise, this notification will be published :
 
 
--  **ServiceCreate failed ...** : Indicates that the process of service-create failed.
-   It contains the failure response.
+-  **ServiceCreate failed ...** : Indicates that the process of service-create failed, and also contains
+   the failure cause.
+
 
 To retrieve these service notifications stored in the Kafka server :
 
-**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-service*
+**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-process-service*
 
 **Sample JSON Data**
 
@@ -1512,7 +1509,31 @@ To retrieve these service notifications stored in the Kafka server :
     }
 
 .. note::
-    The field 'connection-type' corresponds to the topic that store the notifications.
+    The field 'connection-type' corresponds to the topic that stores the notifications.
+
+Another implementation of the notifications allows to notify any modification of operational state made about a service.
+So when a service breaks down or is restored, a notification alarming the new status will be sent to a Kafka Server.
+The topics that store these notifications in the Kafka server are also named after the connection type
+(service, infrastructure, roadm-line) accompanied of the string 'alarm'.
+
+To retrieve these alarm notifications stored in the Kafka server :
+
+**REST API** : *POST /restconf/operations/nbi-notifications:get-notifications-alarm-service*
+
+**Sample JSON Data**
+
+.. code:: json
+
+    {
+      "input": {
+        "connection-type": "infrastructure",
+        "id-consumer": "consumer",
+        "group-id": "test"
+       }
+    }
+
+.. note::
+    This sample is used to retrieve all the alarm notifications related to infrastructure services.
 
 Help
 ----
index 39ed1aa1639536b0fe9711d77cfc6f97b42989c3..aa52bc1d07c16f91f7c26ac27ef8a67b2e8b4227 100755 (executable)
Binary files a/docs/images/TransportPCE-nbinotifications-service-example.jpg and b/docs/images/TransportPCE-nbinotifications-service-example.jpg differ