CoB Architecture

The overall CoB solution architecture is made up of various "blocks" that work together, allowing a complex but highly efficient execution to be guaranteed for each new application created.

The following image is an illustration of the various parts of this architecture, and how the different aspects of the overall solution are all connected.

The application itself, once deployed, is accessed through a web browser, regardless of the type of device used - desktop computer, laptop, etc...

Generally speaking, there are two internal services/processes running on the machines: RecordM and DeviceM.

RecordM stands for Record Manager, and it is through this internal server that instances and all other aspects related to information management and organization are created and managed.

DeviceM, similarly to RecordM, stands for Device Manager. While RecordM manages information records, DeviceM is used to create and manage "devices", storing their data and other useful aspects related to these devices.

There are also a few ancillary services that act as intermediaries: UserM, IntegrationM and LogM. These services are vital for the functioning of the entire application.

UserM, or User Manager, is responsible for adding and managing all users of the solution. LogM, or Log Manager, generates logs of all events that are happening in the application, such as the creation of instances and devices. Finally, IntegrationM, or Integration Manager, is responsible for executing scripts in certain situations, such as when instances are created. This aspect is explored in greater detail in this article.

Here is a set of features common to all of the internal components of the CoB architecture we just mentioned:

• All of them use the MySQL database management system for storing and managing data. In addition, all of them - with the exception of IntegrationM - are able to persist data for later retrieval.
• They all use a BUS messaging queue provided by HornetQ to communicate between each other, sending and receiving messages. For example, whenever RecordM creates an instance, a message is sent to HornetQ and relayed to all services, even though the message is only needed by to a few of them.
• All of them have an ElasticSearch client installed, and all the relevant data they generate is indexed in a common ElasticSearch database. They all also exchange data indexed by ElasticSearch between each other and have a varied number of nodes(?), so the more complicated clients can have more nodes and processing power when necessary.

Other components of the CoB architecture included in the above image but that have not been mentioned yet:

• NGINX is used to redirect the REST requests made by cients to the relevant internal server, such as /recordMor /deviceM, depending on the layout of the URL.
• Kibana is an external product, which is used to generate reports and visualization panels on top of the ElasticSearch part of the architecture.
• Last but not the least is the RecordM importer. This service is responsible for everything related to the importing of data from external sources, such as Excel spreadsheets and any others.