[Quick 48hrs] GnG - EPC Service API Updates

******* NOTE: This challenge has 24 hrs Reviews / 12 hrs Appeals Phase *******

Challenge Objectives

 

• Java Rest API development using Spring Boot

Project Background

• Our client has developed a specific method of calculating stress and pressure values

• 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 update 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. 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

   1. Id

   2. Name

   3. UWI (string)

   4. Description

   5. 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

1. Id

2. groupId

3. isPublic

4. Name

5. Description

6. Status (use the same status options as xrd )

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

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

9. createdAt, createdBy, updatedAt, updatedBy

2. Update calls to the calculation service
   Right now the code expects the calculation service to return an ID and it’s saved in our Java services as externalID. We need to remove that behavior as the calculation backends are now stateless. Updating job run inputs should again call the calculation service (as a new calculation - the calculation service doesn’t have the “update calculation” endpoint)

3. 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

 

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.

 

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

• 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