Adobe LiveCycle Central Migration Bridge

Adobe Output Central is a very old product with substantial customer base. Its design was basically watch folder based and it uses very naive string matching to run the customer workflows. The workflow steps can be simple command line invocations of the components of Adobe Output Central or any other executable. The core Adobe Output Central components are:

1. JFMerge – it merges templates and data to generate formatted document (PDF/PCL)
2. JFTrans – it converts structured text and overlay text to usable .DAT and XML data. It is also used for touching up existing data as ut contains a rudimentary scripting capability.
3. XMLImport – it converts XML data to .DAT data.

Besides these Adobe Output Central has other helper utilities like send/read emails. The main goal of this document is to help central clients to move from the rudimentary hosting environment of Adobe Output Central to modern environment of Adobe LiveCycle. Adobe LiveCycle Output Service does similar things as Adobe Output Central. But it uses different data and template models which are xml schema based.

The pricipal problem with current clients moving to or looking to move to Adobe LiveCycle is the time required to transition. It is in the magnitude of 1-2 years. There are basically two things the customers need to do. They have to migrate their Adobe Output Central templates to Adobe LiveCycle Output templates i.e. XFA templates and migrate their Adobe Output Central workflows to Adobe LiveCycle workflows. Though Adobe LiveCycle Designer provides capability to import any Adobe Output Central templates and convert it back to Adobe LiveCycle templates, this proves to be a more time taking than migrating the workflows. In fact, migrating Adobe Output Central workflows to Adobe LiveCycle workflows is very easy with the hosts of services available with the Adobe LiveCycle suite. So if we could keep on using the Adobe Output Central from Adobe LiveCycle environment by migrating the Adobe Output Central workflows, that would give our customers freedom to migrate their Adobe Output Central templates to Adobe LiveCycle Templates at their own pace.

We have created Adobe LiveCycle Central Migration Brige in ES 2.0 that enables the user to call all aforementioned core executables of Adobe Output Central from inside Adobe LiveCycle environment. The other helper utilities of central are either lightly used or can readily be replaced by Adobe LiveCycle Foundation components. Adobe Output Central clients can build new processes using Adobe LiveCycle and over time move their Adobe Output Central based templates to Adobe LiveCycle templates at pace that suits them and their business needs; as well this allows for a small application to be transitioned independent of many others allowing for confidence in transitioning to be gained; rather than us pressing them to big-bang the transition.

Adobe LiveCycle Central Migration Brige exposes 3 different operations one each for each core component of Adobe Output Central. Each of the operation will simply fork the corresponding Adobe Output Central executable as a separate process with suitable commandline options. The Adobe LiveCycle CentralMigrationBridge APIs expose the most frequestly used commandline options as an input parameter to the operations. This component will use the existing Adobe Output Central installation from the same machine where Adobe LiveCycle is installed.

The general execution sequence from the APIs would be something like the following:

1. Take input from the user and convert them into relevant command line options.
2. Create a process using ProcessBuilder and pass all commandline options.
3. The result would contain the output and several meta data files as well.
4. Return the Result to the user so that he can pass them to the next step of the orchestration.

Besides the three core component of Adobe Output Central Adobe LiveCyle CentralMigrationBridge service will also provide a fourth operation, dataAccess to help customers convert their data models (.DAT file) into XML document that can be xpath’ed into. This will enable the user to process some of the options that is passed to the .DAT file. We’ll also provide a strongly typed client to the customer to help in their further development.

API Description

Signature for the operations of this DSC would be the following:

1. CentralResult centralDataMerge(Document inTemplateDoc, Document inDataDoc, Document inoutPreambleDoc, String printerDestination, String inIniFilePath, String inAllOtherOptions) throws CentralMigrationBridgeException, DSCException
2. CentralResult centralTransformation(Document inDataDoc, Document inDataModelDoc, String inIniFilePath, String inAllOtherOptions) throws CentralMigrationBridgeException, DSCException
3. CentralResult centralXMLImport(Document inDataDoc, String inXCIFilePath, String inAllOtherOptions)throws CentralMigrationBridgeException, DSCException

CentralResult {
Document logDoc; //log file
Document responseDoc; //jetform.rsp file
Document traceDoc; //trace document that can be passed to the API again as preamble (Applicable only for merge API)
Document resultDoc; //formatted output doc (pdf/pcl) in case of merge API, transformed doc in case of trans API and imported .dat in case of xmlimport
}


4. Document centralDataAccess(Document inDataDoc, int inMaxBytesToProcss) throws CentralMigrationBridgeException, DSCException

Error Handling

Adobe LiveCycle CentralMigrationBridge service would throw the following errors:

The user can get central logs from the Output Objects returned by the APIs and debug the errors. The complete detail of the error would be in the log document returned by the APIs and not in the LC server logs. LC server logs would contain just the top level exception.