Challenge Overview

• Implement the REST API for the ORDIS application

 

Project background

Our client Novus is a leading Telco provider that offers products (devices and accessories) online as well. To be able to maintain their online catalog they put together a system over the years based on many requirements, so they can make sure all the information that is being present in the catalog are available, correct and of good quality.

 

Currently, the system is based on Excel templates and a lot of manual process. Most data comes from existing Sharepoint databases (MAP DB) and a couple of other pieces of information have to be filled in by different employees. To be able to assign tasks relating to the tables and to keep an audit trail they utilize JIRA at the moment. 

 

JIRA is used by our external partners and will continue for the foreseeable future for cross-team tasks. However, this tool should help manage those tasks.

 

At the end of the process, the information has to be approved by a senior employee, so the content can go online. The data processed by the proposed system, the Novus ORDIS (Organizational Resource Document Intake System) will be saved to another working database, that feeds the online catalog. The data is not being saved back to the original source, the MAP database.

 

The purpose of this project is to create an end to end web-based system, in which all these tasks can be handled.

 

 

Technology Stack

• Node12 and NestJS for REST API

• Type Script

• Postgres 12

• Okta SSO

• NX

 

App Overview

User Roles

All logged in users have the same permission in this application for now. We will improve this in the next phase. 

 

Requirements

 

Here are the UI screens: https://marvelapp.com/5gc8906

 

General Info

• There are two types of products: device and accessory, and both can be grouped in the product family. 

• There is only one user role in this phase. 

• User is logged-in through Okta login page

• Device can have following statuses

  • main-sequence: 

    1. Processing

    2. Handoff

    3. Testing

    4. Approval

    5. Launch Request

    6. Launched

  • conditional: [ Hold, Update, Canceled, Retired ]

• Accessory can have following statuses

  • main sequence: 

    1. Processing, 

    2. Handoff, 

    3. Launch Request, 

    4. Launched

  • conditional: [ Hold, Update, Canceled, Retired ]

 

Challenge 1:

 

In this challenge, you are responsible for implementing the following items:

• data import service

  • It exposes an API to load the products from Excel file and return as JSON data

  • the api is called by the ordis app to import products
     

• ordis api to serve all the REST apis

  • the APIs in the following groups are in scope: product. Note that some of them are already implemented in the provided base submission. 
    ���

You should also create a docker-compose file to run all apps and database in their own docker containers. 

Extra Dev Notes:

• Please create a simple login endpoint to generate JWT token, we will replace it with Okta later. 
• For the product and product family, most fields are stored in the data JSONB column - which is basically a key-value mapping (no extra nesting). But when returning to the front-end as JSON, please expand it into the product / product-family entity - no need to put them into "data" property. 
• UserNotification and ActivityLog should be generated properly during the api implementation. 
  • when you make field changes, the field change should be persisted into the ActivityLog

And here are the details about how to parse the excel file:
Product Family Data
- Family Level sheet (identified by family name)

Product Data
- SKU Level sheet (identified by wpc-id)
- Channels sheet
- Image Path sheet
- Base Pricing sheet
- Add'l WPC Reqs sheet
- Add'l SAP Reqs sheet


Device - Accessory Association
- Associations sheet

The flat excel file has all the needed fields.

sheets: these are just views, you don't need to parse them.
- SP ORD SKU View
- SP ORD Pivot View

You can find more details in the architecture documents shared in the forum. 

 

Final Submission Guidelines

Submission Deliverable

• Source code
• Test script to setup initial test data
• Detailed Deployment Guide and Verfication Guide
• Postman file with successful and failed test cases