...
For each mediator to communicate with the OpenHIM-core it will need to be able to talk to the OpenHIM's interfaces. There are 2 3 major interactions the mediators should have with the OpenHIM-core:
...
POST http://<openhim-core_host>:<api_port>/mediatormediators
with a body contain the following sample structure:
| Code Block | ||
|---|---|---|
| ||
{
uuid: "<a UUID>", // A unique identifier to identify the mediator, this identifier should always stay the same even if the mediator changes
version: "", // the version of the mediator, if this is incremented the OpenHIM-core will update the channel configuration - expects a semver string
name: "", // a human readable name for the mediator
host: "", // the hostname or IP address where the mediator can be reached
defaultChannelConfig: {[ // (optional) aan maparray of default channelchannels to add for this mediator
"<channel_name1>": { ... }, // a channel object as defined by the OpenHIM-core
"<channel_name1>": { ... }
}],
routesendpoints: {[ // (optional) a map of routes that represent theA minimum of 1 endpoint must be defined) an array of endpoints that the mediator can be contacted on
"<route_name1>": { ... }, // a route object as defined by OpenHIM-core - https://github.com/jembi/openhim-core-js/blob/master/src/model/channels.coffee#L5-L15
"<route_name2>": { ... }
}]
} |
The OpenHIM-core SHALL respond with a HTTP status of 201 if the mediator registration was successful.
...
The mediator SHOULD return a structured object that indicates the response that should be returned to the user as well as metadata about the actions that were performed. This structured object should be returned in the HTTP response for each request that the OpenHIM-core send to the mediator. This object The mediator MUST return this object with a content-type header with the value: 'application/json+openhim'. If the mediator wants to set a specific content-type to return to the client, they can set this in the response object as a header.
The JSON object returned to the OpenHIM should take the following form:
| Code Block | ||
|---|---|---|
| ||
{
"typestatus": "openhim-response-typeSuccessful", // a static string that contain the response type, this should always contain this string (optional) an indicator of the status of the transaction, this can be one of the following: ['Processing', 'Failed', 'Completed', 'Successful', 'Completed with error(s)']
"response": { ... }, // a response object as defined by OpenHIM-core - https://github.com/jembi/openhim-core-js/blob/master/src/model/transactions.coffee#L13-L18
"orchestrationorchestrations": { ... }, // (optional) an array of orchestration objectobjects as defined by OpenHIM-core - https://github.com/jembi/openhim-core-js/blob/master/src/model/transactions.coffee#L26-L30
"properties": { // (optional) a map of properties that the HIM may want to report
"pro1": "val",
"pro2": "val"
}
} |
...
| Code Block | ||
|---|---|---|
| ||
"metrics": {
"openhim.<channel id>.<route name>.<orchestration name>.num_tx<metric_name>": "62", // for metrics that apply to the entire transaction
"openhim.<channel id>.<route name>.<orchestration name>.<call name>.num_tx<orchestration_name>.<metric_name>": "16", // for metrics that apply to a particular orchestration step, the orchestration_name should reference an orchestration in the orchestrations object
...
} |
Reporting metrics via the metrics service - May be supported in the future
Metrics can also be reported directly to a metrics service if the OpenHIM-core server that the mediator is being deployed on supports this. The metrics service will be a statsd instance so metrics must be reported using statsd UDP messages. The mediator MUST submit metrics using the following naming convention:
"openhim.<channel id>.<route name>.<orchestration name>.num_tx": "62<mediator_uuid>.<endpoint_name>.<metric_name>"
"openhim.<channel id>.<route <mediator_uuid>.<endpoint_name>.<orchestration _name>.<call name>.num_tx": "16<metric_name>"