Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 38 Next »

Introduction

This document describes the design of discussion middleware session.

https://project-sunbird.atlassian.net/browse/SB-22319

Problem Statement

Storing the required information of nodebb and make it available whenever we required.

Key designs solutions

  • Identifying required info for nodebb.

  • Store that info in DMW cache.


Limitations with existing approach

Entire DMW depends on portal session. If any issue occur in portal session then discussion forum also

should affect. By considering this we are implementing cache in DMW itself.

Solution

Initially we stored some of discussion middleware data in portal session. due to this approach our DMW

depends on portal session. So to make DMW independent we are implementing cache with in DMW.

Architecture Diagram

Current architecture diagram Link

Proposed Changes:

Redis:

To pass data from DMW to new notification service, We planned to use Kafka but in the same way we can use Redis Stream/Redis PubSub also.

Redis Pub/Sub:

In DMW we can publish an event and that event can be listened by Notification service and vice versa.

Redis Stream:

We need to create a redis stream in DMW and add the data into the stream. On other side

notification service will receive the data from the stream.

What data we are storing in DMW cache?

We are storing two main objects in DMW cache.

Keys

Data

User

{"userId": { "uid": "2" }, "userSlug":"content_creator_tn3941","userName": "content_creator_tn3941" }

Context

[{ "sbIdentifier": "c4320769-13cd-43a9-bc73",

"sbType": "group", "cid": "150". }]

We are storing the DMW cache data in Redis Database.

Discussion Middleware complete session object

Schema

Key

Type

Key

Schema

context

Object

cid

{
"sbIdentifier": String
"sbType": String
"cid": String
}

user

Object

sbUserIdentifier

{
"uid": String
"userSlug": String
"userName":String

“sbUserIdentifier“: String
}

  1. How to access user information from DMW cache.

We can access the user data from cache using sbUserIdentifier as a key. and it will retune the

below data.

{
"uid": "2" ,
"userSlug":"content_creator_tn3941",
"userName": "content_creator_tn3941",
"sbUserIdentifier": "dfer23-dsds332-33drt-td899w"
}

2. How to access context information from DMW cache.

We can access the context data from cache using cid as a key. and it will retune the

below data.

{ 
"sbIdentifier": "c4320769-13cd-43a9-bc73",
"sbType": "group",
"cid": "150"
}

Different ways of trigger notification service:

Type1:

If the parent service have actual notification data along with action data, then we have to send the below formate. And flink job will take this object and process it.

{
  service: "discussion-forum",
  headers: {  //req tracebility
    sid: // from headers
    traceID: // from headers
  },
  *notifcationData: {
    "*ids": [], // sunbird identifiers
    "*createdBy": { *id, name, type }
    "action": {
      "category": "discussion-forum" // Service name
      type: "", // action type
      template: {
         type: "JSON",
         params: {
           param1: "",
           param2:"",
           param3: "",
        }
      }
    }
  "*additionalInfo": {  // specific to the service & common for all API's of the service. Flink job will parse the object & construct specific to Notfi API
    "context": { 
        cid: "",
        sbItendifier: "",
        sbType: ""
      },
    // based on resp derive the below fields
    "category": {
        "cid": "",
        "title": "",
        "pid": ""
    }  // Flink job has to call API;s to get names of these below (cid, tid, pid etc)
    "topic": {
      "tid": "",
      "title": ""
      }
    "post": {
      "pid": "",
      "title": ""
    }
  }
}

Type2:

If the parent service don’t have the action data the we have to send service and url then particular flink job will add the required action data. The parent service has to send this data.

{
  service:  "groups" // service name (use this as "action.category")
  url: "end-point" (flink jobs will use this to add "action.type"
  headers: {  //req tracebility
    sid: // from headers
    traceID: // from headers
  },
  *notifcationData: {
    "*ids": [],
    "*createdBy": { *id, name, type }
    "action": {
      // "category": flink job will device based on 'service'
      // type: flink job will decide based on 'url'
      // template: flink job will decide based on 'type/url'
    }
  "*additionalInfo": {  // specific to the service & common for all API's of the service. Flink job will parse the object & construct specific to Notfi API
    "context": { 
        cid: "",
        sbItendifier: "",
        sbType: ""
      }
   }
}

Examples :

Group Notification Used Case:

  service:  "groups" // service name (use this as "action.category")
  url: "end-point" (flink jobs will use this to add "action.type"
  headers: {  //req tracebility
    sid: // from headers
    traceID: // from headers
  },
  *notifcationData: {
    "*ids": [],
    "*createdBy": { *id, name, type }
    "action": {
      // "category": flink job will get it based on service context in additional Info
      // type: //service will pass
      // template: flink job will generate based on additionalInfo
    }
  "*additionalInfo": {  // specific to the service & common for all API's of the service. Flink job will parse the object & construct specific to Notfi API
    "group": { 
        "id": "<groupId>",
        "name":"<groupName>"
     },
     role:"admin/member",
     "activity":{
        "activityId":"<ActivityId>",
        "activityName":"<ActivityName>"
     } 
   }
}

Clarification needed

  • When DMW cache expired but user tried to do some actions then need to show one message. Also need message string : Manimegalai Mohan .

  • No labels