Documents are an integral part of case management applications. They mostly form the unstructured data related to the subject of the case. Their use is so often that adding a document panel in the Be Informed platform is a trivial procedure.
Looking a bit deeper into the matter we can distinguish at least two major use cases for using documents. One is when documents are part of the data that is required to process the case and are usually used in a read-only fashion. The second use case is when the document is actually constructed while processing the case. In the ideal situation, whenever a document is be constructed while processing the case then we want it to be generated automatically. This is to say that the case workers need only to worry about (parts of ) the content in its basic form (text, not styling and form in general) and that the document is then generated by the application. This ideal situation is indeed only ideal. In practice we come across situations where the main task of some case workers is to edit a document while processing a case.
In the case of having to edit a document within the context of case most, based on the the Be Informed platform, projects tend to use of the following approaches
- Rely on a document management system as part of the overall solution or
- Provide the ability to download a document locally, edit it then upload it again
The first approach is, AFAIK, not used that often and the second is workable but tends to introduce undesirable side effects as many aspects are left the case workers to decide. In a recent project the customer was concerned about the various naming conventions and versions of the same document uploaded by various case workers. The case workers were not very happy with having to download, edit and upload a document. Could we do something about it, was the question.
So what does it take to make it possible for case workers to edit a Word document on the fly within the context of a case? Well, basically the same things it takes to edit a word document in any on-line application. That must have been done so many times before or at least so I thought.
The most straight-forward solution would be to provide the document not as a read-only but as read-write and let the client (browser) open it with Microsoft Word. That turned out to be much easier said than done. Although the new versions of Office support opening a remote file (as on the server) they do require specific HTTP methods that are not supported by the Be Informed server nor can be easily added. Going down this path would mean to replicate a Java solution form a document management system (like Alfresco) into the platform which might take months of work.
The basic functionality of editing a Word document in web application is however a problem that has already been tackled. There is even a commercial library that does that for you so why not use that instead. After a short research I ended up choosing Aceoffix. It had all the functionality I needed and I could try it with an evaluation licence.
The architecture of the solution is shown in the figure below
On the bowser side an extra plugin (that can readily be loaded the first time the application is started) is used across all browser types to embed Microsoft Word in the HTML page. Microsoft Word has to be installed on this target machine and is not provided by the plugin.
On the server side there is a service provided by Aceoffix to deal with Microsoft Word documents and a V&R plugin that provides the service as part of the Be Informed server functionality. The functionality includes o.a locking the file being edited.
From an end user perspective the editing is seamlessly done within the application. If a document is being edited by another user then it is clearly seen in the overview and is only available to other users in a read-only mode.