Design to get list of ongoing and upcoming open batches.

Problem statement :

Consumer want to show count of upcoming and ongoing open batches for a course. Since course is stored under learning platform and created batch from course are stored under sunbird-LMS.

There are two different system and they don't know each other apart from validation.

Proposed Solution 1:

As of now Sunbird is running a cron job on daily basis, to update some meta data inside course. This scheduler job will do following actions.

* Select all those batch whose startDate <= today date and countIncrementStatus is false.

* Select all those batch whose endDate >= yesterday date countDecrementStatus is false.

* Now based on above two query and batch type (open or invite-only) , it will update course meta data as follow.

* in case of course going to start now. it will add key as ""c_" + {"sunbird_installation"}+ "_open_batch_count" or c_{"sunbird_installation"}_private_batch_count. with value as int.

* in case of batch end , it will decrements count against same key.

Pros

Cons

As get course has meta data to indicate open batch count per installation, so no need to make any extra api call

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

Need to add meta data for future upcoming batch as well.
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.)
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.
Apart from that during batch creation time itself we can add this meta data.

Proposed Solution 2:

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

new api to get course batch count

URI: v1/course/batch/count?offset=0&limit=20
Methods: GET
--- Internal work flow :
  When user call this api , it will internally make course batch search by passing different filters.

 It will internally make two ES call. first call to collect all unique courseIds  and then based on that it will make another Es call to collect details.


{
 "request": {
     "filters":{
              "courseId":["list of courseId found in first search"]
              "status":["0","1"],     
              "enrollmentType":"open"
            },
            "offset":0,
            "limit":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": {
                        "courseName": "SUBU_01",
                        "leafNodesCount": "3",
                        "description": "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_212638416227246080157",
                    "startDate": "2018-11-21",
                    "status": 1
                   
                },
                { 
                    ........
                    "courseId": "do_2126299478299033601672" 
                   
               }
            ]
        }
    }
}

Pros	Cons
Easy to manage , later any other changes can be easily incorporated. Only one api call that will handle complete business logic Using request body 2 or 3 will provide flexibility to move complete business logic on server side.	new api need to be introduce 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:

Sunbird will define new page section to provide open course list under page api.

TO achieve this we need to do following modification under page assemble api and get page section .

* Now section table need to have calling source as well. which will include (source, indexName, typeName)

* Assemble page business logic will be modified to make call based on source

* local source can have multiple search query with query order.

Pros	Cons
for consumer only one page assemble api and that will provide complete data	need to modify existing api , More testing required. Due to that requirement table structure need to be modified some data migration alos required with old section.

Proposed Solution 3:

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

Batch search query

{"request":{"filters":{ "courseId" : ["do_112634552998936576175","do_112634535631675392173","do_112633845274157056122"],"status":["0","1"],"enrollmentType":"open"},
"sort_by":{"createdDate":"desc"}
}
}

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

Open Questions :

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.