Integration with Apollo driver
Ronda senior X has integration with the driver from the manufacturer Apollo, which can be used on devices registered in the system. This page details specifications about how this driver works, it's configurations and what system resources are attended by it.
Apollo driver operation
Installation and configuration of the driver
Apollo driver must be installed on client so the integration with devices which use Apollo happen successfully. The driver monitors communication (online or offline) with all devices connected to it, sends them data and information, and carries out the necessary procedures for their integration with the system.
To obtain the Apollo driver, register on the login screen.drivers and select the item "Apollo" in the fieldDriver type. Then, to download it, access the screenDownloads. Once the driver is unzipped, it can be started and stopped with the start-service.bat and stop-service.bat files, respectively.
The configuration of the driver is made in the config.properties file, which is in the directory where the driver was unzipped. This file can also be obtained by clicking the Download configuration file button of the driver screen. The file has the default settings already filled in, but if it is necessary to change any of its fields, use a text editor (Notepad, for example) to open it.
Fields in the config.properties file
- sdk.host: access address to Ronda senior X followed by the port and other parameters.
- sdk.api_key: token generated for this driver on the driver registration screen.
- sdk.connection.timeout: maximum time, in milliseconds, for which the Apollo driver will wait for a card's response before considering it offline.
- sdk.request.timeout: time interval, in milliseconds, in which the Apollo driver will search for events on each board.
These settings are sent to devices when the Apollo driver is started and when the command"Configure device" is sent to the system.
Information of people, ID cards, locations and access permissions are sent to the device whenever this date is included, whenever this date is included, changed or deleted. Here, "access permissions" correspond to everything that defines whether a person can perform an access event in a device: roles, levels, timeslots and so on. Only non-blocked people who have access granted in the device will be sent.
When sending these information and configurations to the devices, if the communication is offline, these data will be sent as soon as the communication is restored.
Log generation
The procedures performed by the Apollo driver are registered in log files, which can be accessed inside the folder where the driver is installed. Each log message has a classification among the following:
- FATAL: messages that prevent the application from working, forcing the service or executable to be restarted;
- ERROR: application malfunction messages, which must be analyzed by the Senior tech team, however the service or the executable continues working;
- WARN: messages which indicate failure in system registries or configurations. They must be analyzed by the system administrator;
- INFO: messages related to the normal operation of the system (for example: events received, pendencies sent, etc.) for informative effects;
- DEBUG: messages related to the internal operation of system components (for example: timer started, parameters read, etc.) with informative effects to the Senior tech team. This log level must only be enabled in case there are environment issues;
- TRACE: messages of internal operation of system components, with details of the data which is being treated.
Miscellaneous information about this integration
Validations made by the Apollo driver
| Validation | Situation |
|---|---|
| Access credential | OK |
| Location timeslot | OK |
| Level control | OK |
| Antipassback control | OK |
| Authorized role (in locations that control role) | OK |
| Role suspension | OK |
| Role timeslot | Not used |
| Number of group vacancies | Not used |
| Request pending authorization | Not used |
| Authorizer by location | Not used |
| Authorizer by role | Not used |
| Capacity (in locations that control vacancy) | Not used |
Access validations are already made in the devices - in other words, based on the information that was sent to the device and is in them, and not on the information registered in the system, which may not be on the devices yet.
Relationship between Apollo and Ronda senior X features
Apollo devices have certain standard names for their features. As Ronda senior X has equivalent resources with different names, the table below lists these terms to facilitate your understanding:
| Apollo | Senior round |
|---|---|
| Access level | Role |
| Time zone | Location timeslot |
| Area control | Physical Location |
Identified limitations
AAN boards have a limit of data that can be related to them. Each board can have:
- Up to 124 different time zones (location timeslots) registered, each one containing up to six timeslots.
- Up to 254 different access levels (roles) registered, each one containing up to 96 readers related to it.
- Up to 100 holidays.
- Up to 255 permissions.
Other limitations found:
- A card associated to the board can have up to 37 access levels (roles). In other words, a person registered in Ronda senior X whose registration will be used on Apollo boards can have up to 37 different roles.
- When including a card in the board, the identifier of the person's current location must be sent. This information is limited to 96 different locations, as this is the maximum quantity of readers that a board can have.
- Apollo boards support cards of the Magnetic (1 or 2 error digits) and Wiegand formats. Currently, Ronda senior X only uses the Wiegand format.
- Up to 8 Wiegand formats, 8 Magnetic formats with 1 error digits and 8 Magnetic formats with 2 error digits can be registered in the board.
Note
The permissions must be configured at senior X Platform > Technology > Administration > Authorization > Role Management.
