Additional Exercises

This tutorial has covered a lot of territory about how we implement our services in a very directed way. So that you can go through the process on your own, add the following capabilities to your service, using your existing implementation as a guide and building on what you have already done:

  • Define a new endpoint, /identifier/{id}, that has POST and GET calls.

  • For the POST:

    • Pass in a request object containing a value to associate with the id request parameter.

    • Check to see if the id/value pair is in the session cache:

      • If the id is in the session cache, AND the value matches the posted value, return a 200 OK status (do nothing).

      • If the id is not in the session cache, OR if the id exists but the value is different, store the id/value pair in the starter database and update the session cache with the updated id/value.

You should utilize user-session-service for caching and the existing database operations already implemented, with id persisted as the key

  • For the GET:

    • Check to see if there is a value in the session cache for the id

      • If it exists, return the value for the id from the session cache

      • If it does not exist, try to retrieve it from the database.

        • If it exists, retrieve it from the database, set it in the cache, and return the value

        • If it does not exist in the database, throw an exception

For this endpoint, you should make the following updates:

  • Update the swagger contract with the new endpoints.

  • Implement corresponding resource class/method(s) and service(s) to support the new functionality.

  • Add a query parameter to use session cache - if true, perform cache checks as detailed above; if false, only store to/retrieve from the database.

  • Add a new exception for the exception thrown if the id does not exist in the database.

  • Secure the endpoints in the following way:

    • Only STAFF users may perform the POST

    • STAFF and VETERAN users may perform the GET

      Review the Enforcing RBAC (Role) Restrictions section of the v1-migration-guide in the mobile-framework documentation (branch Release/2.4) for guidance on securing multiple possible roles.

    • Resource restrict both POST and GET calls

  • Update the service version number to 1.1.0 in the service and db poms.

  • Update the client version number to 1.1, making sure to update the property in the service pom that defines the client version.

  • Make the following dependency updates:

    • Update the mobile-service-parent, mobile-openapi-client-parent and mobile-java-parent to the latest patch versions.

    • Update the ngss-maven-tiles.version property to the latest released version.

    • Update the dependencies added to kubernetes/dev-with-dependencies/kustomization.yaml to the latest released versions, as well as any corresponding pom properties (for example, any client versions defined in the service pom).

      Use the service-lint tool (https://coderepo.mobilehealth.va.gov/scm/dhsss/service-lint.git) to determine the latest versions of service dependencies. Once you’ve cloned the repository, review the service-lint-cli README.md for information about building and using service-lint from the command line. You can review the rules applied by service-lint here.

  • Add CHANGELOG entries for both v1.0.0 and v1.1.0. Review the changelog from location-service for guidance on the appropriate format. Include entries for the updated parent and tiles artifacts, as well as any updated pom property values.

  • Add integration tests for the endpoints that maintain the service’s configured thresholds of 80% line and branch coverage

  • Add all service endpoints to the table under the Logical Interactions section of the service’s SRVDD.md file, making sure to include the new endpoints with their HTTP methods, paths, descriptions, request/response types, security roles, and any other relevant information. Review the SRVDD from location-service for guidance on the appropriate format.

Review / Acceptance

Make sure all of your changes have been added and committed to git before initiating your review.

When you have completed the above implementation, work with the Onboarding team to review your complete starter project. This review will be informal and will focus on ensuring that you understand our development process and the tools we use to perform our work. Questions and open discussion are encouraged; this is your opportunity to get answers and provide feedback.