Challenge Overview
The client is building the Fund Accounting Yield Application (FAYA), previously referred to as the SEC Yield application. This is the 2nd phase, where we adding new calculation engines and add more front end features for the end user.
What is expected from you in this challenge:
- Use the frontend app to design and implement the Spring REST API in scope.
- Reuse an existing REST API that you will use for delegating some of the logic, or reusing entities.
- Write unit tests for the api.
- Provide test data and updated POSTMAN files.
https://drive.google.com/open?id=0By6n2kEXozMwUUVmQUZYY0JoSXc
Here is the list the APIs we need to implement along with where they are going to be used in the frontend pages:
1. Get Funds by type
- Used to retrieve funds list by type, type here is : SEC yield, Money Market yield, or Distribution yield.
- Route : /funds/:type?date=<business date>
- Used in following pages : ([Funds available for submit section](http://54.208.2.67:5555/dashboard), [Fund Review - Sec yield table](http://54.208.2.67:5555/fund-review/sec-yield), [Money Market Yield table](http://54.208.2.67:5555/fund-review/mm-yield), and [Distribution Yield table](http://54.208.2.67:5555/fund-review/mm-yield))
- If date is not passed, it should use current date by default
- type path parameter is required always.
- For sec yield to pull funds, you will use existing API `GET /fundAccountingSECYieldData`, you can find this api defined under fundyield-api folder
- For MM yield to pull funds, you will use existing api `GET /moneyMarketFundYieldData`, you can find this api defined under fundyield-api folder
- For Dist yeild to pull funds, you will use existing api `GET /distributionFundYieldData`, you can find this api defined under fundyield-api folder
2. Get Sec Yield by CUSIP
- Retrieves the SEC yield of the passed CUSIP
- Route : /secYield/cusip/:cusip
- This api will delegate the call to a fundyield-api REST API, which will delegate to faya-api REST API, we need to add new API added to faya-api folder, that pulls the sec yield from persistence using the passed in CUSIP.
- Refer to existing API that pull SEC Yield to understand how to populate the entities and return them
- It is used by What analysis main page http://54.208.2.67:5555/what-if-analysis, and results will be rendered in sub-pages i.e. http://54.208.2.67:5555/what-if-analysis/tips page
- The UI field names does not match the sec yield model structure, we have a mapping excel file for you to use to map between the UI and model https://drive.google.com/open?id=0B8huYiP6g3MLdVJ6UUJWZDlqUkUtSU9hYTE1SkU0ajUycEpv (this is a mapping between old code name and new one, if you still not sure, please post in forums and we will clarify)
3. Submit What If Analysis Changes
- This submit the sec yield with the overridden values
- Route: POST /funds/:CUSIP/WhatIfAnalysis where body contains the field changes, and the comment
- It will save the status of the fund as "submitted"
- We will have new table that store the overridden fields, you can name it "WhatIfAnalysisFields" table, and you need to document clearly in a PDF document the mapping between the fields in the table and the SEC Yield fields.
- The editable fields are outlined in this document in case it is not clear from prototype https://docs.google.com/document/d/1USomqhUCYw5t6mwuZvYQJElhPE3JxB3vTdM55QVMtfU/edit?usp=sharing
- The call will be done in http://54.208.2.67:5555/what-if-analysis/tips and similar pages to submit the fund changes for review under Admin/approver review page
4. Recalculate SEC Yield
- This will recalculate the sec yield fund using the overridden values without persisting them
- Route : POST /funds/:CUSIP/recalculate where body contains the changes
- Used in http://54.208.2.67:5555/what-if-analysis/tips what user changes/override any value
- The api expected to be implemented is similar to GET /fundAccountingSECYieldData with difference that we use the overriden fields for calculation, we don't do any persistences work here, only do the calculation and return the results.
5. Get Funds Pending Review
- This retrieves the SEC Yield funds submitted and pending review, this will read from WhatIfAnalysis and SEC Yield fund tables.
- Route: GET /funds/review
- This only accessible by Admin/approver in the review page http://54.208.2.67:5555/approval and http://54.208.2.67:5555/approval/123456789
- It should only retrieve funds pending review
6. Submit Fund Review
- This will be used by admin/approver to submit the what if analysis modification review http://54.208.2.67:5555/approval
- Route : POST /fund/:CUSIP/review where body contains fields changes, OR the review status (rejected/approved)
- The admin/approver can change values, so this will behave like `Submit What If Analysis Changes` api where it will update changes to the new table, it will also update the status field to proper status : accepted or rejected
7. Submit Fund To FIRS/UNITY
- This is used to submit the approved fund to FIRS/UNITY
- Route : POST /fund/type/:type/id/:id with body contains type=<type> where type is FIRS or UNITY
- It is used in Fund review pages http://54.208.2.67:5555/fund-review/sec-yield
- We simply update the fund related table to store the type the fund is submitted to, and add a flag that indicates it was submitted
8. SSO implementation
- You are provided in the challenge forums with architecture update files that include the changes needed to implement SSO through spring interceptors, the Security class diagram in TCUML explains what you need to do, also you need to write the ADS document for more information about the security implementation.
- The security should be applied into this new API we are building
- If you need any common entities, you will need to reuse seccommons folder
- The API should be placed in its own war file, it will communicate with existing API via http calls
- All APIs implemented here will delegate to REST API placed under fundyield-api folder/war, which in turn will delegate to faya-api persistence APIs. Make sure to follow this structure.
- All sql commands will be executed as Stored Procedures as done in current code.
- Update README file
- Provide POSTMAN for all the new/updated APIs
- Update sql script files
- Update test data files
- Also provided the UI prototype
- Spring REST API
- JSON
- Apache HTTP Server
- Tomcat 8
- Spring Framework 4.x http://projects.spring.io/spring-framework/
- Log4j 1.2 http://logging.apache.org/log4j/1.2/
- Joda-Time 2.9 http://www.joda.org/joda-time/installation.html
- Oracle 11g express edition
- It is Ok to submit a full source code if you are new to git versioning
- Winner will be asked to do a merge request to the original repository after challenge ends
Challenge Overview
The goal of this challenge is to build Spring REST API to support a frontend angular application http://54.208.2.67:5555/ .What is expected from you in this challenge:
- Use the frontend app to design and implement the Spring REST API in scope.
- Reuse an existing REST API that you will use for delegating some of the logic, or reusing entities.
- Write unit tests for the api.
- Provide test data and updated POSTMAN files.
Challenge Requirements
Refer to this pdf (slide 3), it shows the structure of the application, it show that the frontend api should be on its own container (war file), it will delegate the persistence logic to another war container which is the faya-api in existing source codehttps://drive.google.com/open?id=0By6n2kEXozMwUUVmQUZYY0JoSXc
Here is the list the APIs we need to implement along with where they are going to be used in the frontend pages:
1. Get Funds by type
- Used to retrieve funds list by type, type here is : SEC yield, Money Market yield, or Distribution yield.
- Route : /funds/:type?date=<business date>
- Used in following pages : ([Funds available for submit section](http://54.208.2.67:5555/dashboard), [Fund Review - Sec yield table](http://54.208.2.67:5555/fund-review/sec-yield), [Money Market Yield table](http://54.208.2.67:5555/fund-review/mm-yield), and [Distribution Yield table](http://54.208.2.67:5555/fund-review/mm-yield))
- If date is not passed, it should use current date by default
- type path parameter is required always.
- For sec yield to pull funds, you will use existing API `GET /fundAccountingSECYieldData`, you can find this api defined under fundyield-api folder
- For MM yield to pull funds, you will use existing api `GET /moneyMarketFundYieldData`, you can find this api defined under fundyield-api folder
- For Dist yeild to pull funds, you will use existing api `GET /distributionFundYieldData`, you can find this api defined under fundyield-api folder
2. Get Sec Yield by CUSIP
- Retrieves the SEC yield of the passed CUSIP
- Route : /secYield/cusip/:cusip
- This api will delegate the call to a fundyield-api REST API, which will delegate to faya-api REST API, we need to add new API added to faya-api folder, that pulls the sec yield from persistence using the passed in CUSIP.
- Refer to existing API that pull SEC Yield to understand how to populate the entities and return them
- It is used by What analysis main page http://54.208.2.67:5555/what-if-analysis, and results will be rendered in sub-pages i.e. http://54.208.2.67:5555/what-if-analysis/tips page
- The UI field names does not match the sec yield model structure, we have a mapping excel file for you to use to map between the UI and model https://drive.google.com/open?id=0B8huYiP6g3MLdVJ6UUJWZDlqUkUtSU9hYTE1SkU0ajUycEpv (this is a mapping between old code name and new one, if you still not sure, please post in forums and we will clarify)
3. Submit What If Analysis Changes
- This submit the sec yield with the overridden values
- Route: POST /funds/:CUSIP/WhatIfAnalysis where body contains the field changes, and the comment
- It will save the status of the fund as "submitted"
- We will have new table that store the overridden fields, you can name it "WhatIfAnalysisFields" table, and you need to document clearly in a PDF document the mapping between the fields in the table and the SEC Yield fields.
- The editable fields are outlined in this document in case it is not clear from prototype https://docs.google.com/document/d/1USomqhUCYw5t6mwuZvYQJElhPE3JxB3vTdM55QVMtfU/edit?usp=sharing
- The call will be done in http://54.208.2.67:5555/what-if-analysis/tips and similar pages to submit the fund changes for review under Admin/approver review page
4. Recalculate SEC Yield
- This will recalculate the sec yield fund using the overridden values without persisting them
- Route : POST /funds/:CUSIP/recalculate where body contains the changes
- Used in http://54.208.2.67:5555/what-if-analysis/tips what user changes/override any value
- The api expected to be implemented is similar to GET /fundAccountingSECYieldData with difference that we use the overriden fields for calculation, we don't do any persistences work here, only do the calculation and return the results.
5. Get Funds Pending Review
- This retrieves the SEC Yield funds submitted and pending review, this will read from WhatIfAnalysis and SEC Yield fund tables.
- Route: GET /funds/review
- This only accessible by Admin/approver in the review page http://54.208.2.67:5555/approval and http://54.208.2.67:5555/approval/123456789
- It should only retrieve funds pending review
6. Submit Fund Review
- This will be used by admin/approver to submit the what if analysis modification review http://54.208.2.67:5555/approval
- Route : POST /fund/:CUSIP/review where body contains fields changes, OR the review status (rejected/approved)
- The admin/approver can change values, so this will behave like `Submit What If Analysis Changes` api where it will update changes to the new table, it will also update the status field to proper status : accepted or rejected
7. Submit Fund To FIRS/UNITY
- This is used to submit the approved fund to FIRS/UNITY
- Route : POST /fund/type/:type/id/:id with body contains type=<type> where type is FIRS or UNITY
- It is used in Fund review pages http://54.208.2.67:5555/fund-review/sec-yield
- We simply update the fund related table to store the type the fund is submitted to, and add a flag that indicates it was submitted
8. SSO implementation
- You are provided in the challenge forums with architecture update files that include the changes needed to implement SSO through spring interceptors, the Security class diagram in TCUML explains what you need to do, also you need to write the ADS document for more information about the security implementation.
- The security should be applied into this new API we are building
Folder Structure
- Follow the current folder structure used by faya-api and fundyield-api- If you need any common entities, you will need to reuse seccommons folder
- The API should be placed in its own war file, it will communicate with existing API via http calls
Unit Tests
You will implement unit tests for all new code you are adding, you should provide accuracy and failure unit tests, and try to cover all edges and cases. You will need to use mocks, but not create too many mock objects, as it is hard to maintain. Some limited level of mocking is acceptable. Use [mockito] (http://mockito.org/) as the preferred library. It is also expected that you will write full functional tests to validate each piece of functionality.General Notes
- You are reusing the existing entities and DB tables to populate frontend except for WhatIfAnalysis table, it is new table.- All APIs implemented here will delegate to REST API placed under fundyield-api folder/war, which in turn will delegate to faya-api persistence APIs. Make sure to follow this structure.
- All sql commands will be executed as Stored Procedures as done in current code.
- Update README file
- Provide POSTMAN for all the new/updated APIs
- Update sql script files
- Update test data files
Documents
- Provided in challenge forums the existing source code and architecture- Also provided the UI prototype
Technology overview
- Java 8- Spring REST API
- JSON
- Apache HTTP Server
- Tomcat 8
- Spring Framework 4.x http://projects.spring.io/spring-framework/
- Log4j 1.2 http://logging.apache.org/log4j/1.2/
- Joda-Time 2.9 http://www.joda.org/joda-time/installation.html
- Oracle 11g express edition
Final Submission Guidelines
Deliverables
- Updated git patch file for the new/updated files that implemented the requirements- It is Ok to submit a full source code if you are new to git versioning
- Winner will be asked to do a merge request to the original repository after challenge ends