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

Quick Overview : SAM API subscribes to ACS (Internal Brivo system) events using a callback service that Brivo has in place.  It allows SAM to subscribe to Brivo doors much like SAM allows API clients to subscribe to device events, etc. When an event occurs, ACS sends an event message as JSON to a URL that SAM supplies when subscribing.  So, in other words, a ACS has a webhook and SAM subscribe to the webhook to receive notification about ACS events. Current SAM API "POST /event" endpoint requires authentication, because it respects the domain-centric multi-tenancy model.  It requires OAauth2 authentication, as we all know, using a token in the HTTP header. Thus, we can't currently use the ACS callback service.
 
We want to implement a public endpoint to subscribe to ACS events, here is a Flow diagram showing the scenario we have in production
Following the diagram above, here is what you need to do in this challenge :
  1. 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
  2. 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.
    • 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

The current ACSService has a hardcoded username that it includes on the HTTP header in the outbound request to Pi (formerly known as ACS).  See line 97.
Update this method to read the username value from the method's input parameters.
 

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.

ELIGIBLE EVENTS:

2014 TopCoder(R) Open

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30040803