Aprender CoB

# Breaking Down the Steps Behind the Creation of an Instance

Execution

To understand how the different building blocks of the CoB Architecture work together, we will now present an in-depth step by step execution trace behind the creation of an instance.

  1. POST to /recordm/recordm/instances - this initial request is handled by NGINX. In order to know which internal server to send the request to, NGINX uses the first part of the URL - /recordm. In this case, the internal server is RecordM.

  2. POST to /recordm/instances - next, the request is received by the internal server.

  3. Then, the instance is added to the MySQL database of the relevant internal server by way of a INSERT INTO statement.

  4. The instance is then indexed into the ElasticSearch database.

TIP

While MySQL is only used for data storage, ElasticSearch, on the other hand, is used in all queries. This is because ElasticSearch guarantees that the query results will always be fast.

  1. Two messages are then sent to HornetQ: instance created and log: instance created. These will then be relayed by HornetQ to all internal services. While HornetQ sends these messages to all services, each of the two have an intended destination and will be received by different internal services: IntegrationM and LogM.

  2. LogM and IntegrationM receive the instance created message sent by HornetQ:

    • For logging purposes, LogM receives the message containing the log prefix as well as all the information about the creation of the instance, such as the name of the user account who created the instance, the exact date of its creation, data about the instance itself, etc.
    • The other message, informing of the creation of an instance, is received by IntegrationM. This is a very important part of the execution trace, since the IntegrationM server contains an internal directory named scripts - integrationM/scripts -, where several Groovy scripts are stored. These scripts are executed each time a message is received by the IntegrationM internal server.

TIP

Because IntegrationM is continuously receiving messages, there is a system in place that guarantees that each message is handled by the Groovy scripts in a very quick way: For each script, in the first few lines of code there is a method that checks whether or not the received message is relevant or not to the script, and if more steps need to be taken. If the message is considered relevant, the script continues running. If not, the script is immediately aborted. This ensures minimal waste time while the message is being handled.

  1. POST /cpes to DeviceM - In this particular example, when the message informing that a new instance has been created is received by IntegrationM, the system needs to create a CPE - Customer Premises Equipment - device in response. What this means is that there is a POST request made to the DeviceM internal server, which then creates an instance in DeviceM representing that CPE.

  2. Next, the CPE is added to the MySQL database of the relevant internal server by way of a INSERT INTO statement.

  3. After that, the CPE is indexed into the ElasticSearch Database.

  4. DeviceM sends a log: cpe created message to HornetQ.

TIP

Although - as we can see in the 8th, 9th, and 10th steps - the process behind the creation of a new CPE device by DeviceM shares many similarities with the execution trace behind the initial creation of an instance, in the case of a CPE device there is no cpe created message being sent to HornetQ to be received by IntegrationM, This is due to the fact that we do not want any scripts to be executed following the creation of the device. In any case, in step 10 we can see that a message is also being sent to LogM. This message contains information about the creation of devices and instances to be stored in the system logs.

  1. The message log: instance created sent by HornetQ is received by LogM.

  2. The log_entry file containing information logs about the instance creation event is added to the MySQL database by way of a INSERT INTO statement.

  3. The log: cpe created message sent by HornetQ is received by LogM.

  4. The log_entry file containing information logs about the CPE creation event is added to the MySQL database by way of a INSERT INTO statement.

The last four steps - steps 11, 12, 13, and 14 - only occur after the messages relayed by HornetQ are received by the LogM internal server, In the end, all the information logs are added to the MySQL database.

← An In-Depth Look at The File Structure of a CoB server_* →