Apophis Bunker App API challenge part 2

Challenge Overview

 

Welcome to the Apophis Bunker App API challenge. Our goal here is to implement order and history endpoints for the application. Swagger, db model design and base code are provided - Node + Postgres

 

NOTE: Challenge winner will be offered an additional task to implement remaining api endpoints and work on the future improvements to the backend 

 

Project Overview

 

The intent of this project is to create an MVP web application - Bunker Desk Tool Kit - to manage the activities currently done with a combination of excel tools and manual tasks. Using the new web application, users will be able to:

• Schedule bunker deliveries and resupply movements

• Report and communicate effectively with third-party terminals, barges, and agents

• Provide optimal blend opportunities

• Update Marketers and Traders of the status of inventories and deliveries

 

Technology Stack

• NodeJS

• Postgres

• Sequelize

 

Assets

Swagger API definition, database model, and base code are provided in the forums.  

Individual requirements

 

Endpoints in scope are (swagger tags match these sections):

• Orders (primary requirement - nothing else can be implemented without this part)

• History

The main purpose of the order endpoints is to track inventory (volume) of oil in tanks and barges. You will notice the database model does not specify all the implementation details for order.additionalData - it is up to you to decide whether to implement it using polymorphic relations, additional columns or some different approach.

There are a few important fields in the order details that affect the data that needs to be added/updated in the database when creating/updating/deleting a transaction. Three important fields are transaction date, type and status. Date determines a time when the inventory changes of that transaction affect the inventory. Transaction type and status determine whether the inventory is affected by the transaction. The following are possible transaction types:

• Load Barge (LB) - loading from oil tanks to barge

• Delivery(D) - loading from barge to the target ship

• Load Delivery(LD) - loading from oil tanks to ship directly (without using a barge)

• Resupply Load(R) - loading from a refinery to a barge

• Resupply Discharge(S) - loading from barge to tank

• Pipeline (P) - loading from refinery directly to tank via pipeline (not using a barge)

• Tank Transfer(TT) - transferring oil between tanks

• Unavailable(U) - used only as a marker that a barge/tank is not available

And the following are the transaction statuses:

• Quoted

• Confirmed

• In Progress

• Delivered

• Completed

• Canceled

Define the types/statuses as enumerations in the codebase instead of using strings everywhere. Some status values are not valid for all transactions: Unavailable can only be Confirmed, In Progress, Completed, and Cancelled. All the other ones can have any status with the exception that Delivered is valid for D, LD, D, and Completed is valid for LB, R, S, P, TT, U.

Inventory is always stored in the database directly. What needs to be done once an order is created/updated is to first determine if it affects the tank/barge inventory (based on type/status) and then update all the operations_history entries with later dates to reflect the new volume - this should be done in a single transaction so we don’t have dirty reads/writes. Also, make sure to handle the case where tanks are changed (ex tank 1 and tank 2 are used initially, but then order is updated to use tanks 2 and 4. Same thing with different barges).

Orders of type U do not affect the inventory. Same thing with orders with status cancelled, but make sure to update the operations_history if an order is moved from Confirmed/In Progres status to Cancelled.

Any update to an order will increase the revision number and store the change description to the database (revisions and descriptions can be fetched with GET ���/orders���/{orderId}���/revisions endpoint.

POST ���/orders���/{orderId}���/nomination is not in scope

All database models should be defined using sequelize - use camelCase for attribute names. Follow the code structure of the starter pack codebase. On application startup, create a default app user with super admin role and default user name “superAdmin”.

NOTE: unit tests are NOT required

 

What to submit

• Submit the updated codebase

• README document with deployment and verification steps

• Postman collection to verify the endpoints

 

Final Submission Guidelines

See above