Learn About Configuring Application Notifications

With a subscription that can display the content sent through, we can focus on building the application to create notifications rather than only using OCI Events.

There are many ways to test client notification generation. For this demo, you can exploit an open-source log simulator tool, built initially just for simulating log events but meets the requirements nicely. The other option is to use a simple Java / Groovy application here (the latter derived and simplified from the former). The code development has been implemented with Groovy, as it makes it quick and easy to run and modify. However, the code is Java compliant, so if you prefer, a Java build process can be established, or the code modified to utilize the Java shebang feature. For the rest of this article, we’ll assume the use of Groovy.

Configure the Required Setup

Some third-party apps are required to be installed and configured.

Java needs to be installed (version 8 or later) along with Groovy (version 3 or later). The OCI Java SDK needs to be downloaded and copied into the same folder as the Groovy script. When setting up Java and Groovy, ensure they can be seen in your PATH environment variable.

With everything downloaded, we need to complete some configuration information to connect to OCI and send messages to the correct Notifications topic. The first piece is to create a configuration file that the SDK can use to connect and authenticate with OCI (for simplicity, we recommend putting it in the same directory that will be used to run the Groovy script with the name oci.properties). As a result, you should have something looking like this:

[DEFAULT]
user=ocid1.user.oc1..aaaaaaaajbbbbbbbbbccccccccccccdddddddddddddd
fingerprint=aa:bb:cc:dd:ee:11:22:33:44:55:66:77:1a:1b:1c:1d
tenancy=ocid1.tenancy.oc1..aaaaaaaajjjjjjkkkkkkkkklllllllmmmmmmmnnn
region=us-ashburn-1
key_file=~/mykey.pem

When setting up the key file, remember to ensure the file privileges are correct; otherwise, the file will be rejected as too insecure during the connection process.

The next piece of configuration is for our client application, so it knows which topic to communicate with. This is done by creating the following environmental variables (use the command set for Windows and the command export for Linux):

TOPICOCID=ocid1.onstopic.oc1.iad.oooooooooopppppppppppppqqqqqqqqqqrrrrrrrrssss
OCICONFIGFILE=oci.properties
REGION=us-ashburn-1
CLASSPATH=./lib/*

The topic OCID provided is the OCID for the topic that we previously created. The OCICONFIGFILE is passed into the SDK as part of the initialization process. The CLASSPATH is needed by Groovy and Java to find the SDK lib folder. We provide the REGION again because authentication and topic configuration regions could differ.

Run the Client

With everything configured now we can run our test client.

Use the command:

groovy CustomOCINotificationsOutputter.groovy

We should now see notifications being sent from our client to the Notifications topic, which will send the messages on to our Slack channel.

About Our Client

Our client code has been commented, but let’s quickly run through how it works.

The Groovy code contains a single class with a main method that initializes an instance of the OCINotificationsOutputter class and then initializes the object instance. This initialization creates an SDK client object for sending notifications to OCI.

Once the basic connectivity is readied, the main method then goes into an infinite loop of sending a text string to the Notifications object. This is added to a batch of outputs. As we have hardwired this output to 1 in size, it will immediately construct a message using the SDK static factory methods, and invoke, via the SDK, to the relevant OCI API. We then sleep for five seconds. Both the SDK client and the creation of the OCI Notifications object make heavy use of the Builder design pattern.