[Quick 48 hrs] Gng - Overburden calculator service API

Challenge Objectives

 

• Java Rest API development using Spring Boot

Project Background

• Our client has developed a specific method of calculating overburden gradient

• All the calculations are currently in an Excel workbook - our goal is to create an API to store and process the data, i.e. move the calculations from Excel into the codebase.

• In this challenge, we’ll implement the service to support the frontend UI requirements

 

Technology Stack

 

• Java 11

• SpringBoot

• MongoDB

• JUnit

 

Code access

 

The base code is available in the forums and contains only the bare project structure. Project architecture and deployment instructions are available in the project wiki page (see the link in the forums)

 

Individual requirements

 

NOTE: We are essentially porting existing features from a different api to this app. See the model service link in the forums.

1. Create Job groups and Job runs
   JobGroup is essentially a grouping for jobs for the same Well and it should have the following attributes

Id

Name

UWI (string)

Description

createdAt, createdBy, updatedAt, updatedBy

 

UWI is a unique well identifier. Either a UWI or Name has to be not null. UWI will be used to run calculations against known wells, and name field will be populated if the UWI is unknown (ex testing calculations on a potential new well).

 

JobRun should have the following attributes

Id

groupId

isPublic

Name

Description

Status (use the same status options as xrd )

Calculation results (this is where the outputs of the calculation service are saved)

Calculation inputs (what is used to call the calculation service)

createdAt, createdBy, updatedAt, updatedBy

1. Create the following API endpoints

   1. POST services/job/group/create - create group (UWI should be unique. If it’s null then name should be not null and unique)

   2. PUT services/job/group/save/id - update group

   3. GET services/job/group/all - get all groups

   4. GET services/job/run/id - get job run

   5. GET services/job/run/all/groupId - get all jobs in the group - return all non archived jobs

   6. PUT services/job/run/save/id - update job run

   7. PUT services/job/run/archive/id - update status to archived

   8. POST services/job/run/create - create a new run (save the inputs to db, call the calculation service, save outputs to db and return the job run details)

   9. DELETE services/job/run/id - delete an existing run

NOTE: the current calculation backend is stateful and we're updating it in a parallel challenge. You should use a mock service the new endpoints in this challenge (POST /ob/calculation with same inputs/outputs as the current POST /ob/data endpoint but without id, createdAt, updatedAt fields).
For reference, this is the frontend that will use this service -http://3.83.139.158:8080/#/overburden/calculator (import file is parsed by the frontend, name and description fields are added. no data zone won't have the input table).

 

General requirements

 

• Unit tests are required for all services (not the controllers) and tests should validate that the operation works correctly and the result is correct.

• All database collection names should be prefixed with “API_NAME_SERVICE”

• All configuration parameters should be extracted to the configuration file. Sensitive configuration parameters should be set from environment variables (DB URL, credentials, etc). All environment variables have to be prefixed with “API_NAME_SERVICE”

• Please make sure your code is well-documented. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

What To Submit

 

• All source code (git patch)

• Deployment guide

• Postman collection containing sample calls for all endpoints (success/failure)

• Verification guide - how to set up the environment, start the API, and verification screenshots

• The unit tests coverage report

 

Scoring Methodology

 

Contest Specification Requirements(60% weightage)

 

·       Have all major specification requirements been met?

Score: 0-9

Major requirements are:

·       all endpoints are implemented correctly and return the correct data and codes, etc,

·       all DB models are defined and contain correct attributes and data types

·       Unit tests - minimum coverage 80%

                       Have all major specification requirements been met?

Score: 0-3

Minor requirements are:

 

·       Postman collection

Best Practices & Comments(30% weightage)

 

·       Does the submission follow standard best practices?

Score: 0-3

This section includes the code style, linter, patterns usage, code comments

Please make sure your code is well-documented. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

 

Deployment and verification guide (10% weightage)

 

·       Does the deployment guide contain everything needed to successfully configure and deploy the API?

Score: 0-3

Final Submission Guidelines

see above