V7.16 Release 4-29-23

  1. When deploying or exporting automations that use the “execute automation” or “turn automation on or off” System actions, the referenced automations are now included in the deployment or export.

  2. When an assembly, automation, or module is made public or private, their last modification timestamp is now updated so that the item will be updated when deployed or exported & imported.

  3. When saving an automation, if any invalid field mappings are present the UI now opens all closed groups and includes the name of the step(s) in the displayed error message. Also, the UI now highlights invalid field mappings in red when opening actions/conditionals/loops.

  4. Changed the data structure of the system’s internal work queue mechanism that controls automation processing, to improve performance for the scenario when many copies of the same automation are queued to be processed.

  5. Within mapped action fields in the automation editor, a “swap” arrow icon is now displayed next to all mapped fields. The icon allows a new parent action to be selected. Selecting a new parent action will cause all mapped fields from the previous mapped action to be replaced by the selected parent action. No validation is currently performed to see if the newly selected parent actually emits the same mapped fields. See Changing the mapped parent action - APIANT

  6. Webhook validation logic has been moved from hardcoded internal platform code to plugin JSP code. Zoom and Shopify are examples of API providers that have webhook validation rules. See Webhook Validation - APIANT

  7. In the assembly editor, the “More” menu at the top right has a new option to edit custom webhook plugin code. The menu option is only visible to accounts having the “Edit Webhook Plugin” permission. The code editor allows custom webhook validation logic to be written as JSP code. The baseline webhook validation JSP code that ships with the system can also be viewed. The baseline code has support for Shopify, Zoom, Amazon SNS, and Freshbooks webhook validation.

  8. In the admin console’s User Accounts screen, searching for a single term now includes matches on the person last name, instead of just the first name.

  9. In the admin console’s User Accounts screen, selecting a linked account now enables the “Unlink Account” button.

  10. When editing inline JSP, PHP, or JavaScript code in the assembly editor, the editor dialog now has a Compile button at the lower right that can be used to compile the code to check for any errors.

  11. In the automation editor, when editing a field mapping that consists of JavaScript code with the editor, a Compile button is now available at the lower right that can be used to compile (execute) the code to check for any errors.

  12. Improved the performance of nightly pruning of temp keygroup data in the keyvalue database table. A query that used to take 30 seconds now takes 7 seconds.

  13. System upgrades can now delete theme settings from theme.json and update node and attribute values in the system config file.

  14. Instead of storing all of an automation’s logs in a single directory, new logs going forward are now stored in subdirectories named by date and hour of day. This is done primarily to improve performance of the system’s nightly pruning of automation log files.

  15. The nightly pruning of keyvalue data for automations that have been deleted for more than 60 days has been broken into two separate SQL statements, to improve performance.

  16. Background coloring of automations listed in the dashboard has been adjusted to better indicate which ones are off/on.

  17. In the graphical automation history view, action output data is now searchable.

  18. The Subroutine Input trigger and Subroutine Output action implementations now use custom modules in their assembly implementations rather than inlined JSP code for XML transformations, for the best possible performance. Their inline JSP implementations could take up to 200ms or longer to execute, vs. single digit millis for the modules.

  19. Indexes have been added to two database tables to optimize query performance.

  20. Performing a reset of a polling automation (via the dashboard gear menu in the Processing section) that has processed lots of trigger data rows is now much faster for systems with lots of rows in the keyvalue database table. Instead of deleting database data when the menu option is invoked, the system now just flags database data so it will be deleted during the nightly database pruning.

  21. When saving a Subroutine Output action in the automation editor, the editor no longer briefly displays the field mappings popover.

  22. Module windows in assembly editor diagrams no longer change their size somewhat randomly when fields are moused over or focus & blurred.

  23. Fixed an issue with system upgrades where the Java implementations of new and revised modules were not written to the filesystem.

  24. Optimized the exporting of automations so that subroutines, assemblies, and modules are not duplicated in the export file. This can greatly decrease the size of the export file and may improve performance when importing, publishing, and deploying content.

  25. Assembly and automation versions are now stored in separate database tables, rather than as single XML blobs in their respective object tables, to improve database and system performance. As a result of the design change, there is no longer a limit to the amount of version history saved for automations.

  26. Support for writing automation and batch job logs to Amazon S3 has been removed b/c Amazon fees for S3 are much more expensive compared to storing logs on the server’s filesystem.

  27. The system now performs a reset of polling automations that have been turned off longer than the system’s configuration setting for purging deleted database content, as a way of deleting unused trigger row ids stored in the database.

  28. The Automations screen in the Admin Console has been entirely redesigned so that it is now an uber-dashboard for managing all automations in all accounts in the system. The initial design goal was so that groups of automations can be easily turned on/off in bulk across accounts. Automations can be tagged so that their on/off state can be reversed at a later point in time.