laa-crime-applications-adaptor

This is a Java 17 based Spring Boot application hosted on MOJ Cloud Platform.

Obtaining environment variables for running locally

To run the app locally, you will need to download the appropriate environment variables from the team vault in 1Password. These environment variables are stored as a .env file, which docker-compose uses when starting up the service. If you don't see the team vault, speak to your tech lead to get access.

To begin with, make sure that you have the 1Password CLI installed:

op --version

If the command is not found, follow the steps on the 1Password developer docs to get the CLI set-up.

Once you're ready to run the application:

./start-local.sh

Application Set up

Clone Repository

git clone git@github.com:ministryofjustice/laa-crime-applications-adaptor.git

cd crime-applications-adaptor

Make sure all tests are passed by running following ‘gradle’ Command

./gradlew clean application:test

When running the application locally you will likely want to disable OAuth request authorisation, this can be done by replacing the SecurityFilterChain implementation with:

http.authorizeHttpRequests(authorizeRequests -> authorizeRequests.anyRequest()
.permitAll());

return http.build();

You will need to build the artifacts for the source code, using gradle.

./gradlew clean application:build

./start-local.sh

laa-crime-applications-adaptor application will be running on http://localhost:8088

Metrics and Health Check endpoints

There are a number of out of the box endpoints provided by Spring Boot for verifying application health and various metrics, some of which are enabled and accessible.

These endpoints include:

• http://localhost:8099/actuator
• http://localhost:8099/actuator/prometheus
• http://localhost:8099/actuator/health
• http://localhost:8099/actuator/info
• http://localhost:8099/actuator/metrics
• http://localhost:8088/api-docs (generated by springdoc-openapi-starter-webmvc-ui with URL path defined in application.yaml by springdoc.api-docs.path: /api-docs)

For a complete list of all out of the box actuator endpoints see Spring Boot 3.1.5 - Actuator.

Debugging in IntelliJ

If you are using IntelliJ, you can do the following to run the debugger when running the application using docker:

• In IntelliJ, go to 'Run Configurations' and add a new 'Remote JVM Debug' configuration.
• Give it a name, set the host to localhost and the port to 8183. Set 'Use module classpath' to crime-applications-adaptor. Hit 'OK' to save your changes.
• Run the application using docker-compose up. When it has started, you can select the debugger in IntelliJ at the top right and hit run.

Functional API Tests

The project has been split into two sub module, application and api-tests. api-tests has been added to hold API tests written use Serenity, Cucumber and RestAssured. These tests are designed to be run against a deployed version of the application in DEV or TEST. They will be run automatically as part of the gradle build unless the application module is specified.

For example:

// This command will build and test both modules
./gradlew clean build

// This command will run only the application module tests
./gradlew application:test

// This command will run only the api-tests tests
./gradlew api-tests:test

Test Configuration

The functional tests use Apache Commons Configuration2 to read the config.properties file and provide environment variable substitution. This is designed for use on the CI/CD pipeline where secrets will be injected by environment variable. When running locally create a copy of the properties file and name is local.config.properties and populate it with the required values. This file is included in the .gitignore to avoid accidental commits. The trigger for using the config.properties is the presence of the CHART_NAME environment variable which indicates that the tests is being deployed and run via helm.

Running the API Tests

The API tests can be run through IntelliJ or using the following gradle command.

./gradlew api-tests:test

The test can also in run in the same manner as the CI/CD pipeline using the docker compose. In order to do this you will need to create a .env file alongside the docker-compose.api-tests.yaml file and populate it will the required parameters and then run the following command.

cd crime-applications-adaptor
docker-compose --file ./docker-compose.api-tests.yaml up --build

Example .env contents:

CAM_BASE_URL=https://laa-crime-apply-mock-api-<ENV>.apps.live.cloud-platform.service.justice.gov.uk/
CAM_JWT_SECRET=<INSERT>
CAM_JWT_ISSUER=maat-adapter-<ENV>
CAA_BASE_URL=https://laa-crime-applications-adaptor-<ENV>.apps.live.cloud-platform.service.justice.gov.uk
CAA_OAUTH_BASE_URL=https://caa-api-<ENV>.auth.eu-west-2.amazoncognito.com/
CAA_OAUTH_TOKEN_URI=oauth2/token
CAA_OAUTH_CLIENT_ID=<INSERT>
CAA_OAUTH_CLIENT_SECRET=<INSERT>
MAAT_CD_BASE_URL=https://maat-cd-api.<ENV>.legalservices.gov.uk/
MAAT_CD_AUTH_BASE_URL=https://maat-cd-api-<ENV>.auth.eu-west-2.amazoncognito.com/
MAAT_CD_AUTH_CAA_CLIENT_ID=<INSERT>
MAAT_CD_AUTH_CAA_CLIENT_SECRET=<INSERT>
MAAT_CD_AUTH_TOKEN_URI=oauth2/token
CHART_NAME=laa-caa-api-tests

Code Formatting

This project has been set up to use the Spotless Gradle pluging to detect and fix code formatting issues. The plugin will run as part fo the ./gradlew clean build task and corrections can be applied using the ./gradlew spotlessApply task. For more information see the confleunce page here.