Head First Into Adobe LiveCycle

Yes, yes, I've had my issues with Adobe. However, I'm on a project where only Adobe LiveCycle will do. It's a massive project. The goal is to combine various data sources into PDF files created on the fly and archived for future access. We went through the standard RFP process to evaluate different tools. LiveCycle has the most potential for heavy-duty content integration. But cheap it's not. LiveCycle is an enterprise software solution with a hefty license fee.

Adobe's LiveCycle Diagram

Adobe's website says this about LiveCycle:

Adobe LiveCycle® ES (Enterprise Suite) software is an integrated server solution that blends data capture, information assurance, document output, process management, and content services to help you create and deliver rich and engaging applications that reduce paperwork, accelerate decision-making, and help ensure regulatory compliance.

Huh? Think of LiveCyle as an information hub. Many types of document sources can be used to pass information into LiveCycle and then it can spit out that information into several formats based on pre-defined templates. In other words, LiveCycle is a gigantic single-sourcing tool. You can also use LiveCycle to manage publishing workflows. That means you can assign content creators, editors, and publishers.

One thing I noticed about Adobe was they couldn't (or wouldn't) articulate what LiveCycle actually is. It's a modular framework for content management. You can pretty much make it do what you want it to do, but out of the box it's close to useless. Adobe will kindly sell you modules for LiveCycle that will connect your installation to your existing document repositiory, for example. The workflow tools were very impressive. I think that was my favorite feature demoed by Adobe. However, workflow management is also part of additional module. We didn't buy it so I can't play with it.

In our case, our final product will be PDF files. This is something LiveCycle does exceptionally well, naturally. I am still learning the principles by which the template system works, but what we are doing is using database data and static text files for content. That content will be inside an XML file and sent to the LiveCycle server as an HTTP request. LiveCycle will receive the request and run it through a template and send back a perfectly formatted PDF file. There are many reasons for our decision not to use LiveCycle to collect the data directly, but if we wanted it to, it could. In addition LiveCycle's output could be more than just a PDF file. For example, we could have it place content on the website and the content can be specified down to the individual customer. That would take more modules and more money.

The templates in LiveCycle are all XML-based. There is a nice GUI to protect you from having to touch XML code unless you need to some very specific but unsupported actions. This is where things start to get murky for me because we are in the preliminary phases, but from my understanding, LiveCycle's templates do not support CSS. I won't comment on this right now until I verify why no CSS is being used in our project. However, LiveCycle works best with PDF files, which do not support style sheets either. So it may be just our project. I'll know more next week.

So far LiveCycle is impressive in its potential. But getting it where you want it may take a lot of time and resources. I also think there is such a need for large content repositories to organize and output information, more products to compete with LiveCycle can't be far behind. The Linuxhead in me wants to see if you can cobble something together that does the same thing with existing Linux solutions, but I'll save that for my bucket list.