Challenge Overview
Challenge Objectives
-
Update the legacy challenge processor to directly write into the database instead of calling the legacy APIs.
Tech Stack
-
Node.js
-
Apache Kafka
-
InformixDB
-
ElasticSearch
-
DynamoDB
Project Background
In this series of challenges, we will build the version 5 (V5) of the challenge API.
Code Access
Repo: https://github.com/topcoder-platform/legacy-challenge-processor
Branch: develop
API & ES processor
You will have to deploy those locally:
Repo: https://github.com/topcoder-platform/challenge-api
Branch: develop
Repo: https://github.com/topcoder-platform/challenge-processor-es
Branch: develop
Detailed requirements
Previously, we created a processor that will listen to events from our new V5 challenge API and will call the legacy V4 API to backfill the information.
Due to instabilities in the V4 API, as part of this challenge, we need your help to update the processor to write directly into the Informix database using the https://www.npmjs.com/package/ifxnjs module instead of calling the API.
You will find attached on the challenge forum the source code of the legacy v4 challenge API which is written in Java. This is provided just for reference and you are not expected to work on it.
You will also find attached a document in Markdown format that explains in detail the flow of the legacy app and includes the related SQL queries. You can use it as a guide.
Reduced scope! Since this has been proven to be a quite complex task, only creating the challenge record in the legacy DB without doing any checks is in the scope of this challenge.
Only the following points from the provided Markdown document are in scope:
Create the asset DTO
-
SQL (via Hibernate) : Save the created component (`direct-app/services/catalog_services/src/java/main/com/topcoder/catalog/service/CatalogServiceImpl.java` line 257)
-
SQL (via Hibernate) : Save the component version (`direct-app/services/catalog_services/src/java/main/com/topcoder/catalog/service/CatalogServiceImpl.java`) line 261
-
SQL (via Hibernate): There's some wonky stuff here around version documentation. In `CatalogServiceImpl.java`, line 1073, we go through all documentation potentially added in the frontend (??!?) and then does a bunch of complex stuff if any is found. Then, for each new documentation element "merged", we save it back to the DB in line 265. This one is tagged with all sorts of "BUGR-1600", which we may be able to pull up from JIRA to see what the deal was?
-
The ID from the DB is set to the asset, asset version number, and asset compVersionId. Seems slightly redundant.
Refer to the document for more details.
Updating the tests is out of scope.
Should you have any questions, feel free to ask on the challenge forum!
What to Submit
Submit a git patch file for the latest commit in the develop branch.
Make sure to mention the exact commit you used so we can apply your patch without issues and a verification document with details on how to verify your submission.