Register
Submit a solution
The challenge is finished.

Challenge Overview

Welcome to "ASoD Economic Calculator App - Backend API Swagger Architecture Challenge". Application Security on Demand (ASoD) is a service that we offer to our customer and currently, we use a manual excel document as an “Economic calculator” to calculate the economic benefit to our customer.

In this challenge, we need your help to create a simple question-based calculator to replace the manual excel approach into a modern application to show the economic benefits for our client. The application needs to be simple, easy to use, fast, and offer a great focus to the user, and at the same time, it needs to look modern and professional.

Read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. Let us know if you have any questions in the challenge forum!
 

Challenge Objectives

  • Design a robust and performance oriented API(s) for the given set(s) of functionalities.

  • Build Swagger spec based on the details provided below + ERD Diagram.

  • Create documents to support your API spec & mapping to functionalities.

 

Project Background

In this series of challenges, we would like to build out models and functionality for backend services needed by the Economic Calculator App.

As the first step, we want the Topcoder community to help us design, build and document a Swagger API specification for the backend.

 

Technology Stack

  • REST

  • Swagger

  • NodeJS

  • Heroku

  • NoSQL DB layer

  • ERD

 

Challenge Forum

If you have any doubts or questions regarding challenge requirements, please ask in our challenge forum:
https://apps.topcoder.com/forums/?module=Category&categoryID=52119

 

General Requirements (Major)

  • Create ERD Diagram of the database models/tables

  • Design a robust and performance oriented API(s) for the given set(s) of functionalities.

  • Build Swagger spec in OpenAPI 3.0 format based on the details provided below.

  • Make sure to include appropriate models as part of your Swagger. Also, make sure that your Swagger handles error cases for each endpoint as applicable.

  • For responses, you should cover all the cases, not just 200 status code

  • Create sample body requests for each API paths

  • Create documents to support your API spec & mapping to functionalities.


Detailed Requirements (Major)

We do not have any UI/design for this ready so asking questions in the forums is highly encouraged! You should refer to the currently running UI design challenge here: https://www.topcoder.com/challenges/30072970/?type=design

The challenge describes all the screens of the application very detailed. The API mapping to functionalities file should cover all screens listed by the design challenge and also all functionalities needed that are not listed there.

 

The Economic Calculator App API should handle but it is not limited to:

  • User roles support - roles should be associated with users. Based on them the UI will serve different content and functionality. Roles should be “CLIENT”, “USER”, “ADMIN”. Need roles identified for each client, a standard user will have multiple clients. Need ability for a standard user to add multiple clients associated with his account. A client user would only have the ability to answer questions, save/email model and pull up an existing model. Each client user will be associated with either a Standard User or Admin.

  • Role-based privileges table
    https://drive.google.com/file/d/15ytrTFHsuGqZ-XwmFUGDPpz-qO7xe3LU/view?usp=sharing
     

  • User management - login, forgot user. No need for registration flow. It will happen through the backend. Also, all required to support the user roles functionality means admins can create, update and link clients to users and etc.

  • Lookup APIs - there are multiple screens that need to have tips functionality included for each item. Those should be covered by lookup APIs.

  • Master Data - the calculator is using “master data” and default values to perform its calculations. We need an “ADMIN” to be able to perform the creation, update, and storage of them. Master data consists of:

    • Set of questions asked to the user with help hints/texts associated with them. The set should be able to vary and be configurable by admin.

    • The master data

    • The default data

  • Reports  - A report is called the result of the calculation based on the “master data” used to create it. The APIs need to be handle CRUD for reports. Should be able to email report to a list of email addresses. Reports do need audit fields.

     

 

Potential data model

This suggested model is pseudo and open to your suggestions/modifications as needed.

Users:

  • ID

  • Name

  • Email (uniq)

  • Role - one of [“CLIENT”, “USER”, “ADMIN”]

  • Clients - [“UserID”] - This is an array of associated clients to the user/admin. Empty for the client role.

  • Agent - {UserID} - reference to user record in case of client role. Represents the employee responsible for the client.

  • Company

  • Phone

  • Password - hashed password. Can be null for clients as those do not login physically to the system.

  • Salt

  • Audit fields

 

Master Data:
We have identified 13(could be more) groups of master data each with own keys/values. See “Requirement_Flow_Clarifications.pptx” for more info. You need to suggest best way to organize this information as DB model. Note that:

  • Each set of master data should have its own ID. This way we will be able to refer to it. For instance, from report record.

  • Each record should have Name/Alias text field

  • Audit fields

 

Reports:

  • ID

  • ClientID - ref to UserID

  • CreatorID- ref to UserID

  • State - one of [“completed”, “draft”]

  • MasterDataID - reference to the master data record used for the calculation

  • UserInputs - should hold the answers the client gave to the questions

  • Resutls - the calculated fields from the excel file

  • EmailedTo - [“emails”] - set of emails that got this report emailed to them

  • Audit fields

 

Please make sure to explore and inspect the excel document (ASoD Economic Impact Model V2.1 Working Prototype - 100218.xlsm) and the flow document (Requirement_Flow_Clarifications.pptx) to understand more about how the Economic Calculator works. Those are available in the forum.


- There are several tabs available in the excel document, please see below for more information about each tabs purpose:
-- Sheet 1 (out of scope)
-- Input Form (this contains the data that needs to be asked to the customer. Based on that, the value/output would be given)
-- Data (possible values for the all the questions and the data page need input screen from the admin)
-- Defaults (default value for the questions)
-- Action Items (out of scope)
-- Planning (out of scope)



Final Submission Guidelines

Please, submit to TopCoder:

  • ERD Diagram
  • ���Swagger spec
  • Documents to support your API spec & mapping to functionalities.


Scorecard & Review Criteria
We’ll follow a subjective scorecard (1-10) for this challenge. The submissions will be evaluated by the copilot & PM on the basis of:

  • Completeness of Swagger file + ERD Diagram

  • Adherence to best practices for designing REST API

  • Quality of documentation and mapping file
As we are performing a subjective review there won't be Appeals and Appeals Response phases.

ELIGIBLE EVENTS:

Topcoder Open 2019

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30074604