Modules
Manage the modules available in the system.
Last updated
Manage the modules available in the system.
Last updated
Open Appmixer Backoffice and click the Modules item in the main menu.
In this section, you can see all the available modules that you can install. Already installed modules have an Installed badge at the top. You can also search modules by name and status (installed or not).
At the bottom, there is also an option to upload modules from your filesystem. More on that later.
When you click on any module, you are redirected to the module's detail page.
Here you can find the module's description, a few options like downloading the module as a zip file and installing/removing the module from your engine. You can also find a list of the components inside the module with their respective descriptions.
You can download any module that is available or installed as a zip file (your custom modules). Simply click Download this module and your browser will download the zip file.
When you are looking at the module details from a module that is not installed in your engine, you will have the option to install it.
To install an available module in your engine, simply click the Install this module button, and the installation will begin. You will see a loader indicating that the module is being installed. Some modules could take a while to install.
Once the module is installed, you should check several things.
Some of the modules require further configuration, this is typical for modules that use OAuth, but that's not a rule. There are modules wihtout authentication that require additional configuration. In such a case we provide documentation for the module, the link is visible on this page, you should read the documentation.
If your system is configured properly, it should not contain a generic ACL rule which allows all users to see/use all modules (more about that in the ACL section). When the module is installed, it is visible only to users with the appropriate ACL. This gives you time to configure and test the module before making it available to your users. There is a table here that shows you the ACL rules in your system that apply to the module. Once the module is configured properly and tested you can make it visible to the rest of the users. There is a button ADD ACL RULE FOR USERS here which will create the appropriate ACL rule for this module (the same can be done manually in the ACL section).
You can remove any installed module from your engine. Simply click Remove this module and it will be uninstalled and removed from your engine. You have to be careful when removing modules, as flows that contain components from this module will stop working. Please refer to this section for more detailed information.
As you probably know by now, you are able to create your own components. More detailed information on creating custom components is available here.
The Appmixer Backoffice allows you to upload the zipped module with components and install it in the engine. Once you have your components ready and zipped (using Appmixer CLI), click the Add module from your filesystem located at the bottom of the page:
After you click the button, a dialog will appear. Then you can drag and drop, or browse your files. Remember that only zip files are accepted. After doing it, you should see your file name in the upload box. Finally, click the Upload button to start the installation. This could take a few minutes to complete. After that your module will be listed in the modules section and ready to use.
When you remove a module that is being used by a running flow, the engine will start producing errors when components from that removed module are triggered. Depending on the type of component the behavior will vary slightly:
In the case of trigger components, the triggers keep polling and failing. If the module is re-installed, the trigger recovers and the flow can continue.
In the case of action components, the action component will start failing to receive messages. After a certain period (and a certain number of retries), the message is discarded and put into the dead-letter queue, which can be reached through our API. See the Unprocessed Messages section for more information. If the module is re-installed before all the retry attempts are used, the action component recovers and will process such a message.
In all these cases, the System Webhook will notify recipients of any of these failures with detailed information.
Sometimes the module and its components have to be changed entirely. It can happen, for example, when the 3rd party service changes the API completely when they switch from API key authentication to OAuth, or when they add new required properties.
In such a case, we prepare a new major version of that module, which is not compatible with the flows that were created using the older version. In all of these cases, the existing flows cannot be automatically updated to support the new major version of the module. It always requires input from the owner of the flow. If the authentication method changes, the user has to authenticate again. If a new required field is added, then the user has to fill in that field. If the API is completely different and the set of components in the module is different, then the flow has to be reconfigured using the new components.
The owners of the flows have to be notified that their flow was stopped and that they need to reconfigure it. There is a System Webhook WEBHOOK_FLOW_STOPPED that you can use to do this.
The payload of the webhook looks like this:
