CMSOI

Challenge

Green Valley developed a plugin called DSOI (Discovery Server Office Integration) for their CMS product that is used by a wide variety of government authorities, as well as corporate customers.

The plugin allows easy access from Microsoft Word to the document tree and dramatically improves user experience. It allows accessing, modifying, and uploading new documents to the CMS directly from Word and to also set metadata. It opens Word files stored in the CMS. All of these actions are performed via the plugin’s menu added at installation.

DSOI was written in C++ and it communicates with Office using COM and OLE technologies, so it could only be used with certain versions of MS Office libraries. Therefore, Green Valley was maintaining several plugin builds for each version of MS Word. And once users upgraded their Office version, the plugin became non-functional.

The challenge was to create a next generation plugin that would meet the following requirements:

• Easy to install
• Require no admin rights to install
• Be as independent from a MS Office version as possible
• Support multiple languages and be localized at least in English and Dutch

Solution

The Redwerk team started off by researching how to implement a plugin that would work with multiple versions of MS Office. We found a match with VBA (Visual Basic for Applications), which is widely used for writing macros for MS Word and other Office products. It’s a translated language that doesn’t need to be compiled into binary code in order to be executed. The only challenge was dealing with slight incompatibilities in the API created by different Office versions, which our team quickly overcame.

Our Windows applications development squad created a prototype using a very basic use case of saving a document into the CMS along with some metadata. It had to ask for credentials, login into the CMS, fetch and display the document tree where a user would be able to pick a location to save the document. This prototype had to work on as many Office versions as possible. To communicate with the CMS, it used a proprietary protocol based on HTTP — also a protocol our team helped develop.

Next, we went on to implement additional scenarios and a UI. We added localization and tested, tested and tested again to make sure it works flawlessly in all the MS Office versions we wanted to support. To achieve this, we only used the most generic APIs.