In part one of this two part series, I talked about some of our experiences with workflow systems and portals, and how we have built systems where domain specific workflows were provided in the context of a portal, like LifeRay. Specifically, we build a SaaS marketing system on LifeRay, and got to the point where marketers needed to create response forms and landing pages.

For the response forms, we used Orbeon, which turns out to be a very popular web form solution, and brings us back to where we started, forms and workflow. Over the past couple years, I had heard the word “Orbeon” bandied about the office by I did not know much about it. It turns out that most of the work done with Orbeon has been done by developers in our offshore R & D center. Recently I wanted to find out more about it, and that led me back into this journey into the world of forms and workflow.

At its core, Orbeon is an implementation of XForms, which is a standard for XML Forms that was developed in the 2000s. You’ll find a W3C users group on line that is pushing things forward, so adoption and application of the standard appears to be fairly widespread. There are several vendors with compliant products. Orbeon has a freemium model, but the open source version is all we have ever used. The commercial version has supports commercial RDBMS products, and claims internationalization and performance enhancements over the community version.

The community version is the core product, consisting of the XForms processor, Form Runner, which is the runtime environment that contains the forms processor, and a web based Form Builder. The Form Builder creates forms that allows one to design forms with quite a wide a variety of controls. As in most programming IDEs, there are property pages for controls that enable one to set various options, assign validation rules including whether a value is required, what the data type must be, a calculation formula, and error messages. Once you create a form, Form Builder writes out the XForm representation into the Orbeon repository. Then you can run the form embedded in a web page.

Now, our use of Orbeon is somewhat non-standard, of course. It turns out that Orbeon integrates fairly well into LifeRay. Its not just the Form Runner that runs in a LifeRay page, so does the Form Builder. So somebody decided to make the Form Builder part of the marketing application (as well as the Form Runner, of course). This means that the person creating a marketing campaign can open the embedded Form Builder and create his or her own custom forms, for instance, contact forms that they will request their prospects to fill out on line. Personally, I’m not sure it’s a choice I would have made because while Form Builder is fairly easy to use, it still seems to me like you need to be at least a power user, especially if you are going to get into validation rules and formulas. Perhaps our expectation is that they are not.

In any case, with that genie out of the bottle, the marketing person can create many versions of a form and will want access to several versions for future use. Orbeon does not have a built-in versioning capability, so we had to invent one. At first, we saved form definitions versions as rows in the MySQL database. That solution ran up against object relational mapping challenges between the document representation of the form and the tabular representation in the DB. Considering that LifeRay has a document library, and all documents in the document library are saved in versions, it seemed like we ought to try to persist the forms as documents in the LifeRay document library. This required that we customize Orbeon’s persistence layer to call the Liferay API to save form definitions (XML) to the Liferay document library directly. As a result, a form gets representated as a document in the Liferay Document & Media Library, and we can view a form as an asset, just like other documents and  images that are stored there and used in client landing sites, email campaigns and other campaign components.

The net result is that when a prospect responds to a contact, they can be directed to a customized response form designed by the marketing campaign designer and managed as an asset in the LifeRay document library, where they enter their information. From there, application can route the prospect (based on what are essentially workflow rules), for example by sending out a particular offer or document, or presenting a specific, personalized information page. At the end of the day, we find ourselves using a reasonably contemporary toolkit to do what amounts to the same old thing. But the need never goes away.