Challenge Overview
Project Overview
The Early Alert Tool (EAT) is a data store for all of the Codes and Standards which Thor needs to follow when developing products. As codes and standards change or improve, the divisions within Thor (specifically the division leaders and product managers) need to be alerted of these changes.
The division leaders document the issues which arise from any of these changes along with and need to track details on the action plans for those issues. A number of different users would will be using the application. There could be codes & standards committee representatives who notify other key point people (product managers or division leaders) of the changes.
The main goal of the application is three-fold:
1. Highlight the standards which have been identified by the business divisions as important
2. Notify people within divisions of standards changes (email functionality)
3. Track the internal corporate action plans issues related to standards changes
For this challenge we need your help to building backend data model and J2EE REST API for Thor Early Alert Tools application by following swagger file and analyze data from provided storyboard screens.
On challenge specification we analyzed the storyboard design screens and wrote down the routes that we think that will be proper for this system. As part of this challenge, you are highly encouraged to review the storyboard workflow/content and suggest any improvements. You also need create best practice table/collection on each section on SQL Server database.
REST API Technology Requirement
We will use following technology stack in this challenge :
- JBOSS EAP 7.0 (not 7.1.1)
- JAVA 8
- Spring 5.0.6.RELEASE
- MS SQL Server
Ragnar: Check forum to get Ragnar Self Registration Access
Docker & Swagger Challenge Result
- Please check Docker setup and Swagger file: https://gitlab.com/thor-early-alert-tool/architecture
Design Assets as Reference
Storyboard Source Files: https://drive.google.com/open?id=1x5S7h93IUJDHqtMCoZk7yBTaqyhJYQPj
MarvelApp flow: https://marvelapp.com/40d8gb0
REST API Submission Generals Requirements
- We will use J2EE to build the REST API and MS SQL Server as database source
- Always refer to provided Swagger file when build the REST API
- Create Database schema for each table/collections based data/fields displayed on provided storyboard screens
- Make sure your submission possible to develop on based on provided storyboard screens
- You’re encouraged to improve/suggest proper Database based on existing
- We will host our app on Docker with this REST Services SQL Server database on let us know any suggestions. Make sure your submission configuration can support that.
1). Code Standard
- IMPORTANT: For this REST API services build you must follow client provided coding standard. Please check the details here: https://docs.google.com/document/d/1JLDieRq7Q8gw86FoQd2qjza33sH5Dq0PD23JH7804pc/edit?usp=sharing
2). Base Structure
- App will need to be J2EE (Java 8 base) /, using the Spring 5.0.6.RELEASEframework. It will be deployed on JBOSS EAP 7.0 and will need to be delivered either as a WAR or EAR format (with included source)
3). SQL Auth
- Services app will be hosted on Windows based OS, We may need to support windows auth for the SQL access. Check the details here:
https://artisticcheese.wordpress.com/2018/01/27/extending-windows-authentication-in-docker-containers-in-accessing-cross-container-resources/
4). Password Management
- Minimum password length (typical user-id) must be at least nine (9) characters.
- Maximum Password Age (Password expiration) must be no greater than 90 days.
- Password complexity (Password strength) - passwords must consist of a minimum of three (3) of the following four (4) character sets:
-- Upper Case Alphabetic, ( A, B, C, … Z )
-- Lower Case Alphabetic, ( a, b, c, … z )
-- Numeric, ( 0, 1, 2, … 9 )
-- Special Characters, (e.g. space,!,$,#,% )
- Password history, where available, must be a minimum of 24 generations or maximum allowed by application/system, if less than 24.
5). Email Sending
- Send e-mail notification to all data manager and Admin users when Standard is updated (after approved and committed to standard table)
- Default text for this email should be stored and retrieved in a JSON configuration file
- Send e-mail notification to all data manager and Admin users when new Standard is added
- Default text for this email should be stored and retrieved in a JSON configuration file
6). Update GET /standardDivisions
- The GET /standardDivisions endpoint would be the junction of all of the data shown in the table (containing reference to standard, organization, division, contact, product line). The client is looking to search across the standards, organizations, divisions, product line and contacts via the keyword search on /standardDivisions
- This will be use on Keyword Search and Organization Standard Search
- Update related Swagger specification
- Update table fields
- Update initial data scripts
{
"total": 0,
"query": {
"offset": 0,
"limit": 15,
"divisionId": "string",
"subDivisionId": 0,
"productLineId": 0,
"organizationId": 0,
"standardId": 0,
"keyword": "string"
},
"items": [
{
"id": 1,
"criticalToBusiness": true,
"comment": "a comment",
"standardParticipant": [
"JohnIDoes@Eaton.com"
],
"standard": {
"id":1,
"name":"Standard Name",
"description":"Standard Description",
"organization": {
"id":1,
"name": "Organization name"
},
},
"division": {
"id":1,
"name":"Division Name",
"region":"Region Name"
},
"subDivistion": {
"id":1,
"name":"SubDivision Name"
},
"productLine": {
"id":1,
"name":"Product Line Name"
}
}
]
}
7). Add sortColumn and sortDirection to search endpoints
- Add sortColum and sortDirection to the search endpoints
- Update GET /standardDivisions endpoint to have the sortColumn and sortDirection
- Update GET /cnSIssues endpoint to have the sortColumn and sortDirection
- Update GET /users endpoint to have the sortColumn and sortDirection
- Update GET /changeRequests endpoint to have the sortColumn and sortDirection
- Update related Swagger specification
- Update table fields
- Update initial data scripts
REST API Submission Individual Requirements
- You will build REST API for all pages, here is list of endpoints to implement, you can suggest changes but you need to post in forums for confirmation and discussion.
- Please check the detailed swagger file here: https://gitlab.com/thor-early-alert-tool/architecture/blob/master/open-api-spec/swagger.yaml
- As part of this challenge you must make sure your submission possible to use based on our winning storyboard:
- Important: We override some endpoints structure as explained above.
Filtering
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
Pagination
We need to add pagination when user scrolling the page, these endpoint should have the following parameters :
- offset (default 0)
- limit (default 20)
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
Validation
Perform the following validation in each API endpoint :
Path parameters :
- They usually represents the ID of existing objects, a validation should be done that the entity with ID exists, otherwise return error.
- Required input parameters in create endpoints must be present. For update endpoints we can pass only the fields that should be updated.
- Required input parameters should be validated against their expected type.
- Optional input parameters should be validated against their expected type if provided.
- Foreign keys must be validated.
- Validation between callbacks must be performed.
Errors should be in json format with three fields :
- code : http status code
- status : success/failed
- message : reason of failure
Request and Response
- GET endpoints parameters will accept parameters as query strings, in key/value format.
- Create/Update endpoint parameters will accept input as JSON format.
- Exclude file upload endpoints which cannot work with application/json content type.
- Response should be in json format always.
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.
Hosting
- It is preferred if you provide scripts and steps to deploy the application in Live Site
Documentation
- Provide a detailed README documentation for how to setup and configure the application.
Configurations
- You are expected to use environment variables to store sensitive information and environment-specific configurations.
Scripts
- Provide scripts for all tables/collection
- Provide script to insert default users.
- Provide script to insert sample data
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
- Provide description for endpoints
- Get Started with Postman : http://www.getpostman.com/
- All source code that implement the challenge requirements.
- REST API matching with storyboard screens/flow
- README in markup language
- Verification document contains steps to verify your solution.
- Scripts input files
The Early Alert Tool (EAT) is a data store for all of the Codes and Standards which Thor needs to follow when developing products. As codes and standards change or improve, the divisions within Thor (specifically the division leaders and product managers) need to be alerted of these changes.
The division leaders document the issues which arise from any of these changes along with and need to track details on the action plans for those issues. A number of different users would will be using the application. There could be codes & standards committee representatives who notify other key point people (product managers or division leaders) of the changes.
The main goal of the application is three-fold:
1. Highlight the standards which have been identified by the business divisions as important
2. Notify people within divisions of standards changes (email functionality)
3. Track the internal corporate action plans issues related to standards changes
For this challenge we need your help to building backend data model and J2EE REST API for Thor Early Alert Tools application by following swagger file and analyze data from provided storyboard screens.
On challenge specification we analyzed the storyboard design screens and wrote down the routes that we think that will be proper for this system. As part of this challenge, you are highly encouraged to review the storyboard workflow/content and suggest any improvements. You also need create best practice table/collection on each section on SQL Server database.
REST API Technology Requirement
We will use following technology stack in this challenge :
- JBOSS EAP 7.0 (not 7.1.1)
- JAVA 8
- Spring 5.0.6.RELEASE
- MS SQL Server
Ragnar: Check forum to get Ragnar Self Registration Access
Docker & Swagger Challenge Result
- Please check Docker setup and Swagger file: https://gitlab.com/thor-early-alert-tool/architecture
Design Assets as Reference
Storyboard Source Files: https://drive.google.com/open?id=1x5S7h93IUJDHqtMCoZk7yBTaqyhJYQPj
MarvelApp flow: https://marvelapp.com/40d8gb0
REST API Submission Generals Requirements
- We will use J2EE to build the REST API and MS SQL Server as database source
- Always refer to provided Swagger file when build the REST API
- Create Database schema for each table/collections based data/fields displayed on provided storyboard screens
- Make sure your submission possible to develop on based on provided storyboard screens
- You’re encouraged to improve/suggest proper Database based on existing
- We will host our app on Docker with this REST Services SQL Server database on let us know any suggestions. Make sure your submission configuration can support that.
1). Code Standard
- IMPORTANT: For this REST API services build you must follow client provided coding standard. Please check the details here: https://docs.google.com/document/d/1JLDieRq7Q8gw86FoQd2qjza33sH5Dq0PD23JH7804pc/edit?usp=sharing
2). Base Structure
- App will need to be J2EE (Java 8 base) /, using the Spring 5.0.6.RELEASEframework. It will be deployed on JBOSS EAP 7.0 and will need to be delivered either as a WAR or EAR format (with included source)
3). SQL Auth
- Services app will be hosted on Windows based OS, We may need to support windows auth for the SQL access. Check the details here:
https://artisticcheese.wordpress.com/2018/01/27/extending-windows-authentication-in-docker-containers-in-accessing-cross-container-resources/
4). Password Management
- Minimum password length (typical user-id) must be at least nine (9) characters.
- Maximum Password Age (Password expiration) must be no greater than 90 days.
- Password complexity (Password strength) - passwords must consist of a minimum of three (3) of the following four (4) character sets:
-- Upper Case Alphabetic, ( A, B, C, … Z )
-- Lower Case Alphabetic, ( a, b, c, … z )
-- Numeric, ( 0, 1, 2, … 9 )
-- Special Characters, (e.g. space,!,$,#,% )
- Password history, where available, must be a minimum of 24 generations or maximum allowed by application/system, if less than 24.
5). Email Sending
- Send e-mail notification to all data manager and Admin users when Standard is updated (after approved and committed to standard table)
- Default text for this email should be stored and retrieved in a JSON configuration file
- Send e-mail notification to all data manager and Admin users when new Standard is added
- Default text for this email should be stored and retrieved in a JSON configuration file
6). Update GET /standardDivisions
- The GET /standardDivisions endpoint would be the junction of all of the data shown in the table (containing reference to standard, organization, division, contact, product line). The client is looking to search across the standards, organizations, divisions, product line and contacts via the keyword search on /standardDivisions
- This will be use on Keyword Search and Organization Standard Search
- Update related Swagger specification
- Update table fields
- Update initial data scripts
{
"total": 0,
"query": {
"offset": 0,
"limit": 15,
"divisionId": "string",
"subDivisionId": 0,
"productLineId": 0,
"organizationId": 0,
"standardId": 0,
"keyword": "string"
},
"items": [
{
"id": 1,
"criticalToBusiness": true,
"comment": "a comment",
"standardParticipant": [
"JohnIDoes@Eaton.com"
],
"standard": {
"id":1,
"name":"Standard Name",
"description":"Standard Description",
"organization": {
"id":1,
"name": "Organization name"
},
},
"division": {
"id":1,
"name":"Division Name",
"region":"Region Name"
},
"subDivistion": {
"id":1,
"name":"SubDivision Name"
},
"productLine": {
"id":1,
"name":"Product Line Name"
}
}
]
}
7). Add sortColumn and sortDirection to search endpoints
- Add sortColum and sortDirection to the search endpoints
- Update GET /standardDivisions endpoint to have the sortColumn and sortDirection
- Update GET /cnSIssues endpoint to have the sortColumn and sortDirection
- Update GET /users endpoint to have the sortColumn and sortDirection
- Update GET /changeRequests endpoint to have the sortColumn and sortDirection
- Update related Swagger specification
- Update table fields
- Update initial data scripts
REST API Submission Individual Requirements
- You will build REST API for all pages, here is list of endpoints to implement, you can suggest changes but you need to post in forums for confirmation and discussion.
- Please check the detailed swagger file here: https://gitlab.com/thor-early-alert-tool/architecture/blob/master/open-api-spec/swagger.yaml
- As part of this challenge you must make sure your submission possible to use based on our winning storyboard:
- Important: We override some endpoints structure as explained above.
Filtering
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
Pagination
We need to add pagination when user scrolling the page, these endpoint should have the following parameters :
- offset (default 0)
- limit (default 20)
The parameters should be returned in the response with the total count of matching records as well, It is preferred if the default values are configurable.
Validation
Perform the following validation in each API endpoint :
Path parameters :
- They usually represents the ID of existing objects, a validation should be done that the entity with ID exists, otherwise return error.
- Required input parameters in create endpoints must be present. For update endpoints we can pass only the fields that should be updated.
- Required input parameters should be validated against their expected type.
- Optional input parameters should be validated against their expected type if provided.
- Foreign keys must be validated.
- Validation between callbacks must be performed.
Errors should be in json format with three fields :
- code : http status code
- status : success/failed
- message : reason of failure
Request and Response
- GET endpoints parameters will accept parameters as query strings, in key/value format.
- Create/Update endpoint parameters will accept input as JSON format.
- Exclude file upload endpoints which cannot work with application/json content type.
- Response should be in json format always.
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.
Hosting
- It is preferred if you provide scripts and steps to deploy the application in Live Site
Documentation
- Provide a detailed README documentation for how to setup and configure the application.
Configurations
- You are expected to use environment variables to store sensitive information and environment-specific configurations.
Scripts
- Provide scripts for all tables/collection
- Provide script to insert default users.
- Provide script to insert sample data
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
- Provide description for endpoints
- Get Started with Postman : http://www.getpostman.com/
Final Submission Guidelines
Deliverables- All source code that implement the challenge requirements.
- REST API matching with storyboard screens/flow
- README in markup language
- Verification document contains steps to verify your solution.
- Scripts input files