72h Odyssey Microservices - Channel Activity History and Channel Router

 

CHALLENGE OBJECTIVES

• Build the following microservices:

  • Channel Activity History Service

  • Channel Router Service

• Make some minor updates to some existing services

  • SMS Service

  • Email Service

 

TECHNOLOGY STACK

• Java 11

• Spring 5.2.8

• Spring Boot 2.3.3

• Spring Security 5.3.5

• Log4j/Slf4j

• JSON (gzipped)

• REST

• Microservices

• Docker

• SMTP

• MySQL 8.0

• JPA

 

REQUIREMENTS

The following common and generic requirements must all be followed:

• Implement the mentioned microservices below

• Follow the same structure and practices that we have implemented in the existing microservices, make sure you set up the same code style check and format commands like the existing ones

• All Data being Ingress or Egress from Spring Boot Application needs to be GZIPPED (see https://www.javainuse.com/spring/boot-zip for an example)

• Each of the microservices need to be buildable and deployable on its own, i.e. there should be no direct build dependency between any of them so we can have them in separate repos, and it must be possible to deploy them to different servers.

• Licenses to be followed in development:

  • Apache License 2.0

  • MIT License

  • Common Development and Distribution License

  • Eclipse Public License version 2.0

• Service should follow Spring Slueth Tracking (check the Server Side Request Tracking document shared in the forum)

• Implement logging properly for each service

  • Please follow the requirements in the Server Side Logging document shared in the forum

  • You must use Aspect Oriented Programming (AOP) for Trace Logging

• Exception handling should be implemented as described in the Service Exceptions Coding Convention document shared in the forum

• Service Registration and Service Discovery must be supported (if you just follow the same approach that  the existing services are using, you should be fine)

• Data traversal between the logical layers in microservice architecture should follow the scope bounding rules for application entities and domain entities, separation of concerns needs to be adhered to strictly:
  

• Other guidelines mentioned in the Guiding Principles document shared in the forum must be followed

• Reusability as much as possible. Please build common components in order to delegate basic activities like Encryption, decryption, masking, hashing etc. These components can be packaged into its own common components archives, reusable by all the microservices being developed. Please add common code to the existing cyn-commons package.

• Each microservice will have its own / separate schema.

• Service to service trust establishment mechanism must be implemented in the same way as the provided microservices.

• Service names in pom should start with cyn- prefix, for example for the Channel Activity History Service, the final built jar would be cyn-channel-activity-history-service.jar, and the version would be 1.0.0. If you simply follow the same convention as the provided existing services, you should be good.

• Please note we consider the requirements and client guidelines mentioned above to be major requirements.

 

Channel Activity History Microservice

• Service name: cyn-channel-activity-history-service

• Please use com.cyn.ccds.event.channel.activityhistory as root package name for this service

• Please carefully check the provided document on implementation details of the service:

  • The swagger file defines the endpoints to be implemented

    • /recordChannelActivity: this endpoint simply takes the request, generates a unique activity log id, save the info into database and return the activity log id in the response

      • Please note the payload comes in encrypted so the api must decrypt the payload first

      • The request structure needs to be updated: channelId should be renamed to channelIds which is an array of ids

      • The endpoint should generate a unique activity log id for each channel id and return the response as a map

      • There should be one database entry per such activity log id, channel id pair

    • /updateChannelActivity: this endpoint will find the existing record from the database using the provided activity log id, and updated the fields in the database with the new information provided

      • Please note the payload comes in encrypted so the api must decrypt the payload first

    • /public_cred and /add_public_cred are the regular endpoints used to establish service trust

  • The pdf defines some stubs that you can use as a reference for your implementation

• Database model:

  • Should define at least one database table that will store the information used in the endpoints, use CHANNEL_ACTIVITY_LOG as table name with the following fields:

    • activityLogId

    • componentName

    • customerUniqueIdentifier

    • serviceEvent

    • message

    • channelId

    • Receipt

    • transmissionDateTime

• Proper configuration & logging should be implemented

• Provide a docker file for this microservice so we can build it into a docker image

 

Channel Router Microservice

• Service name: cyn-channel-router-service

• Please use com.cyn.ccds.event.channel.router as root package name for this service

• This service will use “CCDS_CYN_CHANNEL_ROUTER_SERVICE” as the component name when calling other services

• Please carefully check the provided document on implementation details of the service:

  • The swagger file defines the endpoints to be implemented

    • /routeMessage: this endpoint will do the following:

      • Please note the payload comes in encrypted so the api must decrypt the payload first

      • The service will call the channel activity history service first and get back the activity log ids for the received channel ids

      • Then depending on the channels, it will call the following microservices:

        • SMS Service: should be called if channel name sms (case insensitive) is in the request

        • Email Service: should be called if channel name email (case insensitive) is in the request

        • Cloud Messaging Service: should be called if channel name push_notification (case insensitive) is in the request, since we are not providing cloud messaging service in this challenge, please add a //TODO when the channel is push_notification

      • Note that there can be multiple channels in the request, so this services might be calling multiple of the above-mentioned services

      • Please make the names of these channels configurable so that change them later easily

      • Make sure you are not calling these services using hardcoded urls, do it the same way that the OTP service calls the SMS and Email services

      • The SMS / Email services need some minor updates in this challenge to work properly (see the next section for details)

    • /public_cred and /add_public_cred are the regular endpoints used to establish service trust

  • The pdf defines some stubs that you can use as a reference for your implementation

  • This service doesn’t need any database persistence

• This service doesn’t need any database persistence

• Proper configuration & logging should be implemented

• Should set standard 60 seconds timeout but make it configurable.

• Please use Spring Integrations for channel configurations and routing.

• Please implement factory pattern for redirecting to appropriate channel (see OTP service for reference)

• Provide a docker file for this microservice so we can build it into a docker image

 

Minor Updates to SMS / Email Microservices

• SMS Service

  • The SmsRequest should be updated to have the following parameters

    • activityLogId: long

    • channelId: long

    • parameters: Map<string, string>

      • Please note that the mobileNumber / template fields are all moved to this parameters map

  • After the sms is sent (which is a mock), this service calls the /updateChannelActivity endpoint of the Channel Activity History service with a receipt field (use some dummy value now) and timestamp

• Email Service

  • The MailRequest should be updated to have the following parameters

    • activityLogId: long

    • channelId: long

    • parameters: Map<string, string>

      • Please note that the to / from / subject / template fields are all moved to this parameters map

  • After the email is sent, this service calls the /updateChannelActivity endpoint of the Channel Activity History service with a receipt field (the response from mail server) and timestamp

Final Submission Guidelines

• Full code that covers all the requirements.

• A detailed README file including information on how to configure, run, and verify your application.

• Maven script(s) that at least cover the following:

  • Run the services locally

  • Build each project into separate packages that can be deployed independently

  • Build each project into separate docker images

  • Generate a sitemap for the project using Maven Site Plugin (mvn site)

• Postman collection file to properly test the API (covering positive and negative cases).