Posts in Category "Product Administration"

Configuring Rights Management ES Client Access

Adobe’s LiveCycle Rights Management ES solution has been in the market since the beginning of 2005 and, as of our LiveCycle ES Update 1 release this past summer, can be used to protect a growing variety of file formats – PDF, Office, CAD, and FLV. The server works together with Adobe Acrobat and Adobe Reader clients to protect, view, and manage sensitive PDF documents. Because support is included in every copy of Acrobat and Reader 7.x, 8.x, and 9.x, we have more than 700 million machines world-wide that are capable of receiving protected PDF documents with absolutely no configuration required or any special software to be deployed.

We give you the option to allow documents to be viewed on any of these clients out of the box, but understand that in certain cases you might wish to restrict clients to the latest version. For example, there may be cases where you want to take advantage of newly introduced functionality, such as the new AES-256bit encryption algorithms introduced earlier this year.

As such, we now allow you to configure each deployed server to restrict which client versions or applications the server may communicate with. Technical details can be found at http://www.adobe.com/devnet/livecycle/articles/deny_services.html.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

Execution contexts and LiveCycle ES processes

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.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

How To Minimize Database Growth

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:

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)