Challenge Overview
Project Overview
BrivoLabs has a beta version of a node.js/coffeescript application that is called Social Access Management (SAM) API. It uses postgres database, runs on heroku, consists of both a web and a worker process, and uses a redis-based message queue to communicate between them.
The goal of this challenge it to add new functionalities, and bring few fixes and improvements to existing API.
Competition Task Overview
You are required to address the following requirements in this challenge.
Webhook Listener
- Define new endpoint "Post /device/:id/pi/listen" , this end point should do the following:
- Generate unique webhook code and associate it with the domanAccount of caller.
- Generate the webhook listener URL (URL format "/webhook/events/:webhookCode") and subscribe to Pi using url "POST /api/event-subscription" with following JSON :
{
"url": "{webhook url}",
"criteria": [{
"criteriaTypeId": 5,
"criteriaOperationTypeId": 1,
"criteriaValue": {device.externalId}
}],
"errorEmail": "{config. supportEmail}",
"name": "SAM listener {device.externalId} "
} - The Pi subscription url should be configurable
- Add supportEmail configuration variable to environment variables (.env)
- A domainAcount can have multiple webhook codes associated with it so you need to add new model to store webhook codes and associations
- The Pi call is expected to return an event-sub ID, it should be persisted. The response is string that contains a path to the newly created resource. For example:"/api/event-subscription/189", it will be persisted for future un-subsribe feature.
- Create a device subscription
- New endpoint to listen to handle Pi webhook events :
- Signature will be "POST /webhook/events/:webhookCode"
- Verify webhookCode is valid and associated with valid domainAccount
- Create an "event" object, the logic will be similar to "POST /events", with following notes :
- This new endpoint will only accept two types of json :
- doorbell.json - this is the response from Pi doorbell event, passed to SAM via Pi webhook callback as shown in the diagram above.
- doorpulse.json - If something (not necessarily SAM) "pulses" a door in Pi, and SAM has created an event-subscription on that door, then Pi will post to our webhook URL. This will look like doorpulse.json that I supplied previously. Note that we don't currently have any use cases for this - we don't "handle" this event, we just need to log it.
- To differentiate between the two events (as json is identical), the doorbell will have actorType.type = DEVICE.
- Current "POST /events" logic accept the doorbell.json (as seen in Postman "Create Event"), clean it up so it only handle events from Randivoo app (refer to Postman "Create Event (Old Way)" for the parameters passed from that app.
- Move the common logic between the two endpoints to ahelper class.
- This new endpoint will only accept two types of json :
- Execute SAM Subscription.
- Add support to Device events on worker.coffee (refer to this thread for more clarifications http://apps.topcoder.com/forums/?module=Thread&threadID=811763&start=0&mc=1#1848586):
- The Device events will support two subscription types (door-pulse, and glass-monitor)
- Retrieve the device of the event
- Retrieve associated subscriptions with the device
- Based on the subscription type, call corresponding service, either glass or ACS.pulseDoor. We already have other events that have this logic. You can refer to it.
ACS Service
EventInvite Service
- Add new field "description" to EventInvite model
- Fix all endpoints that manipulate event invite to store/retrieve "description" field
Misc Fixes
- Update accessReservationController#show to replicate the same logic as in #index method.
- Update "GET /me" endpoint's response to include all child entities (domain, account, and roles)
- Update worker.coffee to allow SAM to access salesforce via a token instead of user/pass when calling /services/apexrest/brivolabs-checkin, please use best practices related to the salesforce integration
Architecture Documents
Provided in forums the architecture document of the SAM API, it is useful for new developers, it is bit out of date with last two weeks of fixes, but it has good information to understand the overall application.
Testing
- Create mock ACS (Pi) service webhook and endpoints to test the subscriptions. Provide instructions for how to setup the mockup and run it.
- Update postman.json it will be used for testing
- Update mashery-io-docs document
Final Submission Guidelines
Submission Deliverables
Below is an overview of the deliverables:
- Patch of file changes
- Readme file should be updated
- Include a text file with any notes about applying the patch and any other notes for reviewers to verify and test the submission.
Final Submission
For each member, the final submission should be uploaded to the Online Review Tool.
Environment Setup
Source code setup
The source code attached in forums, it has a .git folder, and a detailed readme file that you can follow to setup and run the SAM API.
Development Environment
SAM API can be deployed and run on any OS, if you have problem setting up the environment, please post in forums and Copilot will help you.