Challenge Overview
Challenge Overview
Challenge Objectives
-
Java Rest API development using Spring Boot
Project Background
-
Our client has developed a specific method of of analyzing geological data from soil samples which involves estimating swirr, porosity, and lambda using saturation and permeability data.
-
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.
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 (list of strings) - this is different to the other services
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
Calculation inputs for this service will be an array of objects, each with the following attributes:
-
UWI (string)
-
Sample name
-
Depth (float)
-
Porosity (percentage, 0-100)
-
Kair
-
A1, a2 - floats
-
Exp1, exp2 - floats
-
Hfu - integer, optional
-
waterSaturationInfo - array of objects
-
Capillary pressure (float)
-
Saturation (float)
-
Water saturation info is not sent to the calculation service. All other properties are sent to the service - the backend service does not exist yet so you will need to mock it in this challenge. It will have a single endpoint POST /calculation that will accept a json body with {“name”, samples:[depth, porosity, Kair, a1, a2, exp1, exp2, hfu]} and will return the results as json in the following format {name, inputs:{samples}, outputs: { samples:[{same attributes as input, por, klink, rqi, phiez, fzi, rank, z}], hfus:[{name, minPorosity, maxPorosity, averagePorosity, porosity(float array), K(float array), samples (list of sample objects that belong to this hfu), charts:[{name, image:base64EncodedPng}]}
-
Create the following API endpoints
-
POST services/job/group/create - create group (UWI list should be unique. If it’s null then name should be not null and unique)
-
PUT services/job/group/save/id - update group
-
GET services/job/group/all - get all groups
-
GET services/job/run/id - get job run
-
GET services/job/run/all/groupId - get all jobs in the group - return all non archived jobs
-
PUT services/job/run/save/id - update job run
-
PUT services/job/run/archive/id - update status to archived
-
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)
-
DELETE services/job/run/id - delete an existing run
-
Make sure to log all the errors in calling the calculation service - don't log just the generic message "error calling calculation service" but log the api response too (we need to know if the error is a network error (can’t reach the target service) or the api returned an error (400,500) and the cause.
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