This post is the last in my current retrospective series, that sampled the projects I was working on years ago. You can see the previous posts here and here.
While the previous posts were about projects that span through years, this will be about a project that took no longer than a couple of months.
I was desperately looking for a screeenshot in my archives, to add as an illustration. I finally gave up, and tried to go with the University logo from the Internet. Imagine my surprise, to find the application is still up and running! It wasn't used since 2013, but considering it was not maintained since the end of 2010, it was quite well done. You can see the version number on the bottom of the screen.
Disclaimer: The project is described best from my memories. I tried to keep the story professional, still there were emotional aspects that I tried to present in the back story.
Background
I was running a small company of IT professionals between 2003 and 2010. Our main strength was getting into projects with obscure technology requirements, and helping out the customer with the project deliveries. These were times, when there were so many major projects, where the customer prescribed a certain technology and the supplier had no idea, how to deliver. Our clients were mostly engaged on projects in the telecommunications and financial sectors. We were going strong until the financial decline around 2008. Most large projects were cancelled and we were struggling to find jobs anywhere.
Corvinus University in Budapest is the most well-known University of Economics in Hungary. They offer several grants, participate in consortial projects, as well as run their own departmental projects. As usual the department responsible for this was undermanned and was floating in paperwork. Thus came the idea of having a system that keeps track of the tasks.
We were previously involved in a filing and records management project that turned out as a complete disaster for both the University and ourselves. The company that originally won that project disappeared into thin air, leaving them without the promised government mandated electronic records management system, and us with the unpaid bills for months of business analysis and development.
To cut our losses we took on this task, salvaged whatever we could from the previous project and tried to meet the short deadline.
Project goals
Government subsidised programs and projects have a great deal of red tape associated with. There are pre-defined reports and milestones associated with each project. Forms must be filled and filed all the way through the project and even after it's completed the results must be reported. The projected spending must be reported along with the actual spending, and the remaining budget must be visible. It takes lots of paper pushing and record keeping to keep things aligned with the expectations.Constraints
The University has recently introduced a new ECM system, Alfresco. Since the goal was to base as many projects as possible to Alfresco, the project had to make use of its' abilities, like the task management, rights management and the document management features. The financial data had to go be stored alongside the relevant documents.
The user interface had to be separated from the Alfresco, as this was a purpose made application, and had to be task centric.
There were only two months for developing the application, before the project subsidy expires. The time frame has also set the maximum possible amount billable.
Development was to be started before the winner of the public bidding was announced. If we didn't win that would have been a wasted effort.
The source code along with development documentation was to be handed over. The documentation must be detailed enough to make the code understandable for qualified developers.
Architecture
The overall architecture was just as simple, as a three tier web application can get. Data backend, application server, web front-end. There were only a few twists to it that made the project special.
Most of the data model had to be implemented using Alfresco's content metamodel. As the Alfresco content metamodel allows great flexibility in terms of inheritance and meta data customization, it was surprisingly easy to create the entire structure. The financial data was stored in the metadata on the milestone nodes, that contained the documentation related to the given milestone, as well as the rest of the milestones. Since projects are pretty easily represented in such a tree structure, this was even easier to create and manage, than to design the corresponding database and create all the traversing algorithms.
Using "traditional" document archive solutions, such as DB2 Content Manager, ECM Documentum, Saperion, that use a more rigid content model, like table per document type, this would have not worked. Those beasts are great for storing vast amounts of documents of a limited type, but Alfresco was good to store virtually any type of document albeit not as effectively.As the milestones and the documents themselves had associated actions, such as deadlines to produce some document, or review something, we had to dig in and provide ad-hoc task assignment features. Since the users of the application were in the project monitoring office, but the executors of these tasks were "only" people with access to the Alfresco Web interface, we had to come up with something that uses Alfresco but not directly our application. Alfresco had jBPM version 3 built in those times.
I never was satisfied with jBPM, to me it was not much more than a hack in itself, that ignored the trends and standards for so many years. Alfresco has decided not to go with jBPM, and upgrade to the already available version 5, despite, that it already supported BPMN 2.0. They have developed Activiti that's way easier and better integrated.Even though Alfresco provided API's to most of it's internal components, it was not true for the task management. We had to create an add-on to the Alfresco to expose the jBPM services. Since our goal was to create a reusable framework, that can be deployed on a out-of-the-box Alfresco installation, it had to be created as a standard package. This was when the open source world has shown it's backside. Neither Alfresco package structure, nor the jBPM API, nor the way it was integrated in Alfresco was well documented. We had to do lots of digging around in the source code to make up for the non-existent documentation.
The actual application was based on standard EJB 3.0 that managed the connection to the Alfresco web services. We used the mandated Glassfish AS, which was great at that time, and we separated it from the Alfresco instance, just in case. The front-end was implemented in JSF 2.0 using Primefaces. We had to match the University design handbook on the UI, and since we had no designer at this time, I was the one re-skinning the components using CSS. This presented some problems, as the version of Primefaces that contained the features we needed, was still in development. Fortunately that was not a "big-league" type open-source library, the developer offered us help, it was well documented, and worked almost out of the box. We even went to production with a pre-release SNAPSHOT, because we couldn't wait another month for the actual release.
The most challenging, and interesting part of the entire interface was the collapsible project tree display. This was implemented in PrimeFaces' tree control, since it is a really flexible implementation, even the data aggregation was done pretty easily. The only custom code we had to do, was the Export to excel feature, that dumped the entire project's financial data to a spreadsheet, for further analysis. Once we got that right, the rest of the application was just a standard JEE development task.
Reporting was implemented in Jasper Reports. Fortunately this reporting engine already had the ability to use the Java beans that we used in the application to map our data model to the front-end components. It just clicked in it's place waiting for someone to define and implement reports in it.
Development
As I pointed out, the timeframe was tight, the administration overhead was huge, still we had to deliver readable, maintainable components.
With all the gear already in place it took no more than a few hours to set up the continuous integration environment using the traditional Java stack.
- Subversion - source code repository
- Maven - modularization, dependency management, build management
- Jenkins - automatic builds/releases
- Nexus - Artifact repository to store build results
