Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ProsCons
As get course has meta data to indicate open batch count per installation, so no need to make any extra api call
  1. This meta data is updated only when course is going to start , it means for upcoming course we can't get it.

2.  Data is updated by scheduler job and scheduler job is not 100% guaranteed 

3. Some time due to content attribute changes , it's not able to update the content, so in that case meta data won't be updated.

4. TO add meta data for upcoming batch as well , will have more complexity to manage it when upcoming batch changes as ongoing.

  

         Note : So to support solution 1: we need to take following actions:

...

Actions
  1. Need to add meta data for future upcoming batch as well.
  2. Need to fix all those content which are failing during update (On Diksha found only 1. do_31261135182897971215 and on ntp staging and sunbird staging can't find any content,but on sunbird dev found lot more content.)
  3. Need to have some fallback  for scheduler job management . so might be instead of once in a day can be run twice in a day.
  4. Apart from that during batch creation time itself we can add this meta data.





Proposed Solution 2:

  User can make another api as batch search api  by passing all courseIds and some extra filters.

  

...

languagejs
titleBatch search query

...

:

...

          

...

  1. Existing api can be re-used.

...

  1. Caller (portal/app) need to make one extra api call and then then need to merge both response
  2. Caller need to make one more api call to get my enroll course
  3. It can have performance issues .

Proposed Solution 3:

Sunbird will expose a new api to get open batch count for list of courseIds. for ongoing and upcoming batches.  New api details will be as follows:

...

Code Block
languagejs
titlenew api to get course batch count
URI: v1/course/batch/count?offset=0&limit=20
Methods: POSTGET
Request--- bodyInternal 1:work {flow  "request":
{  When user call this "filters":{api , it will internally make course batch search by passing different filters.

"courseId":["courseId-1","courseId-2"],
              "status":["0","1"],     
              "enrollmentType":"open"
            }
       }
}


Request body 2: It will internally make two ES call. first call to collect all courseIds with participant list . Based on that response it will keep count of same courseId and remove those courseId for which user is already enrolled.
After that based on unique courseList it will fetch complete data and merge count in new response.


{
 "request": {
     "filters":{
              "courseIdstatus":["courseId-10","courseId-21"],     
        }      "enrollmentType":"open"
        } }   Request},
body 3: {  "request": {       "offset":0,
            "courseIdlimit":["courseId-1","courseId-2"]20
       }
}




----
Response:
{
    "id": "api.course.batch.count",
    "ver": "v1",
    "ts": "2018-11-20 17:53:00:716+0000",
    "params": {
        "resmsgid": null,
        "msgid": "8e27cbf5-e299-43b0-bca7-8347f7e5abcf",
        "err": null,
        "status": "success",
        "errmsg": null
    },
    "responseCode": "OK",
    "result": {
        "response": {
            "count": 8,
            "content": [
                   {
                    "identifier": "",
                    "createdFor": [
                        "",
                        ""
                    ],
                    "courseAdditionalInfo": {
                        "courseIdcourseName": "doSUBU_212629947829903360167201",
                        "openBatchCountleafNodesCount":2, "3",
                        "inviteOnlyBatchCountdescription":0 "Why?",
                        "courseLogoUrl": "https://sunbirdstaging.blob.core.windows.net/sunbird-content-staging/content/{}/artifact/images-1_1532061239427.thumb.jpg",
                        "tocUrl": "https://sunbirdstaging.blob.core.windows.net/sunbird-content-staging/content/{}/artifact/{}toc.json",
                        "status": "Live"
                    },
                    "endDate": "2018-12-31",
                    "description": "nieowhoifheoiw",
                    "participant": {
                        "userId": true
                    },
                    "countIncrementStatus": false,
                    "createdDate": "2018-11-21 04:47:18:306+0000",
                    "createdBy": "",
                    "courseCreator": "",
                    "hashTagId": "0126384233410641921",
                    "mentors": [],
                    "countDecrementStatus": false,
                    "name": "My batch",
                    "id": "0126384233410641921",
                    "enrollmentType": "open",
                    "courseId": "do_2126299478299033601672"212638416227246080157",
                    "startDate": "2018-11-21",
                    "status": 1,
                    "openBatchCount":2
                },
                { 
        "inviteOnlyBatchCount":0            ........
                    "courseId": "do_2126299478299033601672",
                    "openBatchCount":2
                   
               }
            ]
        }
    }
}


ProsCons
  1. Easy to manage , later any other changes can be easily incorporated.
  2. Only one api call that will handle complete business logic  
  3. Using request body 2 or 3 will provide flexibility to move complete business logic on server side.
  1.  new api need to be introduce
  2. Some issues with limit and offset. there might be the case one course is used under "N" number of batches , then in another set as well it can come.




Proposed Solution 3:

  User can make another api as batch search api  by passing all courseIds and some extra filters.

  

Code Block
languagejs
titleBatch search query
{"request":{"filters":{ "courseId" : ["do_112634552998936576175","do_112634535631675392173","do_112633845274157056122"],"status":["0","1"],"enrollmentType":"open"},
"sort_by":{"createdDate":"desc"}
}
}



ProsCons
  1. Existing api can be re-used.
  1. Caller (portal/app) need to make one extra api call and then then need to merge both response
  2. Caller need to make one more api call to get my enroll course
  3. It can have performance issues .


Open Questions :

  1.  If one course have 3  open batches and caller already enrolled for one batch then do we need to sent open batch count as 3 or 2 or for him there is no open batch to do enroll.

...