One of the best parts about being an Atlassian certified consultant at Valiantys is getting unusual requests from clients, and following it down the rabbit hole until we derive an innovative solution. Thus when we were asked to make content from a Confluence instances available without an Internet connection, instead of just laughing nervously we dug into the use case for the potential solution.
Accessing Confluence offline
The client in question, a global leader in engineering and electronics, came to Valiantys to help them design and create a consolidated Enterprise Content Management (ECM) solution to centralize all of their documentation and content across their UK business unit. Their previous content management solution at the time was leaving gaping holes in knowledge, containing out-dated information and providing little to no continuity, not to mention the high cost and strain on staff and resources. Combining all the content was the next and logical step for reducing operational costs, improving decision making, increasing customer satisfaction and of course creating continuity.
We were therefore charged with consolidating tens of thousands of pieces of content: documentation, images and videos from multiple digitized formats and systems, such as SharePoint, Websites, Office documents and a custom built in-house wiki. On top of that, thousands of paper documents, manuals, booklets and even some flash cards were also included. If that wasn’t hard enough, all this content needed to be accessible by 2000 online users and roughly 500 remote users who regularly traveled around the country and often didn’t have an Internet connection. They previously either gathered the hard copies, printed out required information, or called the office for telephone support. Obviously, that solution quickly became unscalable and unreliable.The client already had another business unit using Confluence for a service desk knowledge base, so the tool became the front runner.
We just had to find a way to make the content available offline.
Taking Confluence offline
To start, we had to build an enterprise scale Confluence instance – which as an Atlassian Platinum Solution Partner, we’re pretty good at. We quickly fired up a Confluence server instance with a straight-forward set-up running on a Windows Server, SQL Server and Apache with ample RAM and HDD space. A couple of apps were also thrown in the mix to manage the content, such as Comala Workflows.
Once set-up we mapped out the content migration paths. After tweaking this, we finally had a high level ECM solution with thousands of pieces of content from a wide verity of sources.
Next, we thought about how remote users could reach Confluence’s content offline. Exporting the specific pages prior to use was one option, but also not much better than the current solution. The client was also adamant that the offline solution should behave as close as possible to the centralized Confluence ECM solution.
So this left us with the option of physically running a local Confluence instance on each remote users’ laptop to mirror the ECM Solution – all 500 of them. These remote Confluence instances needed to get all their content from the ECM solution for regular updates. We searched for a previously implemented solution – which didn’t exist – or an app that could do the job. The closest thing was RoadRunner for Confluence, an old unsupported app that syncs data between Confluence instances.
We tested this idea in a small pilot group of around 5 remote users, in theory it was working but was it needed to be scalable and more reliable. Luckily, RoadRunner was made open-source, so getting the Java source code wasn’t too tricky. One of our developers took it apart, analyzed the methods and drastically improved the functionality by adding the ability to sync macros, labels, changing the UI along with others and facilitating a silent install.
Now we had a sample of remote laptops that would sync the data between the remote Confluence instance and the central Confluence ECM solution. Obviously the synchronization required an Internet connection, but once the sync was complete all the content was stored locally – within no need for Internet. RoadRunner also gave the remote users the option to choose which content they wanted to sync, reducing the time and storage required.
Roll out needed some serious thought, as we couldn’t have each of the end users manage and install their own Confluence instance along with RoadRunner.
Rolling out the new offline Confluence solution
We needed the roll out to be non-disruptive for the remote end users. We took one of the manual remote installs for testing and modified it to be a template. We edited all the configuration files as required, added a generic local user, a group, updated permissions and applied a development license. Each of the instances would run on the standard ports 8090 and with the embedded H2 Atlassian database, so adding a dedicated database server for each wasn’t required. This left us with a remote Confluence instance that could easily be “migrated”. For RoadRunner a similar process was followed, we used one of the already configured RoadRunners and adapted it to use the generic user to communicate with the Confluence ECM solution. RoadRunner configuration files are just text based, so replicating these was straight-forward.
The client already had remote management of all the remote users laptops set up using Windows SCCM. The package duplicated the templated Confluence and RoadRunner set up into one bundle, which could be pushed out for a silent install. Each of the Confluences and RoadRunner would be installed as a Windows service to run at start up, limiting any user interaction with the systems. All this left the remote users to do was to use the RoadRunner UI (when connected to the Internet), select the spaces they want to sync and press go. The sync displays a progress bar, and once complete the Internet connection can be dropped. Updating the content is simple – when the remote users have an Internet connection, RoadRunner picks up and can sync any changes made down to the local Confluence instance.
The remote users can then simply open any web browser go to http://localhost/confluence and see all of their selected content from the centralized Confluence ECM solution!
If this use case appeals to you or if you have any other unusual scenarios you’d like to investigate, then definitely get in touch we’d love to hear about them. Get in touch with one of our Atlassian certified consultants at Valiantys.