
6_API INTRODUCTION
OJMAR 79
The API needs a valid license provided by Ojmar to work, this license activates the
API.
3rd party SW will make REST calls to the API functions via http protocol. The call
information will be exchange using a JSON structure (See point examples below in
this document).
The API allows to the 3rd party SW to operate in a programmatic way with the locks
and the peripherals.
The API is divided in two three parts:
1.
Datamodel API
: Permits the interpretation of the obtained information of the
locks and cards independently of the version of lock that operates in the facility.
This part of the API works as a parser, so, it is able to encrypt/decrypt the
information of the card/lock. These functions are the ones defined in point 3 in
the RFID part.
(Communications are encrypted due to security reasons).
2.
Recorders’ API
: The API implements the communication with both
peripherals, including functions to write and read cards and all the NFC
programmer functions.
3.
Socket API
: The API implements a mechanism based on sockets to receive
information from the locks and to send answers back to them.
In order to work properly with the API, firstly a frame must be created using the
Datamodel API (at the end, it is like a translation from human language to lock
language), and after that, it is decided where to send that information (Desktop
reader or NFC reader).
This has been implemented in such a way, to avoid reader monopolization, letting
to the 3rd party SW to use their own RFID reader writer or the option to use Ojmar's
programmer for their own application.
6.3.1
Online Communications
The Nexo NLX1 locks have the ability to work online in a wireless network and
communicate with the API. This way the 3rd party SW can receive state information
in real time from the locks and determine whether a card should be able to operate
with a lock in each situation.
This scenario presents an asynchronous communication where the connection can
be started by the lock in any moment.
To make possible this decision delegation the 3rd party SW needs to publish a
service for the API to query when a request is received. For that purpose, the API
expects a TCP socket to be listening to the machine in a configurable port. The 3rd
party SW is responsible to open this socket and implement the protocol to
communicate with the online system of the API.
For each connection, the API will forward the information received from the lock
translated to JSON format and the 3rd party SW will respond with another JSON.
Summary of Contents for Nexo NLX1
Page 1: ...E S P INSTRUCTIONS MANUAL VERSION 2 0 NEXO NLX1 SYSTEM...
Page 2: ......
Page 3: ...INSTRUCTIONS MANUAL VERSION 1 0 NEXO NLX1 SYSTEM...
Page 7: ...CONTENTSOJMAR 7 PAGE LEFT BLANK INTENTIONALLY...
Page 39: ...2_MANUAL DE INSTALACI N OJMAR 39 PAGE LEFT BLANK INTENTIONALLY...
Page 57: ...3_PUESTA EN MARCHA OJMAR 57 PAGE LEFT BLANK INTENTIONALLY...
Page 62: ...5_MANUAL DE MANTENIMIENTO 1 2 3 User key master or service 4...
Page 70: ...5_MANUAL DE MANTENIMIENTO...
Page 74: ...5_MANUAL DE MANTENIMIENTO PAGE LEFT BLANK INTENTIONALLY...
Page 150: ...7_API REFERENCE MANUAL options BT group 1 range_from 1 range_to 100...
Page 184: ...7_API REFERENCE MANUAL PAGE LEFT BLANK INTENTIONALLY...
Page 186: ...7_API REFERENCE MANUAL Option b...
Page 187: ...7_API REFERENCE MANUAL OJMAR 187 Option c INSTALLING ONE ROUTER PER 50 LOCKS IS RECOMMENDED...
Page 188: ...7_API REFERENCE MANUAL...