Key Decision Log (Scheduler)

Owned by Steve Conrad
Last updated: Mar 23, 2023 by PSRAMKUMAR
2 min read

All of the following key decisions were made and absorbed into the specs from feedbacks and associated discussions with Technical Advisory Committee [ April 2022]:

  1. Scheduler will have capability to send alerts directly to a Rest-API of target BB or indirectly through messaging BB or through its IMBB Pub-Sub room. The choice is an implementation time decision, but it is preferred to use direct alerting sparingly for synchronous (time-critical) alerts, other asynchronous alerts can use Messaging BB based alerts suits for endpoints on mobile client apps, while pub-sub should be chosen only when it is okay the art has no control of who should read it in pub-sub room

  2. The Scheduler does not retain any reports its generates, it only maintains raw logs and produces reports on demand. It retains logs of all transactions including the fact that it did give a report to a specific requestor

  3. It is necessary for any BB / application that is alerted by message from Scheduler be tagged with a unique token by synchronous response. An alert recipient can process the trigger and asynchronously update status back to an end point on the scheduler along with the token. Alternately, along with the token, it can also publish an end point in its synchronous response. The scheduler can later poll for status updates, by giving the unique token it received.

  4. The archival and retrieval of data generated or received in the scheduler building block is left to implementation time considerations of IT infrastructure planning.

  5. The scheduler BB can be used also as an internal sub-block of another building block with interfaces. However, the same APIs will be retained in such interfaces, even if an internal IMBB block is not used.

  6. Considering the generalized case of workshops, training Events, medical camps, marketplace exhibitions, etc., which generally host same event on multiple days and may be run at different places by different resources and address different subscribers, multiple events of same name are allowed as long as they do not overlap in date-time zones.

  7. The Scheduler UI may host a calendar view to help visualization of a worklist of specific users, however the internal storage of all schedules are maintained only in form of a worklist. The scheduler also returns JSON formatted details of a schedule when queried through its API, but it is left to the application consuming the response to format it accordingly into a calendar format if required for presentation