After installing LiveCycle ES, there are a number of URLs that you use to access various LiveCycle ES web applications. Here's a cheat sheet for those URLs.
Continue reading "LiveCycle ES web application cheat sheet" »
Adobe LiveCycle ES provides a sample web application called Forms Installation Verification Sample (IVS). This sample is a web-based application that interacts with the Forms ES service to generate interactive PDF forms, HTML forms, and form guides that users can fill and submit. After you deploy the Forms IVS, you can use a web browser to render form designs created in LiveCycle Designer ES for testing purposes. Another use for the Forms IVS application is for debugging the forms in isolation from the rest of your LiveCycle ES application that was created in LiveCycle Workbench ES.
Continue reading "Forms IVS – A Form-tastic Development and Testing Tool" »
After running the standalone (non-Turnkey) JBoss LiveCycle ES Installer, you select the “Start LiveCycle Configuration Manager” option, but nothing happens. You then try to browse to the directory where you installed LiveCycle ES (e.g. D:\Adobe\LiveCycle8.2\configurationManager\bin), double-click the ConfigurationManager.bat file, and a Command Prompt window appears and closes in seconds. The LiveCycle Configuration Manager does not start. You check the log file (ConfigurationManager.000), but there are no log messages indicating the error.
Continue reading "Troubleshooting the LiveCycle ES Configuration Manager" »
LiveCycle ES provides a sample application called Output Installation Verification Sample (IVS). The sample is a web application that interacts with the Output ES service to generate PDF or printed output. After you deploy the application, you can browse to the web page it provides and render form designs for testing purposes. So, the Output IVS application enables you to debug the Output ES part of your solution in isolation from the rest of your LiveCycle ES application.
Continue reading "Output IVS – A Useful Output ES Development Tool" »
As part of our ongoing initiative to be a friend to the environment, we wanted to reduce the number of old socks polluting our landfill sites. So, to give these old socks a new life, and to explore different ways of delivering meaningful information to you, we are now using sock puppet videos to provide LiveCycle ES overviews.
See our latest video describing how PDF forms and form guides can be used to capture information for an insurance claim process.
Disclaimer:The information provided herein and in the attached video are solely due the influence of April Fool’s day. Any resemblance to real or actual puppets (living or dead) are pure coincidence.
Credits
A common pattern that’s used in process design is establishing ‘constant’ values that you refer to a few times in the process. To establish a constant value, you either:
With Adobe LiveCycle ES, you can certify PDF Portfolios to ensure that none of the documents contained within the portfolios are changed without being detected. Additionally, you can encrypt or policy protect PDF Portfolios and the files they contain, and you can apply usage rights to PDF Portfolios.
This article discusses limitations in the types of files you can include in certified PDF Portfolio and the order in which you must apply LiveCycle ES services when creating certified PFD Portfolios.
For definitions of the terms used in this article, see PDF Packages vs. PDF Portfolios located in the LiveCycle Doc Team blog (this blog).
The cover sheet in a certified PDF Portfolio can be an interactive form; however, the files contained in the portfolio must not be interactive. The certification for a PDF Portfolio becomes compromised if any of the component files are modified, even if the component file’s certification allows form fill-in.
To create a certified PDF Portfolio, apply operations in the following order. These services must be invoked within a short-lived process.
You can also create a process that consumes component files that are already encrypted, policy-protected, or certified. In this case, the order for applying services is still the same as above with the omission of the first step. If any of the component files consumed by your process are encrypted or policy-protected, ensure your DDX file defines them in a way that avoids the Assembler service having to open them. You can accomplish this goal by defining the component files using the <PackageFiles> source element, not the <PackageFiles> filter element. For example, the following DDX produces a PDF Portfolio without requiring Assembler ES to open the component files:
<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
<PDF result="outDoc" >
<PDF source="_AdobeCoverSheet" bookmarkTitle="Cover"/>
<PackageFiles source="doc1" required="false">
<File filename="MyFirstFile.pdf" mimetype="application/pdf"/>
</PackageFiles>
<PackageFiles source="doc2" required="false">
<File filename="MySecondFile.txt" mimetype="text/plain"/>
</PackageFiles>
</PDF>
</DDX>
Any of the following changes would compromise a certified PDF Portfolio:
Information about all of the DDX elements that are discussed in this posting can be found in DDX Reference.
LiveCycle ES Update 1 introduced the ability to use DDX files and the Assembler service to invoke the following LiveCycle ES services:
Note: Information about all of the DDX elements that are discussed in this posting can be found in DDX Reference.
Continue reading "Using DDX and the Assembler service to invoke other LiveCycle ES services" »
Here are a few easy ways to improve performance when using the Output service with forms.
Continue reading "Tips for maximizing Output service performance" »
Recently, I’ve learned more about execution contexts for process services and thought it might be important enough to post here.
Execution contexts determine which user’s account credentials are used to execute a service. Recall that a service is created for all processes that are activated, and each operation in a process is also provided by a service. So, all processes and operations have an execution context.
A few changes were implemented in LiveCycle ES Update 1 (that's version 8.2.1) that changed the way execution contexts work for processes. For both versions, the user that invokes the process is used as the invocation context for executing the process. The difference is in what invocation context is used for executing the operations in the process.
In LiveCycle ES (that's version 8.0.x), the context that is used for process operations depends on whether the process is long-lived or short-lived:
• In short-lived processes, the context of the user who invoked the process is used to execute each operation in the process.
• In long-lived processes, the System user (similar to a super administrator) is used to execute each operation in the process.
In LiveCycle ES Update 1, you can use Adobe Administration Console to specify a user account to use for executing process operations. Also, the behavior is the same for long-lived and short-lived processes. There are three options for configuring this feature:
• Run-As Invoker (the default): The context of the user account that invoked the process is used to invoke the operations in the process.
• Run-As system: The System user executes the operations.
• Run-as named user: A user account that you specify is used to execute the operations.
To learn more about configuring this feature, read Modifying security settings in Applications and Services Administration Help.
Note that for both releases of LiveCycle ES, render and submit services that are used with xfaForm, Document Form, and Form variables are always executed using the System user account.
Why is this important?
For some services, the user account that executes the operation affects the results. For example, in Content Services ES, the user that stores content is made the owner of the content, which affects who can later access the content. If you are using a process to store content, you need to think about what user is used to execute the Document Management service, because that user will own the stored content.
Until recently, when I've been using LiveCycle ES to learn about developing processes I often found myself creating a form using Designer ES and manually creating an XML schema to embed in it. I want to embed the schema so that I can see the data model of the form in Workbench ES. Seeing the data model is useful when you are creating XPath expressions using XPath Builder to access a value from the form data.
My limited knowledge of XML schema enables me to create only the simplest of schemas, and consequently, the simplest of forms. However, I've now learned how to generate an XML schema for an existing form. This frees me from having to learn the intricacies of XML schema, and enables me to use more complex forms in my processes:
1. Create the form in Designer ES. If you are creating an XDP file, save it as a different file in PDF format.
2. Open the form in Acrobat Professional.
3. Save the form data to an XML file.
4. Use the file with a tool that derives XML schemas from XML documents.
5. Embed the schema in the form. (see Displaying the form data model in XPath Builder in LiveCycle Workbench ES Help.)
Here is a blog article that lists a few free tools that derive schemas from XML: http://blog.dotkam.com/2008/05/28/generate-xsd-from-xml/. I like using Trang, a command-line tool written in Java (you need to have a Java runtime environment (JRE) installed to run it). The blog also lists some GUI-based tools if you prefer those.
Further Considerations
You may be tempted to use the XML schema that you generate as the schema for a database to use to store form data. This would work, however this solution doesn't scale well. If you develop several LiveCycle ES applications you will likely use many different forms to gather different sets of data. In this case, you should use a common schema for all forms.
It's also important to realize that the process doesn't need the XML schema to execute correctly. XPath expressions that locate form field data items are evaluated correctly regardless of whether the schema is present. You also don't need to see the data model of the form in XPath builder to create XPath expressions. Seeing the data model makes it much easier.
Have you ever been working away in LiveCycle Workbench ES or LiveCycle Administration Console, when you're unexpectedly forced to log in again because your session has timed out? By default, those components time out after two hours (regardless of activity or inactivity) and you have to log in again. But if your organization's security policies allow it, you can change the default timeout setting to any value up to 1440 minutes (24 hours).
If you're using LiveCycle 8.2.1, you can change the timeout setting by logging into LiveCycle Administration Console and clicking Settings > User Management > Configuration > Configure Advanced System Attributes. The setting is named Session Timeout Limit (Minutes).
If you're using an earlier version of LiveCycle, you can change the timeout setting in the configuration file. To update the setting, follow this procedure:
1. Log into LiveCycle Administration Console and click Services > User Management > Configuration > Import and export configuration files.
2. Click Export to produce a config.xml file that contains the current LiveCycle ES settings.
3. Open the XML file in an editor, change the value for the following entry to a number between 5 and 1440 (in minutes), and save the file:
<entry key="assertionValidityInMinutes" value="120"/>
4. Go back to the Import and export configuration files page and import the file that you just modified.
Long-lived processes store process data in the LiveCycle database. The growth of the LiveCycle database can be minimized using a few easy process design and product configuration strategies.
Process Design
Use short-lived processes. Short-lived processes don't store process data in the database. The downside is that you can't use Adobe Administration Console to track process status and state. Also, you won't have a history of the process or any BAM reports.
Some service operations, such as the Assign Task operation (User service), require that they are used in long-lived processes. In this case, you can segment the process into several subprocesses and make them short-lived when possible. If you use this strategy, short-lived subprocesses should handle large data items, such as document values.
Use variables sparingly. When using long-lived processes, for every process instance, space is allocated on the database for each variable in the process. Strategic use of variables can save a considerable amount of space:
Use the fewest number of variables that is possible. For example, you can overwrite variable values when old values are no longer needed in the process. And delete any variables that you've created and are not using. (Tip for LiveCycle ES Update 1 users: Validate the process to find unused variables.)
Use simple variable types (such as string, int, etc) and avoid using complex variable types when possible. Database space is allocated for variables even when they don't contain a value. Complex variables typically require more space than simple ones.
Product Administration
Use Global Document Storage (GDS) effectively. The global document storage directory on the LiveCycle ES server is used to store, among other things, files that are passed to LiveCycle ES services in processes. To improve performance, smaller documents are instead stored in-memory and persisted in the database.
Adobe Administration Console exposes the Default Document Max Inline Size property for configuring the maximum size of documents that are stored in-memory and persisted in the database. If you set this property to a low value, most documents are persisted in the GDS directory instead of in the database. The advantage is that you can more easily delete the files when they are no longer needed when they are stored in the GDS directory.
Some background references: