Notifications service

Coding

When using IntelliJ IDEA, use the 'default' style. This is matched by checkstyle, which is invoked when running maven.

Multiple API Versions

Notifications might host multiple API versions at the same time. This is done by replacing some calls depending the requested version. The version is part of the URL (as per platform guidelines). When starting a new version, most of the APIs have the same implementation. To make the process of adding a new API version as easy as possible the following strategy is used.

The @Path annotation in each resource is moved to an inner class with the version name. e.g.

@Path("api/notifications/v1.0/endpoints")
class EndpointResource {
   @GET
   public void myPath() {
   }
}

becomes:

class EndpointResource {

    @Path("api/notifications/v1.0/endpoints")
    public static class V1 extends EndpointResource {

    }

    @Path("api/notifications/v2.0/endpoints")
    public static class V2 extends EndpointResource {

    }

   @GET
   public void myPath() {
   }
}

Modify an existing API

Consider we want a new implementation of an API, with different behavior and even params.

class EndpointResource {

    @Path("api/notifications/v1.0/endpoints")
    class V1 extends EndpointResource {

    }

    @Path("api/notifications/v2.0/endpoints")
    class V2 extends EndpointResource {

    }

   @GET
   public void myPath() {
   }

   @POST
   public void myOldPostRequest() {
        // ... do some old stuff
   }
}

We would update it as follow:

class EndpointResource {

    @Path("api/notifications/v1.0/endpoints")
    class V1 extends EndpointResource {
        @POST
       public void myOldPostRequest() {
            // ... do some old stuff
       }
    }

    @Path("api/notifications/v2.0/endpoints")
    class V2 extends EndpointResource {
        @POST
        public List<?> myNewRequest(@QueryParam int coolParam) {
            // ... New API. Different params, different return value
        }
    }

   @GET
   public void myPath() {
   }
}

In this example, we moved the old request of the V1 class and added the new behavior in V2. That’s it!

Enabling the MockServer log during tests

This project uses MockServer to mock external services during the tests execution.

The MockServer log is disabled by default to reduce the noise in the application log. It can be enabled by adding the following argument to the Maven build command:

-Dmockserver.logLevel=WARN|INFO|DEBUG|TRACE

Details about each MockServer log level are available in the MockServer documentation.

Usage of the Clowder Config Source

This project uses the Clowder Config Source from https://github.com/RedHatInsights/clowder-quarkus-config-source. To configure this source to use a different file than /cdappconfig/cdappconfig.json you can use the property clowder.file=/path/to/file.json.

Deploying the backend with data on ephemeral

If you deploy notifications-backend on ephemeral, the database may not contain all the data you need for your tests. It is possible to load data on ephemeral when the backend pod starts, but this is restricted to three kinds of database records: Bundle, Application and EventType.

There are two ways of loading that data, as explained below. Both can be used at the same time as long as the name field is globally unique for each type of database record. If there is no name conflict, the data from both sources will be inserted into the database.

Loading data using a ConfigMap

The notifications-backend ClowdApp template contains an environment variable definition that can be used to load data:

env:
- name: NOTIFICATIONS_EPHEMERAL_DATA
  valueFrom:
    configMapKeyRef:
      name: notifications-ephemeral-data
      key: ephemeral_data.json
      optional: true

If a ConfigMap named notifications-ephemeral-data is created by any of the pods present in the ephemeral namespace, the backend pod will consume that ConfigMap as an environment variable and put the value of the ephemeral_data.json key into the NOTIFICATIONS_EPHEMERAL_DATA environment variable.

Tip	The ConfigMap is optional, it is not a requirement for the notifications-backend pod deployment.

Here is an example of the ConfigMap you could add to your application ClowdApp template:

- apiVersion: v1
  kind: ConfigMap
  metadata:
    name: notifications-ephemeral-data
  data:
    ephemeral_data.json: |
      {
        "bundles": [
          {
            "name": "my-bundle",
            "display_name": "My Bundle",
            "applications": [
              {
                "name": "my-app",
                "display_name": "My Application",
                "event_types": [
                  {
                    "name": "my-event-type",
                    "display_name": "My Event Type",
                    "description": "This is my event type"
                  }
                ]
              }
            ]
          }
        ]
      }

Loading data using the persistent ephemeral_data.json file

You can also load data on ephemeral by creating a pull request that modifies the ephemeral_data.json file which is hosted in this repository. This file may contain ephemeral data from other applications so please be careful not to delete or edit data that would belong to another team.

Here is an example of the data structure allowed in ephemeral_data.json:

{
  "bundles": [
    {
      "name": "my-bundle",
      "display_name": "My Bundle",
      "applications": [
        {
          "name": "my-app",
          "display_name": "My Application",
          "event_types": [
            {
              "name": "my-event-type",
              "display_name": "My Event Type",
              "description": "This is my event type"
            }
          ]
        }
      ]
    }
  ]
}

Generating Jackson Java classes based on JSON requests and responses

For the requests as well as for the responses for querying the IT User Service we can use this online generator to generate the clases by pasting the json files there: https://www.jsonschema2pojo.org/

Updating the Grafana dashboard on prod

While the Grafana dashboard on stage gets updated automatically after merging a PR that changes the dashboard, prod still needs to be updated manually. If you want to update the dashboards on prod after you checked that your changes are working on stage, you need to update the reference in app-interface/data/services/insights/notifications/cicd/ci-int/saas-observability.yml