Migration from 4.3

Appmixer SDK

The Appmixer SDK has been heavily improved. On the other hand, it is not fully backward compatible. Especially, if you have some custom CSS hack to show/hide different parts of the UI widgets, these hacks may stop working. We have simplified the customization of the UI, you can now set only a few variables and change the whole look. It also means that the structure of the themes and strings objects have changed.

appmixer.ui

• widget.destroy method removed, use widget.close instead.

appmixer.ui.Designer

• options.beforeInspectorOpen replaced by a new event: component:open

• options.beforeInspectorClose replaced by a new event: component:close

• options.changeActionCallback replaced by a new event: component:update-type

• options.renameCallback replaced by a new event: component:rename

• options.onComponentAddCallback replaced by a new event: component:add

appmixer.ui.FlowManager

• options.filters list changed to support following presets:

filters: [
    { property: 'stage', label: 'Running flows', value: 'running' },
    { property: 'stage', label: 'Stopped flows', value: 'stopped' },
    { property: 'sharedWith', label: 'My flows', value: 'myFlows' },
    { property: 'sharedWith', label: 'Shared with others', value: 'sharedWithOthers' },
    { property: 'sharedWith', label: 'Shared with me', value: 'sharedWithMe' }
],

appmixer.ui.Components

• widget name changed to appmixer.ui.Connectors

Appmixer engine

New ENV variables

There are a few new ENV variables. You should set this one if you are running Appmixer self-managed.

The first one is for the Appmixer engine:

APPMIXER_FE_URL which has to point to your FE application (defaults to http://localhost:8080). You have to set this, only if you are using the built-in FE app, not if you use the Appmixer SDK.

Another one for the Frontend application (if you use it):

APPMIXER_BACKOFFICE_URL which has to point to your Backoffice URL. If the signed-in user is an admin, the FE displays a new icon in the left menu that can take the user straight to the Backoffice.

Webhook can return 202 response

Webhook components may return 202 code. That can happen when a component needs a quota to process the incoming webhook, but there is no quota available at that time. The webhook will be enqueued for processing and 202 returned to the caller. In the previous versions, the response to the webhook was delayed (until the quota was granted) which lead to timeouts

Components

Component versioning

It is important to re-install all the Appmixer built-in modules that you use through the Backoffice. This way, the source codes of those modules will be stored in the Appmixer database. Future releases of Appmixer (4.5) will be released without modules. New modules will be released and updated only through the Backoffice.

We introduced versioning for modules and components. This will allow us to deliver component updates independent of Appmixer releases. When we develop a new module, it will be directly available in your Backoffice and ready for installation. When we develop a fix for a module or a component, you will be able to update it through the Backoffice.

The Appmixer 4.4 version still contains all the built-in modules stored the old way - located on the filesystem. This is due to migration, when you update to 4.4, there will be no downtime for your flows that use the Appmixer modules. But the next major release will no longer include the built-in modules, all of them will be available and released only through the Backoffice! This means, that when you update to Appmixer 4.4, you have to install the modules you use, through the Backoffice, to be ready for the next Appmixer versions.

If you don't use any built-in modules, only your custom ones, you can skip the next part. If you use some of the built-in modules (including utils like OnStart, Each, ...), you should do the following AFTER you update to Appmixer 4.4. Go to the Backoffice and the Modules section. You should see something like this:

A bunch of modules, some of them could be marked with a purple Update available label. At the top of the screen, you could see a yellow box with an exclamation mark. You will see that yellow box only if you have a generic components ACL rule in your system:

And if you click it:

Generic ACL rule for user scope

That ACL rule is in the system by default. If you never used the ACLs, then you have it there. This rule says, that every user in the system can use every module/component. This generic default rule should be removed and replaced with an ACL rule per each installed module. Before you can do so, you need to create an ACL rule per each installed module, to make it easier for you, we added a button for that - ADD USER RULES FOR INSTALLED MODULES.

So the first thing, you need to do is to click this button:

A whole new set of ACL rules will be added, one per each installed module:

At this point, it is safe to remove the generic rule:

When a Backoffice user installs a module, they have to decide, when this newly installed module will be available to the users. The reason is simple. When you install a new module (either through the Backoffice or through the CLI) into Appmixer, you usually need to configure it first. In the case of an OAuth module, you need to set up the clientId and clientSecret, for example. Before you set up the module, you don't want your users to see it in the application. After the module is installed and set up, you want to test it. You can have tester accounts that will have access to these new modules through ACL. Once the module is tested, you can release it to your users by adding the proper ACL rule.

For details on installing modules from the Backoffice, refer to the Installing and updating modules tutorial.

At this point, you can go back to the modules page and install the modules you want to have in your Appmixer instance. Let's say you are using the Slack module. You go to the Modules section and look for Slack:

Every module will have the Update available mark on top of it. Some of them do contain new fixes or features, but some have no changes (only their version is set to 1.0.1 to distinguish them from the old versions in 4.3).

When you open the module, you can install it by clicking the Update this Modules button:

At this point, the module has been installed into Appmixer and is stored in its database. Such Appmixer is now ready for a future update which will be distributed WITHOUT modules located in the filesystem (in the zip file).

This step has to be repeated for every module that you use in your Appmixer.

Module changes

Few modules (Slack, JIRA, Microsoft OneDrive, and Tasks) were migrated into plugins. If you use those, you need to change some settings.

Slack Event API

Slack Events API endpoint URL has been changed from https://acme.com/services/appmixer/slack/events to https://acme.com/plugins/appmixer/slack/events

More information in the Slack Events API registration.

Microsoft OneDrive file picker

The file picker frontend component is using a BE API endpoint. Has been changed from https://acme.com/plugin/onedrive/picker to https://acme.com/plugins/appmixer/microsoft/onedrive/picker

More information in the Microsoft OneDrive file picker registration.

Utils Tasks

The Tasks module has been migrated into a plugin.

It does not affect functionality. In the previous version of Appmixer, some features this module requires in order to work were part of the engine. Like the Tasks API, collections, where the tasks are stored, were defined in the engine, and jobs that process the due tasks were part of the engine as well. The first disadvantage was, that you did not have access to this code, second, you did not have the possibility to extend the Appmixer engine with similar features (extending its API, adding new collections or jobs).

So the Tasks API endpoints have been migrated, the older ones removed and the new ones defined in the routes.js file located inside the appmixer/utils/tasks folder. And the collections were changed. Former peopleTaskTasks is now pluginAppmixerUtilsTasksTasks and peopleTaskWebhooks is now pluginAppmixerUtilsTasksWebhooks. The migration will perform automatically when Appmixer 4.4 loads the Tasks plugin for the first time. There is no need to do anything unless you access the Tasks API or collections directly.