Best practices for creating LiveCycle processes

This article discusses some of the best practices for creating LiveCycle processes using Adobe LiveCycle Workbench. It does not apply to a particular version of Workbench and should not be considered as a step-by-step guide for creating LiveCycle processes, but it represents general practices to improve and standardize practices. Before implementing these best practices, ensure that they fit into your overall strategy for designing LiveCycle processes and align with your organizational needs.

Defining best practices and molding them into usual procedure is an on-going activity as individuals and teams gain experience with creating LiveCycle processes.

An important aspect of any LiveCycle process is its design and layout. Ideally, a process should be uncluttered, logically laid out, and easy to implement and understand:

• Keep the design simple. The process management diagrams visually represent the process. Avoid cluttered diagrams that contain lots of steps. To design clear process diagrams, use swim lanes, sub processes, and proper documentation.
• Provide a proper description for each process, operation, and route. You can set description in the Properties panel for a process.
• Provide a Title and a Description for every variable.  The Title is used whenever the variable is used for input or output in an operation and provides more information on its purpose than simply the name of the variable. The Description provides valid help information to the process developer. This is especially relevant for sub-processes and their input and output variables.
• LiveCycle does not provide extensive support to create new database tables and manipulate data sources. Use third -party data sources for creating database objects.
• To accelerate the creation of LiveCycle processes while minimizing the effort, you should consider creating sub-processes. Sub-processes enable you to re-use and simplify processes in your application. Create sub-processes for similar functions used in multiple places or across multiple applications.

Another important aspect of standardizing processes while creating LiveCycle processes is to follow a naming convention. Naming conventions are usually specific to one's organization, and therefore should be defined keeping the requirements and policies in mind before the development of LiveCycle processes begins.

• Use descriptive names for objects, instead of the default names, to define the functionality or the usage of the object. Use camel case for variable names.
• Use same language for all the processes, sub-processes, and applications. Do not mix multiple languages.
• Create standards for creating the folder structure for applications and processes.
• Use different names for each variable, object, process, and application to avoid a naming conflict.        
• Define standards for custom components, and then apply and enforce these standards for use.
• Define standards for implementing the logging, and then enforce these logging standards for use.

The optimal performance of processes, sub-processes, and applications reduces the resource utilization, computational time, and prevents applications from entering into stalled state.

Here are some best practices for increasing the performance of the LiveCycle processes:

• Implement exception handling in all the sub-processes. It reduces the number of stalled processes that cannot be resumed again.  
• The out-of-the-box components provide a way to define error routes.  When checking possible values, always implement default route or error-routes for all the sub-processes.
• The executeScript can slow LiveCycle processes. Instead of heavily relying on executeScript, create a custom component or use a combination of sub-processes.
• When performing checks on possible values, use uppercase or lowercase expression to implement a fail-safe mechanism. For example, on checking @nextStep = ‘PROC.001’, also check ‘proc.001’ and ‘Proc.001’.
• Ensure that your code does not contain any warnings. Apply a fix to the code to reduce the number of warnings.
• Do not place the code in the comments section, it leads to unreadable code and new developers will have a hard time understanding the code.
• Sometimes developers write few classes and methods only for testing some functionality and these classes/methods are not used later on.  Remove unused code as it will make code easier to read and understand.
• Sometimes, multiple components use a similar piece of code. Create jar files of such re-usable code instead of copying code from another component.
• Do not create ad-hoc database tables. Consult database team for approved and normalized scheme.
• For exceptions, perform proper checks for the condition instead of assuming a particular situation. Assuming a situation may lead to ambiguous results or stalled processes.
• Every node adds to the execution time and adds to database storage in case of long-lived processes. Avoid irrelevant or not-in-use nodes/operations.
• Consider using XSLT instead of defining long lists of individual mapping expressions, for moving  or copying multiple elements within or in between XML data.
• Check processes, sub-process, and applications for unused variables. Use Workbench Add-Ons to identify unused variables. Remove unused variables, especially in long-lived processes as processes allocate database space for variables.

Here are some best practices for coding:

• Use camel case for variable names.
• Always define the types (int / string / document) of the variables.
• Use clear and descriptive names for activities, use names such as “Set Search Variables”, in place of “setSearchVariables”. These names are used in LiveCycle Administration Console.
• The processes should always have a default route.
• While carrying out comparisons, always perform explicit conversation. For calculations, convert the process variable used for calculation to a number.

Error Prone:
/process_data/dataXML/CandidateDataCaptureForm/dataCapture/pmiData/pmiForSelf = “1” or /process_data/dataXML/CandidateDataCaptureForm/dataCapture/pmiData/pmiForSelf = 1

Best Practice:
number(/process_data/dataXML/CandidateDataCaptureForm/dataCapture/pmiData/pmiForSelf) = 1

• Always consider creating a custom component instead of putting code in a executeScript object. It enables you to do better unit-testing, and re-use of functionality from other custom components.
• Always implement return values for sub-processes. When calling a sub-process (especially synchronous, short-lived ones), it must return a value, which can be checked by the main-process. This way the main-process knows what the status is of the sub-process. The main process should handle the return value appropriately.
• Avoid hard-coded literal values. Such values require rebuilding, repackaging, and redeploying the application when changing LiveCycle environments. Use configuration values where possible so you can configure the service outside of its process definition.  
• Implement default route at all the check points. The process routes are defined for almost all the possible values; the default route invoked when the variable does not match any possible values. The default routes prevent creation of stalled processes.
• Logging uses a lot of system resources, even when it is switched off. Avoid excessive logging for optimal utilization of system resources.

Consistency and completeness among all the processes makes processes understandable, improves performance, and reduces the clutter in the code.

Here is the checklist to ensure consistency and completeness among LiveCycle processes:

• You have handled exceptions.
• You have handled invocations of sub processes and their return value properly.
• You have removed unused variables.
• You have removed irrelevant operations.
• You have annotated your processes properly.
• You have checked outgoing routes from your operations for consistency.
• You have replaced literals with configuration variables at relevant locations.
• You have checked your calculations and comparisons to use proper data types and for completeness.
• You have checked the sizes of each of your variables.

We have discussed, in brief, the best practices for creating LiveCycle Workbench processes.

You can visit LiveCycle Developer Center for additional information. The documentation for LiveCycle Workbench is available at LiveCycle ES3 Documentation page.

Although the documentation should answer most of your questions, feel free to initiate and participate in discussions.