The DMaaP Mediator Producer provides Information Coordinator jobs that pushes messages from DMaaP Message Router to data consumers.
The producer is configured with environment variables. The ones defining the host of the supervision and job info callbacks are required to set before starting the producer. All other variables have default values.
DMaaP Message Router (MR) forces the user to poll a specific topic. Examples of topics are faults and metrics. So the decision has been made for a mediator job to provide messages for a specific topic. The first job to be provided will push messages from the fault topic.
A discussion was held around wether a job should provide the possibility to filter the messages pushedor not. Though it would be a nice feature, it was decided that this should not be provided in the inital version. Later a number of different filtering solutions, more or less generic, can be considered and introduced if wanted.
The first job will have the following schema:
{
"$schema": "https://json-schema.org/draft/2019-09/schema",
"title": "STD_Fault_Messages",
"description": "Schema for Job delivering fault messages from DMaaP Message Router",
"type": "object",
"properties":{}
}It was also decided that the implementation shall be done using the Go language and code should reside int the "nonrtric" repo.
The producer has a folder called "configs" that contains files whose file name is the job type name, and extension ".json", and content is the job definition schema. The producer takes all these files and register a type in the Information Coordinator for each of them. Should, for any reason, not all types be possible to register, the producer will exit and log the cause of the failure.
The producer builds up a slice of all supported types during the type registration. This info and the callback URLs provided as environment variables during startup are then used to register the producer in the Information Coordinator. Should, for any reason, the registration fail, the producer will exit and log the cause of the failure. It will also exit if the callback URLs are not provided in enverinment variables at startup.
Server handler for status supervision only replies to "GET" method at the "empty" path. All other calls will return "404 NotFound".