Using the Event Notification Service

Overview

The Event Notification Service provides automated clients with an MQTT endpoint for notifications of activities within Ivanti Neurons for MDM and Ivanti EPMM.

Messages indicate:

•Device activity, such as registration, check-in, and retirement

•Device state activity, for example, transitions between compliant and non-compliant, and back

•Administrative changes

A variety of out-of-the-box MQTT implementations are available and this manual provides sample client code in the section, Sample client snippet for message subscriber. Messages are JSON objects, and any of the widely-available JSON implementations can de-serialize them. For more information about MQTT, visit http://mqtt.org/documentation.

TLS (Transport Layer Security) is the standard security technology for establishing an encrypted link between a server and a client. This link ensures that all data passed between the web server and browsers remain private and integral. Partner connection and communication with a message broker as a subscriber is TLS secured and encrypted.

Notes:

•MQTT protocol enabled by Ivanti EPMM for CPS events only supports TLS 1.2.

•Ivanti recommends a maximum of fifteen connections per tenant. The best practice is to use a single connection to connect and subscribe to all the required topics from a tenant or Ivanti EPMM.

•Every connection should have a unique MQTT client ID.

•Subscribers (MQTT/TLS clients) need to connect to broker over TLS encrypted port 8883. See Endpoint information for the broker URL to use for your environment.

•For Ivanti EPMM, during backup and restore on a secondary node, any cipher suite and protocol configuration changes for incoming TLS connections from Ivanti EPMM System Manager (MICS) has to be manually replicated on the secondary node because MICS configurations are not synced .

•All MQTT clients maintaining an active subscription when MQTT sends the message receive the message. The system purges the message after delivery, even if the message is consumed by only one active client that acknowledges receipt with a PUBACK command. MQTT delivers messages with QoS level 1, which means the sender can deliver the message more than once until the sender receives a PUBACK command from a receiving client.

•If no active consumers are available at the instant message is published to the messaging server, the message would be retained in the system for a maximum duration of 3 hours before it either gets consumed by a re-connecting durable subscriber or gets evacuated out of the system

Suggested messaging integration workflow

 

1.

Obtain endpoint URLs and a login email address to make a connection. These are provided separately by your Ivanti account representative. You also need a client (identity) certificate. See Authentication and Certificate-based authentication workflows.

2.

Use the Getting event subscription metadata call to get list of available events and topics to which to subscribe.

3.

Edit your login information into the sample client snippet for message subscriber, then execute one of the sample clients. This connects to the messaging system, registers for events, and begins printing message activity to the standard output. See Sample client snippet for message subscriber.

4.

Register a device to generate events that will enable you to test your integration.

5.

Verify that device registration and check-in actions are showing up on your console from your client.