One of the characteristics of Integromat is transactionality that works here similarly as in relational databases. In practise, it means that each module contained in a scenario is processed in the following 4 phases:
At the beginning of the scenario execution run each module is initialized. During the operation phase that follows, the modules return bundles (Read operation) and/or perform other operations with the bundles (write operation). If the operation phase succeeds on all modules, the third phase (commit) begins during which all operations performed by the modules are committed. If an error occurs during the operation or commit phase, all modules and bundles are rolled back (the operation or commit phase is aborted). The scenario run is then marked as Failed. In the last step, all modules are finalized and the scenario run is completed.
The following text describes the individual phases in more detail.
During the initialization phase, all necessary connections (connection to a database, email service, and others) are created and it is checked, whether a module is capable of performing intended operations.
Reading and/or writing is performed during the operation phase.
The read activity consists in obtaining bundles that will then be processed by other modules according to a predefined scenario. Example: During the operation phase, the Dropbox module Watch files returns new bundles (files) added since the last run of a scenario.
The write activity consists in sending bundles to a given service for further processing. Example: During the operation phase, the Dropbox module Upload a file uploads the received file to a selected Dropbox folder.
In this phase, operations are committed. Integromat sends information to some services about successful execution of the scenario.
If an error occurs during the operation phase or the commit phase, Integromat starts the rollback phase on all modules. The rollback phase reverts everything to its initial state before the start of the run.
Some modules do not support rollback and data processed by these modules can not be rolled back. For more information see the ACID modules section.
During the finalization phase, open connections (e.g. FTP connection or database connection and others) are closed and the scenario is completed.
All Integromat modules that support transactionality are marked with the ACID tag. The modules that are not marked with this tag do not support transactionality and can not be reverted back to their initial state in case of error on other modules.
A typical example is the Send an Email action. Once the email is sent (during the operation phase), you can not undo the sending.
The following example shows how to connect three ACID modules. The aim of the below scenario is to get new rows from a MySQL database, insert (transfer) them into a MSSQL database and then insert the IDs of the rows from the MSSQL database into a PostgreSQL database.
When the scenario starts, the initialization phase is performed first. Integromat verifies connections to the MySQL, MSSQL and PostgreSQL databases one at a time. It everything goes well and the connection is successful, Integromat moves on to the operation phase. If an error occurs, the finalization phase starts instead of the operation phase and the scenario is terminated.
Next comes the operation phase. A preset procedure selects (reads) the table rows (bundles) from MySQL. Those rows are then passed to the next module that writes them to a selected table in the MSSQL database. If everything is in order, the last PostgresSQL procedure is called to insert the row IDs returned by the preceding module into the table.
If the operation phase is completed successfully, the commit phase begins. Integromat calls the SQL COMMIT command for each database and the write operations will be committed.
However, if the operation or commit phase fails due to an error, (e.g. connection failure), Integromat calls rollback. During the rollback phase, Integromat goes through all modules one after another and executes the SQL
ROLLBACK command for each module to revert each database back to its initial state.
Finally, during the finalization phase, each module will close its connection to the database.
For each scenario, you can specify the maximum number of round trips allowed between the initialization phase and the finalization phase of the scenario execution run. By default, the maximum number of round trips is set to one. This can be changed in the Advanced scenario settings.
Example: In the above example, if you set the number of round trips to 3, the initialization phase will run first followed by 3x the operation phase and 3x the commit phase and then by the finalization phase.