Omega Microservices - Course correction

Welcome to the Omega Microservices / API challenge. This challenge is the seventh in a series of challenges where will build an application for a world leading retail hardware and software solution manufacturer.

 

Project Overview

The goal of this application is to allow retail store operators to manage and provision security for their fleet of hardware and POS software. In this series we will be building our application APIs. This will be a series of microservices built in Golang connecting to a Cassandra database. We will be creating 13 microservices in total and have already completed seven of them so you will have some good examples.

 

Challenge Details

We have the following resources that will be built out as microservices:

 

 

For this challenge, we will be refactoring code and the API to provide a cleaner separation between resources within the DGES hierarchy. In an effort to reduce confusion and ensure that the YAML specification properly represents what the resources do, we need to refactor some microservice JSON object properties overall. Below is the bulk of the work necessary. There may be modules I missed, however it’s up to the developer to perform a thorough check and determine where all changes should be made across the microservice projects.

 

Specific guidelines:

 

1. We will not embed downstream hierarchies as sub-objects, instead we'll include an absolute resource URL (excluding host) for the client to fetch the downstream object or object collection. This will apply to Locations, Terminals, Endpoints, Endpoint Services, Peripherals, Manifests, Manifest Templates, Manifest Endpoints and Manifest Policies.

 

2. The following microservices need to be enhanced based on the YAML specification 0.0.9. Specifically:

   1. Add a locations resource property to the Enterprise Group object that can be used to retrieve Location objects. Hint: the URL should formatted as per the GET operation to retrieve the same, i.e. GET /urlbase/customers/{customerId}/enterpriseGroups/{groupId}/locations.

   2. Add a terminals property to the Location object that can be used to retrieve all terminals at a Location.  e.g. GET /urlbase/customers/{customerId}/locations/{locationId}/terminals  

   3. Add an endpointServices property to the Location object that can be used to retrieve all endpoint services associated with a Location.  e.g. GET /urlbase/customers/{customerId}/locations/{locationId}/endpointServices

   4. Replace the embedded Manifest object of the terminal with a resource URL that directs to the manifest e.g. GET /urlbase/customers/{customerId}/terminals/{terminalId}/manifests.

   5. Add a peripherals property to the Terminal object that can be used to retrieve all peripherals associated with a Terminal.  e.g. GET /urlbase/customers/{customerId}/terminals/{terminalId}/peripherals.

   6. Add an endpoints property to the Peripheral object that can be used to retrieve all endpoints associated with a Peripheral.  e.g. GET /urlbase/customers/{customerId}/peripherals/{peripheralId}/endpoints.

   7. Add a terminals property to the EndpointService object that can be used to retrieve all terminals associated with an EndpointService.  e.g. GET /urlbase/customers/{customerId}/endpointServices/{endpointServiceId}/terminals.

   8. Replace the embedded ManifestEndpoint collection of the manifest template with a resource URL that fetches the associated manifest endpoints e.g. GET /urlbase/customers/{customerId}/manifestTemplates/{manifestTemplateId}/manifestEndpoints.

   9. Replace the embedded ManifestEndpoint collection of the manifest with a resource URL that fetches the associated manifest endpoints e.g. GET /urlbase/customers/{customerId}/manifests/{manifestId}/manifestEndpoints.

   10. Replace the embedded ManifestPolicy collection of the manifest endpoint with a resource URL that fetches the associated manifest policies e.g. GET /urlbase/customers/{customerId}/manifestEndpoints/{manifestEndpointId}/manifestPolicies.

 

3. Terminals currently stores the manifest and its children (manifest, manifest endpoints, manifest endpoint permissions) in a database text field. Now that we have created the manifest microservice we need to refactor terminals so that it makes use of those APIs for fetching the manifest and its corresponding child collections. Some of what needs to be addressed:

   1. When deleting a terminal, remove the manifest association from the terminal - the manifest will be orphan but still exist on its own.

   2. Remove the code in the update terminal that allows for manifest data to be included. A Manifest would be associated in a separate operation via the manifests microservice.

   3. Remove the code in the create terminal that allows for including manifest data. A manifest will be associated in a separate operation via the manifests microservice.

   4. When retrieving one or a list of terminals, do not retrieve the manifests. The manifest can be retrieved (when needed) via the manifests microservice.

 

As part of this challenge, you also need to make sure that you take care of the following:

1. Update the “dgestool” utility if required

2. Update the Unit Tests if required.

 

Following are points that you need to take care of:

1. Domain data isolation: each microservice “owns” its respective Cassandra keyspace, if another microservice wants to access data that is not its own, it must do so through the foreign microservice’s API and not attempt to access the Cassandra keyspace directly.  A good example of this can be found in the locations service where the service verifies the existence of the parent enterprisegroup by creating a web service client and querying enterprisegroups microservice for the enterprisegroup in question.

2. Sanitize the input data and ensure that the microservice that you build is not prone to SQL-injection type of attacks: use parameters for querying which will also allow special characters from being interpreted as part of the CQL script.   

3. For all purposes, we strongly suggest that you follow the design and architecture of the “Locations” microservice.

4. You are developing microservices. As such, we expect that your submission for the Manifests microservice should be independent of the other existing microservices. Under no circumstances should any of the microservice be dependent on the other. Do not create any common code outside of the microservice that you are working on. This may result in redundant code that is present across all the microservices and we are fine with that.

Final Submission Guidelines

Submit your source code in zip file to TopCoder Online Review. Your submission must include the following:

• Detailed setup instructions. We have already provided our setup instructions. If there are any changes to that, ensure that you update it.
• Unit tests
• No Video required.
• Code coverage is NOT required. However, kindly note that you should not remove tests which break after the refactor. The current spirit of the test coverage mush remain consistent.