Updated Streaming Data Test Client
I am a Master Principal Cloud Architect for Oracle Cloud (OCI). I create content designed to help developers with Cloud-Based technologies. This includes AWS, OCI, and occasionally Azure. I'm not excluding GCP, I just haven't had any excuse to dive into GCP yet. As far as development is concerned, my area of focus is predominantly .NET, though these days, I do branch out occasionally into NodeJS and Python. I am available for in-person speaking events as well as virtual sessions. I can usually be found at Boston Code Camp. Opinions expressed on my blog are my own, and should not be considered to be the opinions of my employer.
Envisioning the Test Client
A few months ago I started playing around with Oracle Streams and .NET. I wanted to build a sample streaming solution. However like most developers I lacked having multiple devices that I could point at my solution to test.
So… I created a streaming data client to use. The aim was simple, create an ASP.NET web application that could be used to simulate sending of data from a test client to an OCI stream. The design principals were pretty simple:
Support multiple virtual nodes
Support sending a customizable payload
Make it easy to get set up and running
So, I created and released the first cut of my code on GitHub:
https://github.com/BasementProgrammer/StreamingDataClient
Over the last week have been working on upgrading the package, and have make some improvements.

With this web application you can install and run the client in multiple different ways, depending on what suits your environment.
OCI Permissions
Running locally
In order to run the test client locally you will need to have the OCI Command Line installed on your system, and a profile set up to allow connectivity to your tenancy.
You can run the client locally by downloading the source code and opening the project in visual Studio. Set the DataSenderWeb project to be your startup project, and then configure the Appsettings.json file as needed.
{
"DetailedErrors": true,
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning"
}
},
"ProfileName": "DEFAULT",
"vaultId": "",
"StreamId": "",
"EndpointConfiguration": ""
}
ProfileName is the profile you have configured in your OCI CLI configuration file. This will point to your tenancy. Note that the user you are using needs to have permissions to read secret-family and to use Streams in the compartment you are building your application.
Instance Principal Authentication
If you are taking advantage of Resource Principal Authentication, then the profile name will be ignored. You can see how to set up Resource Principal Authentication for a container instance here: https://basementprogrammer.com/resource-principal-authentication-with-oci-container-instances
If you are using Resource Principal Authentication the required permissions are the same as the permissions for your user.
Client configuration
The client can be configured in one of two ways, via the appsettings.json file or by using an OCI Vault in your account. Using the Vault is a better option for running the test client as a container, while using the appsettings.json file is better for running locally.
As of the writing of this blog post, there are two configuration options:
StreamID - The OCID of the OCI Managed Stream that will receive the messages
EndPointConfiguration - The streaming endpoint
Vault Configuration
You can configure the client to retrieve it’s configuration from a vault by either setting the vaultID parameter in the appsettings.json file to the vault’s OCID, or by setting an environment variable “VaultID” to the OCID of the vault. The test client will try the environment variable first, and then if that does not work, it will look for the value in the appsettings.json file.
If the vault OCID is not retrieved, then the test client will fall back to retrieving configuration options from the appsettings.json file.
Your vault needs to be set up with two values:

The required values are found in your stream’s configuration in the console

Local configuration
If you do not want to use an OCI Vault for the configuration options, then you can place the settings in the appsettings.json file. The code includes placeholders for the values.
Interactive configuration
If you do not want to specify the StreamID and the Endpoint configuration in the files, you can update the fields manually when the application is running.
Running the client as a container
The source code for the project includes a docker file that can be used to build the application as a docker image and then publish it to your local repo. The website is exposed on port 8080 when you do so. Keep in mind that if you are running the client as a Container Instance in OCI, you will want to set up Resource Principal Authentication with access to both your vaults and Streams. You will also want to set your vault ID as an environment variable.

I am currently running the container in debug mode, thus the ASPNETCORE_ENVIRONMENT option as well. You should NOT use this option when you deploy the application.

You can copy the container’s address and browse to port 8080.

Summary
The streaming data test client is now easier than ever to deploy and use for your streaming data projects. You can use multiple different configuration options to get the client deployed and configured including Resource Principal Authentication.
The updated code is available on Github.com/BasementProgrammer
Happy Streaming!

