On this page |
📋 What’s about
The software provides the tools to handle automated groups of actions on the machines where XCALLY Motion V3 is installed. Through this program it’s possible to execute different types of API requests, custom unix commands or scripts, close channels interactions based on specific conditions or execute databases queries optionally saving them as a report.
⚙️ Installation
The software is executed like a XCALLY plugin, so it’s distributed as a zip archive to be installed directly through the admin interface on, from the AppZone → Plugins section.
Once loaded and installed, you can proceed to the plugin interface through the Plugins → Schedulease entry and complete the first configuration.
🔌 Plugin configuration
First of all you need to configure the Motion database and server details.
From the plugin interface, open the configuration tab and insert the credentials for the motion2 database connection, where the configuration tables for the plugin will be created, and the details of your server, including your server reachable URL and an admin APIkey.
-20241112-150221.jpg?version=2&modificationDate=1731423759509&cacheVersion=1&api=v2&width=637&height=321)
Remember to restart the plugin from the AppZone → Plugins section after saving the configuration
💡How it works
Basically, the software has a straightforward functioning.
You configure one or more automations, routines that are executed periodically, based on an interval that can take one or multiple values
For each one of these automations, you can create multiple actions, that will be executed sequentially, one after another, when the specified interval for that automation is met. The actions are queued, so the next action is not executed until the previous one has not finished or failed.
The queue is common through all the automations, so there is no possibility of two actions of two different automations to be executed at the same time, since all the actions are put in the same queue.Everything that’s happening in the background is logged and can be checked on the log files
🔧 Automations
The Automations view allows you to manage your automated routines. From here you can create new automations or modify and delete them.
Every time an automation is executed, the Last Exec field is updated. Also, in the interval column you can check when the next run of the automation will be.
You can create a new automation with the plus button located in the right bottom side of the page and fill in these fields:
Name of the automation
Interval: when the automation needs to be executed. You can choose the base unit of the repetition (Hour, Day, Week, etc..) and then you can select multiple subparts of that unit (e.g., every Hour at both 0 and 30 minutes)
Skip actions if still in execution: as mentioned before, the actions are all queued in a single queue, and executed after the previous one is completed. It could be, in a remote case, that while the action is still waiting to be executed, the automation interval is met again, and the system will try to insert the action again in the queue. If you want to avoid inserting the action in the queue while it still needs to be executed, you can select this.
Enabled button to enable the automation
And click on Add Automation
After you create an automation, it’s possible to quick edit it, by clicking on the automation row, or through the context menu on the right.
From there you will be redirected to the automation settings, where you can edit it or add/modify/delete actions.
➡️ Actions
From the Actions tab, in the automation settings, you can create new actions, modify and delete them. Each one of these actions, when the automation interval is met, will be added to a queue, and executed sequentially, one after another.
Also here, the Last Exec column is updated when the specific action is executed.
There are 4 different types of actions: Api, System, CloseInteractions, DbQuery
The Api action allows you to perform an API request toward a specified endpoint. You can:
use the most common Api methods (GET, POST, PUT, PATCH, DELETE)
Set a timeout for the Api request
Set custom headers for your request, in json format
In case of a POST/PUT/PATCH request, you can specify a request body, in json format
The System action allows running a unix command on your server. It includes two modes:
Command: it allows you to specify a command to run on your server. Useful, for example, to run command line instructions (e.g. date) or to run scripts files that are located on your server (e.g. sh /usr/src/myscript.sh)
Embedded: it allows you to directly define a script file with its content to be executed, directly from the web interface. You can choose among 3 programming languages (bash, javascript, python) and insert the code directly in the Code input. The system will create the corresponding script file (based on the name you choose) and execute it when the automation is launched
The CloseInteractions action allows to close a group of XCALLY Motion channels interactions, based on the channel, one or multiple accounts, and one or more conditions.
The conditions are applied with an AND operator (all selected conditions must be met) and are:
Inactivity: Amount of time since the last message in the interaction
Tags: The interaction must include at least one of the tags selected
Creation: Amount of time since the interaction has been created
If all the conditions are met, the found interactions are closed automatically.
The Dbquery action allows you to perform database queries using one of the ODBC connections configured in your XCALLY Motion server.
You can choose to execute the query, and optionally choose a Post query action to perform among these 3 options described below
1. Extract the query as an XCALLY report: You can choose different ouput formats (csv, pdf, xlsx, old xlsx). The extracted results will be available as normal extracted reports in the Motion server related section, where you’ll be able to download or delete them.
Eventually you can also choose to send the extracted report through email, using one of the email accounts configured on XCALLY.
You can only enable the report extraction if the inserted query is a SELECT statement
The report extraction takes in account the split configuration on your XCALLY server and splits the report files accordingly to the rows limit you setup in XCALLY general settings (report tab).
You can also decide if you want to send a notification email even if the results for the report are empty.
2. Send Query results to API: You can forward the results of the extracted query to an API endpoint. You can choose the API method, specify the URL, the headers in a JSON format and the request timeout.
By default, the body of the request will be the filled with the array of objects resulting from the query.
If you enable the Send each row individually flag, the resulting rows will be sent one at a time toward the API. In that case you can also specify the object you want to send as the body of the request and use the columns values with the {{column_name}} syntax, or you can leave the body empty to send the whole row.
In that case can also use the columns values in the url (E.g. http://mywebsite.com/api/update/{{id}).
3. Insert the query results into another db table: in this case, you can choose the database connection from xcally ODBC connections, and then specify the table where the results will be inserted.
The columns extracted in the query needs to be named the same as the columns required to be populated on the destination table, so using the “AS” syntax is recommended (e.g. SELECT source_column AS destination_column, etc…)
Logs
The application stores log files for each component and/or function that is executed in the background. You can find these logs in the Log view, where you can check when a specific log is been updated, download, or delete it.
The logs allow you to check the proper functioning of the application, and to eventually check for errors.
You can find logs in folder /var/log/xcally/schedulease
As mentioned, the log files are organized by component and by type, and can be of four types:
<component_name>-combined.log, includes the list of all the complete logs for that component.
<component_name>-combined.date.log (e.g. api-combined.2024-01-01.log): these files gather the log details for the specified component, including both debug and error messages, and for the day specified in the date part of the name. The logs are rotated daily, meaning that you’ll have a new combined log file for each component for each day. The rotation limit is set to 30 days, meaning that after 30 days the oldest logs will be deleted.
<component_name>-error.log, includes the list of all the error logs for that component.
<component_name>-error.date.log: these files gather the log details related to the errors only, and for the day specified in the date part of the name. The logs are rotated daily, meaning that you’ll have a new combined log file for each component for each day. The rotation limit is set to 30 days, meaning that after 30 days the oldest logs will be deleted.