Challenge Overview
We deal a lot with Hercules services across a variety of projects, including websites, C++ embedded systems, and mobile apps for iOS and Android. We have an existing set of base service calls implemented in Node. This challenge will add a new set of service integrations for a client service called CSP. This CSP service aggregates calls from Einstein and other services into a centralized service for customer support representatives.
CSP
A sample Ruby script will be provided in the forum that covers the required calls to be implemented in the CSP service. The CSP service should be expanded to include the new calls and properly integrated with the other services in the base libraries. Don't duplicate code - reuse the existing base classes that already exist!
New calls
New calls include:
* Search by email
* Search by phone number
* Search by name
* Get past bills
* Get current bill
* Get appointsments
* Get single bill by bill ID (returns binary PDF data)
* Get payments
* Compare two bills
* Get DOCSIS devices for account
* Get all devices for account
* Get account by account ID
* Get timeline root
* Get account timeline
* Get account timeline by event type
* Get a single timeline event
* Get CIMA token
* Get WebSec token
Tokens
Instead of a statically defined key and secret, like we have for other services, CSP uses OAuth2 and per-user tokens to perform authorization. This means that the caller will need to get both a token for WebSec and a token for CIMA before making calls.
Note that the test script has a way to get the WebSec token directly, but we will also be generating the WebSec token through a web-based OAuth2 flow, so it's important that the API be flexible enough for the user to set the WebSec token. Don't assume the caller will always give a username and password to generate the WebSec token.
The code will be responsible for refreshing the WebSec token, which expires after an hour or so. If a call is made with an expired token, the API should automatically refresh the token. If token refresh fails, the call should return a 400 / unauthorized response.
Getting payments
Note that the Get Payments call accepts an account GUID. This GUID should come from the account response for retrieving an account by it's account ID. The GUID will be the "primary" user GUID in the response. The caller should be expected to pass in the GUID - don't do this automatically in the API, but it's alright to do it in the unit tests.
Code
The existing code will be linked to from the forum, including the README on how to build and test the base libraries. A Ruby script showing the necessary calls will also be provided.
Unit tests
You MUST provide unit tests to fully cover the new service calls. You should test positive *and* negative values (incorrect or missing parameters, etc...)
Submission
Your submission to OR should be a Git patch file that can be applied to see the fixes. Here is documentation on how to generate a Git patch file:
https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/
For this challenge we will target commit hash e6732416d931ed662e7c3b5bec5d80ec8964d46f.