Microservices

Microservices are independent components that run to prevent or solve common problems on devices, improve their performance, or speed up tasks that would take a lot of time to do manually. Microservices can run autonomously or as part of a broader feature within a system. Microservices allows you to create, enable, and publish microservices so that they can be executed at the organization level, as a prevention or self-remediation mechanism —through flows or alerts—, or directly by the end user.

​

Features

Microservices offers a number of key advantages. The most relevant are described below:

​

Access to a centralized catalog

The available microservices are organized in the Marketplace section, where users can browse the catalog, select and enable specific microservices according to the needs of their organization or particular use cases.

​

Creation of custom microservices

Microservices can be created easily through the Designer section. This tool guides the user, provided they have the appropriate permissions, through all the necessary phases to build and configure their own microservice.

​

Execution scope configuration

Each microservice can be defined to run in one of the following contexts, configurable from the Designer section.

​

Execution from the local administrator

Allows you to interact directly with operating system services, processes, and other resources that require elevated privileges. It is ideal for operations that must be executed with administrator permissions, but may limit access to specific information about the user or their session.

​

Execution from the user session

Useful for accessing user information such as the registry or information contained in the profile. The script will run with the permissions the user has, so if they do not have local administrator privileges, they will not be able to perform actions that require system access.

​

Ways to consume microservices

Microservices can be created and enabled to be executed by the end user, triggered through a flow, or with automated actions.

​

On-demand execution from Workspaces

Any microservice that has previously been enabled in Portal can be executed from Workspaces.

• Access the Workspaces module → Workspaces or Sessions section.
• Select the devices or sessions where you want to apply the microservice.
• In the top menu, click on the microservices icon (>_).
• Select the microservice you want to execute.

Microservices will be visible in the Workspaces section when they have been configured to execute in the System context, and in the Sessions section when the configuration has selected the Session context. The management of the microservice’s execution scope and permissions can be performed from the Designer section. Keep in mind that the authority to run certain microservices will depend on the role the user has on the platform.

​

Scheduled execution through Flows

Flows is a feature that allows you to define automation sequences to execute scheduled actions on devices based on the evaluation of pre-established logical conditions. Its main characteristic is that it simplifies diagnostic actions and quickly resolves problems through the execution of a microservice.

​

Scheduled execution through Alert settings

Through Alert settings, it is possible to link events (event logs) to one or more microservices, to prevent issues with the device or resolve problems immediately.

1. Go to Monitor → Alert settings.
2. In the table, select an alert name to access its detailed information.
3. In the left side menu, click the Microservices tab.
4. Click Link.
5. In the form, choose the microservice you want to link to the alert and the execution order (useful when you want to link more than one microservice).
6. In the form, click Link.

For more information on how to link an alert to a microservice, please consult the Alert settings documentation.

​

Execution by the end user

When a microservice is created, it is not automatically enabled for execution by the end user. To enable it, the following configuration must be completed:

1. Go to Microservices → Enabled.
2. Select a microservice from the list.
3. In the Recipients tab, go to the Execution by end user section.
4. Click Edit and activate Execution by end user.

Then, optionally, you can configure the reception of notifications.

​

Notifications

This option allows you to define whether the user will be notified when the microservice starts to run and when it finishes, either successfully or with errors. To do this, activate User notification and complete the following fields:

• Initial text. Message that will be displayed when the microservice’s execution begins.
• Success text. Message that will be displayed when the execution ends successfully.
• Error text. Message that will be displayed when the execution ends with errors.

Notifications will appear in the Windows notifications bar.

​

Change the name of the microservices folder

When microservices are enabled for execution by the end user, they are automatically added to a device folder called Flexxible; however, this name can be modified.

1. Go to Settings → Organization.
2. In the left side menu, click the Microservices tab → Edit microservices configuration.
3. Change the folder name.
4. Click Save.

The chosen name must have between 3 and 50 characters, and can only contain letters, numbers, hyphens, and underscores. If the device has Windows 11 as its operating system and only one microservice is enabled for an end user, the folder will not be shown; instead, only the microservice icon will be visible in the start menu.

​

Tracking the execution of a microservice

To facilitate the analysis and resolution of incidents, the platform allows you to consult the state, duration, and result of the execution of microservices through the Operations section. To consult the operations:

1. Go to Operations.
2. Select the corresponding operation. The side menu allows you to access different scopes of the execution: Details, Workspaces, and Events.

​

Details

This tab shows summary cards with the main indicators of the operation:

• State. Current status of the operation.
• Summary. Visual indicator of the overall result of the operation.
• Duration. Total time the operation’s execution lasted.
• Workspaces. Number of devices on which the operation was executed.
• Microservice. Name of the executed microservice. Clicking accesses its detail view.

​

Overview

This section presents a table with the following information:

• Description. Brief explanation of the operation performed.
• Operation type. Operation executed.
• State. Current status of the execution: Pending, In progress, Error, Timeout, or Finished.
• Created on. Date and time the operation’s record was created.
• Started on. Date and time the execution started.
• Finished on. Date and time the execution ended.
• Scheduled date. Date and time from which the microservice will be executed.
• Maximum scheduled date. Deadline date and time for the microservice’s execution.

​

Workspaces

This tab shows a table with the list of devices on which the microservice was executed. Each record includes the following information:

• Name. Device identification. Clicking opens its detail view.
• Reporting group. Reporting group to which the device belongs.
• State. State of the operation’s execution on that device.
• Started on. Date and time the execution started.
• Finished on. Date and time of completion.
• Actions. Allows you to access the detail of the executed microservice.

​

Events

This section shows the history of events generated by the system during the execution of the microservice, allowing you to diagnose errors or verify its progress. The information for each event includes:

• Date. Date and time the event was recorded.
• Type. Event level: Information, Error, or Critical.
• Origin. System component that generated the event.
• Message. Detailed description of the event.

​

States of an operation

• Pending. The operation is registered, but has not yet started executing.
• In progress. The operation is currently running.
• Error. The operation ended with errors.
• Timeout. The operation did not finish within the maximum allowed time. For microservices, this time is approximately four hours.
• Finished. The operation ended correctly.

​

Considerations

• If a microservice is executed on a powered-off device, the operation will end with an error.
• If at the time of executing a microservice the device is powered off or not reporting, the execution will fail and will not run automatically when the device is turned on.
• When a microservice is launched on a very large group of devices, operations are processed in a queue (state Pending). In that case, it may occur that, when the operation is started from the console, the order has not yet been sent to the device. If during that time the device is turned on, the operation can be executed.
• The execution of a microservice can also be scheduled to start from a specific time. In this case, the operation remains scheduled and will not start until the indicated time. During that time, the state of the devices may change.
• The maximum execution time of a microservice is approximately 4 hours. If the device restarts during execution, the operation will remain active in the console until reaching that limit. After that time, it will end with the Timeout state.

​

Detail of the executed microservice

The detail view of the microservice’s execution includes the following information:

• Started on. Date and time the execution started.
• Finished on. Date and time of completion.
• Duration. Total time elapsed between the start and the completion.
• Executed microservice. Identifier code of the microservice.
• Output. Information generated as a result of the execution, useful for validating the result and analyzing possible incidents.