I recently found these articles on the web that I wrote in 1999 (yes, that’s seventeen years ago, and yes, I was writing about what we were doing at EC Wise). I used to write a lot of articles, back in the pre-historic nineties, when articles were published in print magazines and had to be reviewed and vetted by editors, but I digress. One of the articles I’m referring to discussed the migration of forms based workflow systems to the web. The other, Wf-XML and Interoperability discussed Wf_XML, which was being proposed as a standard schema for representing workflows (it has since fallen by the wayside). Given my background in automating purchasing, inventory management, and payroll systems, this was very much an area of interest.

Many of the foundation technologies called out in those articles became the basis for much of the work we have done over the years. In particular, we have done a lot of workflow, though much of it has been more of the industrial style where if various conditions are fulfilled, there need not be any human intervention for the workflow instance to proceed to the next step. Our teams have used jBPM and Activiti to implement these systems. When we started we had to modify the source code to enable the ability to proceed through steps based on conditions, a feature often referred to as asynchronous continuation. Nowadays most of the workflow engines support this.

Over the years Activiti has matured quite nicely. It uses BPMN 2.0 as the notation for representing workflows, which is now as close to a standard as there is. As they say on their web site, “Activiti runs in any Java application, on a server, on a cluster or in the cloud. It integrates perfectly with Spring, it is extremely lightweight and based on simple concepts.” In one system, we packaged and ran Activiti as an OSGi bundle inside a ServiceMix Karaf container, where steps that needed the services of “distributed” legacy systems would invoke those legacy systems through a message queue. It has been extremely reliable.

Well, I started this post thinking I was going to write about the state of the art in forms, so I think I’ll shift gears and go there. A few years ago we started working on a marketing campaign definition, management and execution system with the rather prosaic name of AMP for Automated Marketing Programs (they probably couldn’t even trademark that!). One of the main objectives for the product was for it to be a multi-tenant system that offered a lot of “portal” capabilities to the users, who would often be the marketing team at some company (or marketing agency). They would use the portal to manage marketing content. Another objective was that these users would be able to create custom response forms which prospects would visit and hopefully fill out when they clicked on a PURL or GURL in a communication the system would send them – via email, SMS, Facebook messenger, LinkedIn, etc.

To facilitate the creation of portals, we decided to build the product pretty much on top of LifeRay. At the time, we did not have a lot of LifeRay expertise on our team, though a couple folks were reasonably familiar with it. The learning curve for much of the team turned out to be a bit steep, and getting the gestalt of building components took some effort. But after all, it is the leading java portal for a reason, and that reason is that the LifeRay company has been very aggressive about pushing the product forward and providing a full portfolio of portal features. So from a portal standpoint, you get a lot of features for free if you develop portlets following their methodology. We have become pretty good at that. Parenthetically, there is now an Activiti plug-in for LifeRay which allows us to apply our Activiti expertise on LifeRay based platforms.

That’s enough for one blog post; in the next one, I’ll discuss how we created the response forms.