This article is applicable only to Adobe LiveCycle ES4 (11.0) release. It explains how the key features and workflows that have changed with LiveCycle ES4 Service Pack 1 (SP1) are different, in terms of behavior and usage, in LiveCycle ES4.
If you have upgraded or planning to upgrade to LiveCycle ES4 SP1 (11.0.1), see the following resources:
The complete LiveCycle help, updated for LiveCycle ES4 SP1, and other helpful resources are available at LiveCycle Help Home.
The IVS application, adobe-mobileforms-ivs.ear, is delivered along with the LiveCycle installer. The default location of the application is the [LiveCycle_root]/deploy folder.
- Run the LiveCycle Configuration Manager (LCM),
- On the Installation Verification Sample (IVS) EAR files screen, select Include IVS EARs in deployment set and click Next to install the application.
Caution: Do not deploy the IVS EAR files to a production environment.
Open http://<server>:<port>/mobileformsivs on your desktop where the forms created using Designer are saved.
In the folder field, specify the name of the folder that you want to use for storing the XFA-based forms on the application server.
To select the XFA form or the XML data document, click Browse, select an XFA-based form (.xdp) for transformation or data document (.xml), and click Open.
To upload an XFA form or a data file, click Upload File & List Existing Forms. A list of the available XFA forms and Data Files appears in the corresponding list boxes.
To render a form, select the XFA form and the Data File (optional), select the required profile, and click Render Forms. The rendered form appears in the adjacent tab of the browser.
Note: Once the forms are uploaded on the server from a desktop machine, IVS can also be used to render these forms on supported mobile devices.
If you have created a custom profile, and want to render the forms with it, select custom in the profile dropdown and provide the profile name.
Mobile Forms uses caching to optimize throughput and response time. You can configure the level of the cache service to fine-tune the trade-off between performance and space utilization.
|None||Do not cache artifacts
|Conservative||Cache only intermediate artifacts that are generated before the render of the form like template containing inline fragments and images|
|Aggressive||Cache Rendered HTML content
Cache all the artifacts cached in the Conservative level.
Note: This strategy results in best performance but consumes more memory for storing the cached artifacts.
Mobile Forms perform in-memory caching using LRU strategy. If cache strategy is set to None cache will not be created and existing cache data, if any, would be cleared. Besides the caching strategy, you can also configure the total in-memory cache size which can help in having the maximum bound on cache size and if it goes beyond that it will use LRU mode to free up cache resources.
Note: In-memory cache is not shared between cluster nodes.
While performing PDF conversions, a LiveCycle server takes in account of various timeout limits. The Global timeout constitutes of the conversion time and clean-up time required to perform post conversion operations.
This timeout is defined in various BMCs of PDF Generator. The default value of Global Timeout is 300 seconds.
Note: Ensure that the value of the Global timeout is greater than the Server Conversion Timeout value. It is recommended to set the Global timeout limit 30 seconds more than the Server Conversion Timeout limit.
Perform the following steps to set the Global timeout in LiveCycle ES4:
- Navigate to [Application_server_root]\server\<profile>\deploy and copy the adobe-livecycle-native-<appserver>-<architecture>_<os>.ear file to a temporary folder.
- Extract the copied adobe-livecycle-native-<appserver>-<architecture>_<os>.ear file.
- Open the following files for editing and update the Global timeout value in these files:
- Create an archive of all the extracted files. Ensure that name and the structure of the archive is similar to the original adobe-livecycle-native-<appserver>-<architecture>_<os>.ear file.
- Stop the application server.
- Navigate to [Application_server_root]\server\deploy and replace the older adobe-livecycle-native-<appserver>-<architecture>_<os>.ear file with the newer file.
- Restart the application server.
Perform the following steps to configure CRX repository clustering:
- Go to http://<authorHost>:<authorPort>/lc/system/console. Log in with OSGi Management Console user credentials. The default credential is admin/admin.
- Navigate to Main > JMX, locate the row with domain: com.adobe.granite and type: Repository.
- Click Repository. Under Operations, locate and click joinCluster(java.lang.String master, java.lang.String username, java.lang.String password). In the pop-up dialog box, specify the following information:
- java.lang.String master: http://<hostname>:<port>/lc/crx/config/cluster.jsp. [Provide the hostname and port of the node that should act as a master.]
- java.lang.String username: admin
- java.lang.String username: admin
- Click Invoke. It may take some time to complete the configuration. Do not press refresh or back. On completion of configuration, a success message appears.
- To connect more slave nodes , repeat steps 1-5 for each slave node and provide an identical master URL for each slave.
Note: Do not perform these steps on master node.
- On starting a cluster, ensure that the master node is started before all the slave nodes. On stopping the cluster, stop all slaves before stopping the master node. In some specific scenarios, Master node and Slave nodes can switch roles; ensure your master before stopping the cluster.
The particular start /stop cluster order is enforced for CRX clustering but since it is embedded in LiveCycle, ensure that you follow this procedure while starting and stopping LiveCycle cluster.
A slave node waits for the specified number of seconds for the master node to be up and running. If the master node is not up in specified seconds, the slave node stops its repository. To join the slave node in the cluster, restart the slave node. The default wait time for a node is 60 seconds. Use the following JVM argument to configure the number of seconds for the slave nodes:
Some users start all the nodes of the cluster at once. In such scenarios, the start order dependency may fail and slave nodes of a cluster fail to start. To avoid such issues, ensure that the wait time for a node is 300 seconds or more.
Note: Restart the slave instance to avoid stale sessions.
Important: All author instances in the cluster should be time synchronized. You can use an NTP (Network Time Protocol) server to ensure time synchronization.
For the steps to install the Demo application package, see the article Download and install the demo app packages.
To add an annotation, tap the Annotate button on the upper right corner of the screen. The screen defaults to the camera annotation.
In the General tab of the Settings screen, use the Fetch forms option to specify whether or not to download the associated form when each task is downloaded to your app.
The manifest file is used by the app to define assets that are used in the app. For details, see Updating the manifest file.
Since downloading data on the mobile device can affect the performance of the device, by default, the Fetch forms and Fetch Attachments settings are set to OFF. The forms and attachments are fetched to the device for any task that is downloaded from the server after these settings are updated to ON. In the offline mode, a user can then work on all tasks that are downloaded to device after setting the Fetch forms and Fetch attachments options to ON.