MI Core 10.x introduced the Event Notification Service. In doing so, the MI Core makes events available on the secure port 8883 via the MQTT protocol.
These events are retrieved by a MIDA server (ENS Broker) and stored in the MIDA database. All conencted MIDA servers processes this table to retrieve the changed device data from the MI Core, store it in the MIDA DB and thus make it available in MIDA.
Advantage: MIDA no longer must query all devices, but only those where there is a change.
Setup
- An Admin user with the role CPS must be created. The User Portal role is not required.
- The MI Core must be accessible from all MIDA servers via port 8883 (firewall and Load Balancers).
- ENS must be activated on the MI Core as follows
Putty on MI Core
<MI Core User> + password
enable + password
„configure terminal “
„activemq“ - The Tomcat of the MI Core then performs a reboot. On a StandBy MI Core this service must also be activated manually.
- Configuration of the ENS service in MIDA >Settings > Core > Configure ENS
The status of the ENS Service can be checked by the command: systemctl status activcemq
ENS can be disabled on the MI core with the command: no activemq
The MI Core holds the ENS events for 3 hours. If these events are not picked up by an ENS broker, the events are discarded.
Procedure
- The MI core provides the events on port 8883.
- MIDA retrieves the events and stores them in the MIDA database.
- The MI Core receives a PUBACK message for this event from MIDA and thus removes the event.
- If an event is included for the same device and event type, it will not be included in the table to avoid too many events.
- All four MIDA servers process the events in the table successively.
Additional notes:
If ENS is not available for more than 3 hours, events like registration of a new device will not be recorded. This means that the device will not be transferred to MIDA. However, if the device registers later during a check-in at the core and the check-in event is transferred to MIDA via ENS, the device is created in MIDA and in MIDA.
Establishment ENS
The setup of ENS is done via Settings > Cores > click on the status information and click on „Configure ENS Service“.
Switch „Enable ENS“ from OFF to ON:
The following screen will then be displayed:
ENS status and ENS connection established show an X.
The ENS settings for the core are located under the general ENS settings:
The following values must be entered here:
- Username of the ENS user on the MI Core
- User password
- Host: ssl://<URL of MI Core>
Example: ssl://emm-mi-core.com - Time limit for the delay (in seconds)
- Delay for the reconnection attempt (in milliseconds)
- Number of connection attempts
Explanation of the values:
- Time limit for the delay (in seconds)
- MIDA is waiting this time for a response from MI Core
Delay for the reconnection attempt (in milliseconds).
After this time MIDA tries to reconnect to the ENS port of the MI Core.
60000 = one minute
Number of connection attempts
Number of attempts MIDA tries to reach the MI Core.
Subsequently, MIDA no longer attempts to establish a connection.
The connection must be established manually in MIDA again.
Click save
After saving, the connection setup is shown:
By default, all ENS event types are subscribed.
Each Event Topic can be deselected.
It is recommended to deselect the following topics:
- device/cert_inventory
- device/profile_inventory
- device/report_initialized
These three event types are not processed by MIDA.
When deselecting a topic, a confirmation window follows:
Hint:
If ENS is deactivated and reactivated in MIDA, all event types will be reactivated. Afterwards, the three event types should be deactivated again with ENS.
The „Device Import & Synchronization“ sync tasks become obsolete.
To disable, open „Configure Workers“, and under „Devices Import & Synchronization“.
Reduction of ENS events (process point 4)
A very large number of events are expected to be received by MIDA.
~50000 devices check in every four hours. That’s about 300,000 events per day.
MIDA can process about 70,000 with four MIDA instances.
To reduce the number of events, the following function has been implemented.
The MIDA Leader receives an event. Before saving in the table, MIDA checks if there is already an event for this device and this event type in the database already. If such an entry is found in the database, that event is discarded.
Description of the MIDA Components for ENS:
ENS Broker:
The ENS Broker is the MIDA server that keeps the connection to the MI Core, retrieves the ENS events from the MI Core and stores them in the MIDA database.
Node name:
This is the MIDA server on whose server the MIDA UI is currently open.
Configuration parameters:
ENS Event retention:
| Parameter | Standard | Description |
| mida.event.janitor.interval | 3600000 =1 hour |
How often should the Janitor ENS Events run and remove events from the MIDA table? By default, the events are removed from the ens_events table that have the status PROCESSED.
and are older than 3 hours(or mida.event.retention.time). Others are retained |
| mida.event.janitor.delay | 20000 =20 sec | How long after MIDA startup should the first run be? |
| mida.event.retention.time | 10,800,000 = 3 hours | How long should events be stored? |
| mida.event.janitor.clearEvents | PROCESSED | Which processing statuses are automatically removed by the janitor. Comma separated list. Possible values: PROCESSED, PROCESSING,FAILED, UNPROCESSED |
| mida.cluster.nodeName | Here you can define the name for a node (MIDA Server).
Without the parameter a cryptic ID is used. |
|
| mida.cluster.reelection.interval | 60000 | How often is a new ENS Leader selected? |
| mida.cluster.reelection.delay | 5000 | Delay of the task after MIDA restart |
| mida.ens.reelectionConnection.interval | 3000 | Each note checks the entry lastUpdated and last_leader_updated in the table [dbo].[leader_election]. If the two values have a difference of more than 3 seconds, a new leader is determined. |
| mida.ens.reelectionConnection.delay | 5000 | Delay of the task after MIDA restart |
| mida.ens.eventCleanup.interval | 1800000 | ENS events older than 3 hours and events with the status PROCESSING are converted to UNPROCESSED and processed again later on. |
| mida.ens.eventCleanup.delay | 5000 | Delay of the task after MIDA restart |
| mida.ens.compliantHandler.delay | 60000 | Delay for testing Non Compliant / Compliant devices on the MI Core. |
| mida.ens.eventsPriority (from ebf mida iso version 2.8.6) | Adjustment of priorities of event types.
The events ENS_ENABLED, ENS_DISABLED, ENS_RECONNECT, ENS_SUBSCRIBE must ALWAYS have the highest priority of all events, otherwise the ENS system is blocked! Possible values: (default priority): ENS_ENABLED (100), ENS_DISABLED (100), ENS_RECONNECT (100), ENS_SUBSCRIBE (95), ENS_UNSUBSCRIBE (95), ENS_CHECK_CONNECTION (90), DEVICE_ENROLLED (0), DEVICE_CHECK_IN (0), DEVICE_NOT_COMPLIANT (0), DEVICE_COMPLIANT (0), DEVICE_RETIRED (0), DEVICE_APP_INVENTORY (0), DEVICE_CERT_INVENTORY (0), DEVICE_PROFILE_INVENTORY (0), DEVICE_WIPED (0), DEVICE_REPORT_INITIALIZED (0)
Example: mida.ens.eventsPriority={DEVICE_ENROLLED:80,DEVICE_NOT_COMPLIANT:80,DEVICE_COMPLIANT:80,DEVICE_RETIRED:80} This is used to process the events that are important for the administrators earlier. The DEVICE_ events must not be given a priority higher than 89 in order not to endanger the operation. Unlisted events retain their default priority. |
| ENS Process Parameters Parameter |
Standard | Description |
| mida.event.monitor.interval | 5000 (5 seconds) | How often does a MIDA server search for a new event (the oldest event) in the MIDA event table? |