Introduction to Atlassian Connect

In software development, Atlassian products like JIRA and Confluence are widely used today. But these days such tools are also applied in other areas. Meanwhile, Atlassian offers the applications also as cloud products (SaaS), hosted by Atlassian. For the user this is a simple approach, as he can just use the application without having to worry about installation and operations.

Unfortunately, the many already existing add-ons for the server version are not available in these cloud variants *1. With Connect, Atlassian delivers its own framework to extend their cloud applications with add-ons. Currently JIRA Cloud, Confluence Cloud, HipChat and Bitbucket Cloud are supported.

Add-ons with Connect

Technically the existing server add-ons are OSGi Bundles which are implemented in Java and are also directly installed into the application. This type of installation is not possible for cloud applications. Instead, Connect add-ons are autonomous web-applications, which communicate with the application (e.g. JIRA) via REST interfaces. They may also render content like HTML, which will be included in iframes.

The picture (by Atlassian ) shows this communication scheme.

The different functionalities of the add-on are declared through a descriptor, which assigns  them to certain places in the application. Connect offers the opportunity to add elements to the user interface. Therefore, the descriptor contains  URLs pointing to the add-on, together with the information where to place the contents. JIRA will call this URL and integrate the returned HTML in the surrounding page. Furthermore, functionality without a graphical user interface can be registered. This way, the add-on can handle various events (like updating an issue) or add Post Functions to Workflows. Also in this case there is an URL (webhook) pointing to the functionality added to the descriptor.

As the add-on is an autonomous webapp, being called using a REST interface, it does not depend on the technologies used by the main application (e.g. JIRA). The programming language, frameworks and so on can be chosen freely instead. Atlassian and the community additionally offer libraries and tools for different languages and technologies, making development easier and taking responsibility of the ground work. Additionally the current trend for microservices brought up libraries and tools supporting this integration approach.

The add-on vendor also operates and administers his webapp in this model, meaning he has much more tasks following development. He is responsible for hosting and availability. In exchange he gains the advantage of having more control over his application. Updating the add-on becomes much simpler and apply automatically to all customers. No customer administrator needs to manually install the new version, as it is with server add-ons.

But in return this also means, that the customer has less control and needs to trust the vendor even more. If the vendor does not ensure continuous operation or performs incompatible updates, the customer cannot use the add-on anymore.

Compared to server add-ons, there are also limitations on Connect add-ons regarding possible range of functions. Because they are not that deeply integrated as the directly installed variant, they cannot interfere at so many points. An example is the support of Workflow Post Functions, but not of Workflow Validators. Internationalization (i18n) is also not supported at the moment. Whereas some features are planned and might be supported in the future, this is not likely for others. So it is not imaginable to implement an add-on with a custom HTTP filter with Connect.

Installation

As with server add-ons, installation takes place through Marketplace. Add-ons can be offered free or paid, private listings for internal use in organisations are also possible. For chargeable add-ons, payment via Atlassian is supported as well as direct payment via vendor.

Conclusion

In general, Connect offers a good way to extend the applications of Atlassian.

For add-on developers (in the sense of programmers) there is a notable higher flexibility regarding technology stack, which also enlarges the circle of possible developers. On the other hand the framework is not that powerful and offers a decreased level of integration. For add-on vendors in general there is increased effort, due to new challenges like operation of the application.

Atlassian stated that Connect will not be available for JIRA Server and Confluence Server. This results in duplicate implementation and maintenance work for add-ons which should be available for server and cloud. This could also lead to a fragmentation of the community, with impacts on documentation, tutorials, help forums etc.

For users, the difference to server applications is way much smaller. The add-ons do not reach the complete functionality and not all add-ons are available for cloud but there is much work happening in this direction. The biggest risk is that the vendor could stop his add-on which makes it suddenly no more available. Atlassian gives some hints on selecting trustable add-ons.

In the next article we will investigate, how security needs are fulfilled by Connect add-ons.

How about you? Would you use the cloud variant in your enterprise? Share your positive and negative experiences with Connect add-ons in the comments.

*1 There are selected server add-ons preinstalled in cloud instances. This is a special case and should not be considered as option for own plugins. It is more a temporary solution, until these features can be implemented with connect.