Export and Import a Configurable Transaction
Studio allows you to export and import configurable transactions along with their dependencies — such as action libraries, external services, and lambda libraries. Exporting transactions and their dependencies allows you to migrate a whole transaction flow and its functionalities to a new environment without having to create it from scratch every time.
Warning
Legacy action libraries (action libraries created with Postman) cannot be imported/exported.
Export Transactions
To export transactions, navigate to the Transactions page (in the global transaction logic repository), filter transactions by the product you are working on, select one or more transactions from the list, and click Export. If the transaction contains dependencies, such as lambda libraries, external services and/or action libraries, those will be included in the resulting zip file.
This .zip file can then be used to import transactions into another environment with all required dependencies bundled together.
Important
It is suggested to filter transactions by product before exporting the transactions file. Transactions are imported one product at a time. If you export multiple transactions that correspond to different product codes, importing them will override the product code to the one selected during the import process.
Import Transactions
You can import one or more transactions per product at once with their dependencies, such as action and lambda libraries, from other environments. The import process will detect if any of the imported transactions or dependencies are already available in the environment, and you will be able to override or create new entities from them.
Follow the steps below to import transactions from a .zip file:
Go to the transactions page and click Import.
Upload the .zip file either by clicking Select a file and selecting a .zip file from your device, or by dragging a .zip file from your device into the modal.
In the product drop-down list, select the product to apply it to your imported transactions.
Warning
This will replace your transactions' code to the one selected in the drop-down menu.
Studio will display a modal that contains information about the imported entities. The modal includes the transactions' branch, the file's export date and the origin product. Below, the modal details the entities included in this import, such as:
the total number of transactions; and
the number of dependencies included, divided by action libraries, lambda libraries and external services.
If no conflicts are detected and there are no duplicated transactions or dependencies, click Import to finish the process. If Studio detects conflicts in the import process, read Resolving Conflicts to learn how to proceed.
When the import process finishes, a .json file downloads automatically. This file provides traceability of the process and allows you to track which entities were imported and which changes were introduced.
In this .json file, you can see detailed information about:
the product of the imported entities;
imported transactions;
updated transactions;
imported transactions with a new code;
omitted transactions;
new, updated or omitted dependencies;
transaction codes and the dependencies involved.
Important
To add traceability in GitLab, there will be a commit per imported and/or updated entity.
Resolving Conflicts
If Studio detects conflicts during the import process, a modal will show them and allow you to take action.
Read below to read about each conflict it can detect and how to resolve it.
Another transaction with the same name exists in the target environment, which might mean that there is another transaction that has the same logical behaviour but is not up to date.
In the modal that appears, you can:
check the transactions you want to overwrite in your environment; or
leave the checkbox blank to discard transactions from the import process.
Important
The checked transactions will overwrite the ones in the environment. For example, if your environment contained a 1058 LoginTransaction and you are importing a 1058 LoginTransaction, the new transaction will override the old one.
Another transaction with the same code and different name exists in the target environment. In this case, the modal will display the conflicting transactions with their code, their import name (or the name in the source environment), the name in the current target environment, and a New code blank field that will be enabled when clicking the checkbox.
In this case, you can:
Enter the same transaction code in the New Code field to override the existing transaction.
Add a different transaction code in the New Code field to import the transaction. The field will validate if the entered code is in use.
If the new transaction code is in use in the transactions that did not present any conflict in this import process.
If the new transaction code is in use in the target environment.
If the new transaction code is not being entered in another transaction in this same modal.
Leave the checkbox and the New code field blank to discard the transaction from the import process.
One or more dependencies already exist in the environment. In this case, the modal will display the number of affected dependencies and will divide them by the following categories: Action libraries, lambda libraries, and external services.
Click each dependency folder or each dependency individually to override them in the target environment.
Considerations
Studio allows you to import dependencies, such as libraries, that contain another library within it.
If there is an update on an external service, the transactions that consume it will not be automatically updated. This means that if an external service is updated during the import process, it will update its version in the target environment, but the transaction that consumes it will still reference its older version. To fix this issue, you need to edit the transaction in the transactions editor and re-link the external service.
Action libraries created with Postman cannot be imported or exported.