Challenge Overview
Challenge Objectives
App environment:
REST API application based on Java 8, Maven, and MS SQL.
Basic Requirements for this challenge:
- Convert existing REST API from NodeJS to Java 8, Maven based.
- Implement best practice security the access data from REST API service. You may use Java Web Token or come up with your suggestions
- Need exact same REST API service endpoints.
- Create separated scripts outside of the app to run the database init, or add sample datas scripts, should not part of application command.
- Implement the unit testing for all endpoints on this Java 8, Maven based REST API.
Project Background
The goal of this project is to create a web based tool for operators to share frac schedules and locations with other operators. Currently we have a consortium of 15 operators that share their schedules via email roughly once a week to monthly. The email list changes monthly with people being added or taken off, which makes it tough to manage if you are getting all the schedules you need. Not only does the email list change, but so does each individual company’s frac schedule. With so many moving parts, manually sharing emails and aggregating schedules is unsustainable. These emails contain API # (unique public well identifier), well name, Frac start, Frac end, Bottom Hole Lat/Long, Surf Hole Lat/Long, and sometimes the underground formation name.
In the current state, we go into our internal mapping tool or the State website and manually measure out the distances between our well locations and the offset operators locations to see if we need to prepare our wells. From this frac schedule, it us up to the individual companies to check in to see if offset fracs are on time or delayed and if the operator will impact any of their assets. This methodology is cumbersome and time consuming. A tool should be easily accessible, be able to quickly upload operator information and provide a visual and user adjustable display of areas and times where frac operations may cause operational hazards due to “frac hits” http://www.eagleford.training/2015/08/what-are-frac-hits/
For this challenge, we’re in part where we need convert existing REST API that use NodeJS into Java 8, Maven technologies. Expected submission results need produce exact endpoints like current REST API that will be consumed for AngularJS app on the frontend.
Technology Stack
Programming language(s) to be used:
- Java 8
- Maven
Deployment environment requirements
- localhost
- Heroku
- AWS
Database
- MS SQL Server
Code access
AngularApp
https://gitlab.com/quartz-energy/ops-frac-schedule/web-application
Demo
https://ops-frac-schedule.herokuapp.com/
Application support 3 roles, make sure your updates affect all roles:
operator/password
admin/password
user/password
REST API Source Code
https://gitlab.com/quartz-energy/ops-frac-schedule/api-services-alt
Postman Collection for API endpoints Testing
https://gitlab.com/quartz-energy/ops-frac-schedule/api-services-alt/tree/dev/docs
REST API Service requirements:
- Please refer to existing REST API code. We need exact same endpoints that will be consume to our AngularJS app
- But for this new version, we need you to follow examples of services that are well implemented. For instance: https://docs.gitlab.com/ee/api/
- Important things need addressed is we need implement best practice security to access data from REST API services. You may use Java Web Token or come up with your suggestions
- Create separated scripts outside of the app to run the database init, or add sample datas used for the application.
- Need support localhost and Heroku deployment.
- Notice there are 3 separated roles used on the app.
- We’re encouraged you to adjust best practice and efficient schemas for every endpoints. Let’s discuss any solution, we’re open any advices.
Individual Endpoints Requirements
- This is the expected endpoints based on existing REST API. Read carefully for each endpoints for detailed requirements
1). Login
- Create the following endpoints to create, update, delete, retrieve, and retrieve all user collections.
- Create sample endpoints for 3 different user roles
- We need every userID tied with Company ID
- If the authorization are valid, then generate access token that will be consume to our frontend, with configurable expiration date, then return generated authorization token in response.
2). Lookup
- There are some lookup that need accessible for the dropdown or auto suggest:
-- Lookup all wells
-- Lookup US states (Create all US states data)
-- Lookup the Region
-- Lookup all company
-- Lookup all contact roles
- Current user logged in informations
3). Schedule
- Create the following endpoints to create, update, delete, retrieve, retrieve all data.
- Endpoints require valid authorization header
- Display Schedule summary like on top left of screenshot
- Need use clusterer marker on map, you can see some numbers on dot represents total operator.
- When zoom in the map need display scattered dots on map.
4). Company
- Create the following endpoints to create, update, delete, retrieve, and retrieve all company collections.
- All user roles need able to retrieve all company informations
- Admin role need add, edit, delete company
- Admin cannot delete company if there’s still contact data within the company
- Operator role need able to edit company that tied with his id only.
5). Contact
- Create the following endpoints to create, update, delete, retrieve, and retrieve all contacts collections.
- All user roles need able to retrieve all contact informations
- Admin role need add, edit, delete contacts
- Operator role need able to add, edit and delete that tied with his id only.
6). Schedule
- Create the following endpoints to create, update, delete, retrieve, and retrieve all schedule collections.
- on the frontend this will be on dashboard view and upcoming schedule page
- All user roles need able to retrieve all contact informations
- Operator roles need able to pull well review related to his company. Refer separated endpoints below
7). Upload Data
- Create the following endpoints to create, update, delete, retrieve, retrieve all upload data.
- There will be 2 type of Update data: Single Upload and Upload Batch
- User id need saved every time user do Single Upload or Upload Batch
- After successfully uploaded, SMTP Email Server that will send email message after successfully upload data
- We need use the AWS Simple Email Service to send the email message.
8). Well Review
- This well review need connecting the Schedule data
- This well review data only viewable for Operator role that tied with the company id
- On frontend, we have Operator Upcoming schedule page to view this data
- Operator can add and edit the well review
- Well Review contains these fields: Risk Level, Performed By, Well Reviewed Status, Comments
- As part of this Well review, we need support multiple comments
9). Users
- This is for Admin role only
- Create the following endpoints to create, update, delete, retrieve, retrieve all user accounts.
Response
Re-use existing success/error response message.
Unit Testing
All of your code should be test covered. You must cover at least +90% of the code.
You need to test all cases and in test case assertion you need to assert accuracy of all fields.
Documentation
- Provide a detailed README documentation for how to setup and configure the application.
Scripts
- Provide scripts for all tables/collections
- Provide script to insert sample data for all endpoints
Postman Client
- Create postman environment and collection file that will listing all calls and sample data.
- Group each routes on Postman collection into separate folder
- Double check the parameters send
- Provide description for endpoints
- Get Started with Postman : http://www.getpostman.com/
Deployment
- REST API need support local build and deploy to Heroku
Configuration
- You are expected to use environment variables to store sensitive information and environment-specific configurations.
- Access token need auto-generated for logged in user. Do not use of static values
- Create quick documentation how to set up/use the variables on the actual development
What To Submit?
- All source code that implement the challenge requirements.
- README in markup language
- Verification document contains steps to verify your solution.
- External Scripts file.
- Video for Validation Purposes on localhost and Heroku
- All source code that implement the challenge requirements.
- README in markup language
- Verification document contains steps to verify your solution.
- External Scripts file.
- Video for Validation Purposes on localhost and Heroku
App environment:
REST API application based on Java 8, Maven, and MS SQL.
Basic Requirements for this challenge:
- Convert existing REST API from NodeJS to Java 8, Maven based.
- Implement best practice security the access data from REST API service. You may use Java Web Token or come up with your suggestions
- Need exact same REST API service endpoints.
- Create separated scripts outside of the app to run the database init, or add sample datas scripts, should not part of application command.
- Implement the unit testing for all endpoints on this Java 8, Maven based REST API.
Project Background
The goal of this project is to create a web based tool for operators to share frac schedules and locations with other operators. Currently we have a consortium of 15 operators that share their schedules via email roughly once a week to monthly. The email list changes monthly with people being added or taken off, which makes it tough to manage if you are getting all the schedules you need. Not only does the email list change, but so does each individual company’s frac schedule. With so many moving parts, manually sharing emails and aggregating schedules is unsustainable. These emails contain API # (unique public well identifier), well name, Frac start, Frac end, Bottom Hole Lat/Long, Surf Hole Lat/Long, and sometimes the underground formation name.
In the current state, we go into our internal mapping tool or the State website and manually measure out the distances between our well locations and the offset operators locations to see if we need to prepare our wells. From this frac schedule, it us up to the individual companies to check in to see if offset fracs are on time or delayed and if the operator will impact any of their assets. This methodology is cumbersome and time consuming. A tool should be easily accessible, be able to quickly upload operator information and provide a visual and user adjustable display of areas and times where frac operations may cause operational hazards due to “frac hits” http://www.eagleford.training/2015/08/what-are-frac-hits/
For this challenge, we’re in part where we need convert existing REST API that use NodeJS into Java 8, Maven technologies. Expected submission results need produce exact endpoints like current REST API that will be consumed for AngularJS app on the frontend.
Technology Stack
Programming language(s) to be used:
- Java 8
- Maven
Deployment environment requirements
- localhost
- Heroku
- AWS
Database
- MS SQL Server
Code access
AngularApp
https://gitlab.com/quartz-energy/ops-frac-schedule/web-application
Demo
https://ops-frac-schedule.herokuapp.com/
Application support 3 roles, make sure your updates affect all roles:
operator/password
admin/password
user/password
REST API Source Code
https://gitlab.com/quartz-energy/ops-frac-schedule/api-services-alt
Postman Collection for API endpoints Testing
https://gitlab.com/quartz-energy/ops-frac-schedule/api-services-alt/tree/dev/docs
REST API Service requirements:
- Please refer to existing REST API code. We need exact same endpoints that will be consume to our AngularJS app
- But for this new version, we need you to follow examples of services that are well implemented. For instance: https://docs.gitlab.com/ee/api/
- Important things need addressed is we need implement best practice security to access data from REST API services. You may use Java Web Token or come up with your suggestions
- Create separated scripts outside of the app to run the database init, or add sample datas used for the application.
- Need support localhost and Heroku deployment.
- Notice there are 3 separated roles used on the app.
- We’re encouraged you to adjust best practice and efficient schemas for every endpoints. Let’s discuss any solution, we’re open any advices.
Individual Endpoints Requirements
- This is the expected endpoints based on existing REST API. Read carefully for each endpoints for detailed requirements
1). Login
- Create the following endpoints to create, update, delete, retrieve, and retrieve all user collections.
- Create sample endpoints for 3 different user roles
- We need every userID tied with Company ID
- If the authorization are valid, then generate access token that will be consume to our frontend, with configurable expiration date, then return generated authorization token in response.
2). Lookup
- There are some lookup that need accessible for the dropdown or auto suggest:
-- Lookup all wells
-- Lookup US states (Create all US states data)
-- Lookup the Region
-- Lookup all company
-- Lookup all contact roles
- Current user logged in informations
3). Schedule
- Create the following endpoints to create, update, delete, retrieve, retrieve all data.
- Endpoints require valid authorization header
- Display Schedule summary like on top left of screenshot
- Need use clusterer marker on map, you can see some numbers on dot represents total operator.
- When zoom in the map need display scattered dots on map.
4). Company
- Create the following endpoints to create, update, delete, retrieve, and retrieve all company collections.
- All user roles need able to retrieve all company informations
- Admin role need add, edit, delete company
- Admin cannot delete company if there’s still contact data within the company
- Operator role need able to edit company that tied with his id only.
5). Contact
- Create the following endpoints to create, update, delete, retrieve, and retrieve all contacts collections.
- All user roles need able to retrieve all contact informations
- Admin role need add, edit, delete contacts
- Operator role need able to add, edit and delete that tied with his id only.
6). Schedule
- Create the following endpoints to create, update, delete, retrieve, and retrieve all schedule collections.
- on the frontend this will be on dashboard view and upcoming schedule page
- All user roles need able to retrieve all contact informations
- Operator roles need able to pull well review related to his company. Refer separated endpoints below
7). Upload Data
- Create the following endpoints to create, update, delete, retrieve, retrieve all upload data.
- There will be 2 type of Update data: Single Upload and Upload Batch
- User id need saved every time user do Single Upload or Upload Batch
- After successfully uploaded, SMTP Email Server that will send email message after successfully upload data
- We need use the AWS Simple Email Service to send the email message.
8). Well Review
- This well review need connecting the Schedule data
- This well review data only viewable for Operator role that tied with the company id
- On frontend, we have Operator Upcoming schedule page to view this data
- Operator can add and edit the well review
- Well Review contains these fields: Risk Level, Performed By, Well Reviewed Status, Comments
- As part of this Well review, we need support multiple comments
9). Users
- This is for Admin role only
- Create the following endpoints to create, update, delete, retrieve, retrieve all user accounts.
Response
Re-use existing success/error response message.
Unit Testing
All of your code should be test covered. You must cover at least +90% of the code.
You need to test all cases and in test case assertion you need to assert accuracy of all fields.
Documentation
- Provide a detailed README documentation for how to setup and configure the application.
Scripts
- Provide scripts for all tables/collections
- Provide script to insert sample data for all endpoints
Postman Client
- Create postman environment and collection file that will listing all calls and sample data.
- Group each routes on Postman collection into separate folder
- Double check the parameters send
- Provide description for endpoints
- Get Started with Postman : http://www.getpostman.com/
Deployment
- REST API need support local build and deploy to Heroku
Configuration
- You are expected to use environment variables to store sensitive information and environment-specific configurations.
- Access token need auto-generated for logged in user. Do not use of static values
- Create quick documentation how to set up/use the variables on the actual development
What To Submit?
- All source code that implement the challenge requirements.
- README in markup language
- Verification document contains steps to verify your solution.
- External Scripts file.
- Video for Validation Purposes on localhost and Heroku
Final Submission Guidelines
What To Submit?- All source code that implement the challenge requirements.
- README in markup language
- Verification document contains steps to verify your solution.
- External Scripts file.
- Video for Validation Purposes on localhost and Heroku