Queue Channel

In case of queue channels iHub accepts incoming messages from RabbitMQ queue. Each external monitoring systems is expected to send the alerts in project specific exchange with proper routing key.

In case of project specific channels, each project will have an ihub inbound exchange and each channel will have its own queue to accept input request. Ihub creates the project specific exchange and the channel specific queue while creating the first queue channel for a project. The routing key for that channel will be same name as of the queue name. In case of project specific channels, the exchange and queue follow the below naming conventions.

Exchange -> orgId.projectId.projectName.exchange

Queue -> orgId.projectId.channelName.queue

In case of generic channels there will be one exchange with the below naming pattern and each channel will have its own queues which will be bounded to the generic exchange with routing key as queue name. In case of generic channels, the exchange and queue follow the below naming conventions.

Exchange -> orgId.iHub.inbound.exchange

Queue -> orgId.iHub.channelName.queue

Similarly, while deleting a queue channel from a project its associated queue and bindings from exchange will get deleted automatically. If the deleting channel is the last queue channel of that project along with the queue, the exchange also will get deleted.

IHub Inbound Queue Creation

The installation engineer can create queue channels by using channel configuration user interfaces which is available in Channel Configuration section of SmartOps create project UI.

To access IHUB Queue channel, perform the following steps:

Access SmartOps application.
Select IHUB from the menu as shown in Figure:
Click to add a channel. Enter the details as explained below:

Channel Name : Any Alphanumeric value

Channel Type : Select as QUEUE

Request Received time (check box): If this is enabled, IHUB will include an extra field named ‘requestReceivedTime’ inside senseParams map of Smartops json. And its value will be the request received time in UTC. The time will be in a format given in the Timezone Format field which is shown near to the checkbox.

Process request as list: If this is enabled, iHub will not split multiple requests that are coming in ihub as single requests. Rather iHub will include all the requests in a single json array. And this json array will be set inside requestJson -> inputs field of SmartOps json.

Json Mappings:

Json mappings has two sections – shift and default.

In the shift section input to SmartOps output field mappings should be given. For example, if in the incoming request there is a field named alertDescription which should be mapped as alertMessage field inside senseParams map of SmartOps json the key in shift section of json mappings filed should be given as “alertDescrition” and value should be given as senseParams.alertMessage.

The user can add any number of mappings by clicking add button on the top right corner of each of the mapping section.

Apart from the fields that are in input json if the user wants to add an extra field with a default value in output SmartOps json it can be given in default section. For example if a user wants to add automationStroy field in SmartOps json with default value “story123” in the default section the key should be given as “automationStroy” and value should be given as “story123”. If user wants to add a field named “source” inside senseParams map of SmartOps json the key in default section should be given as “senseParams.source” and value should be the required value.

An example mapping for a simple Json is given below.

An example mapping for a complex json with inner objects is given below. Each of the inner fields should be sepaRDZrated by “/” symbol.

Note: In the resulting SmartOps json two extra fields, ie, projectId and organizationId will be added by default.

See Also:

Defining Channel Configuration - Queue

Related Topics: