Archive for May, 2009

LiveCycleES: ALC-WKS-007-040 error in Workspace trying to open a form


When trying to open a form in Workspace you may receive an error ALC-WKS-007-040, and the form will not be displayed.


This error can occur in many different situations.  You should analyse the server log and see what the cause of the exception is.

Here are some examples where this error can occur:

  1. The form as specified in the render options cannot be found, or the render options are incorrect.  This situation would often be accompanied by the following errors in the log:
    • ALC-FRM-001-058: Cannot retrieve the resource from Repository Path
    • ALC-FRM-001-035: Failed to load TemplateStream for FormQuery=
    • ALC-WKS-005-028: A problem occurred in the Render Service
  2. It is using some cached version of the form, and the cached version is then deleted.  You may see the following errors in the logs in this situation:
    • EJB Exception: : com.adobe.workflow.template.document.TemplateNodeNotFoundException: Template object: A1239961657505 not found.
  3. The root cause in the exception trace is: com.adobe.idp.taskmanager.dsc.client.task.TaskNotFoundException: no task found for task ID = xxxx
  4. “The application has failed to start because omniDynamic411_vc8_rt.dll was not found.” error received in Windows.


Follow the respective solutions related to the situations above:

  1. Verify your render options in the xfaform variable.  Use the parameters as specified in the online help:
  2. Upload the form again to the Resources view in Workbench, or create a new folder, and change the xfaform variable to reference the new form location.
  3. This error can occur in numerous situations following a migration from LC7 to ES.  Solutions can be found under:
  4. Refer to solution in:

Additional Information

If you are upgrading a LC7 process which contains a User QPAC, to ES, there are some manual steps you should follow to be able to make the process work in ES.

You will need to change the lc7form variable to an xfaform variable, remove the init-form, configure endpoints and so on.  You can find a detailed guide to this process under:

reference: (180890414)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (1 vote cast)

LiveCycleES: “The application has failed to start because omniDynamic403_rt.dll was not found”


When you are attempting to perform a render operation in LiveCycle ES, you may receive the following error in Windows itself:

The application has failed to start because omniDynamic403_rt.dll was not found.
Re-installing the application may fix the problem.

You should then check the server log for any exceptions. You may see the following exception:

Service XMLFormService: Starting native process with command line
-MyPath D:\bea\user_projects\domains\lc_domain\null\adobe\lc_server\XMLFormService................
BMC024: Service XMLFormService: Process ProcessResource(name=XMLForm.exe,pid=0) terminated abnormally with error code {3}

This could also be accompanied with an ALC-WKS-007-040 error in workspace if you are attempting to render into the browser. You may also see another error code in the server log ALC-FRM-001-004, which indicates a problem with the XMLFormService, of FontManager service. You can check that both of these services are running in the admin console for LiveCycle.


The underlying cause of this is that the XMLFormService could not be found. This is due to the “null” entry in the path to the XMLFormService as seen in the exception above. This actually creates a “null” directory on your server’s file system, and will populate it with the native files. However at runtime it cannot interpret this “null” in the path, and so reports that it cannot find the XMLFormService.


You will have to modify your weblogic startup script to set the adobeidp.RootDirectory property.
1. stop your weblogic server and any admin server that might be running
2. find the setDomainEnv.cmd or script and search for JAVA_OPTIONS (this is usually at the end of the file)
3. you will need to add the following argument to the JAVA_OPTIONS:
-Dadobeidp.RootDirectory=<path to LiveCycle Domain>  (e.g. D:\bea\user_projects\domains\lc_domain)
4. save the file
5. restart your weblogic server

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

LiveCycle Workspace ES: how to disable/hide the complete button


When working with forms in Workspace, you automatically get a complete button which often hides the submit buttons on the form.  It is a common requirement to hide this complete button, especially if you have pre-submit validation scripts on your form, or multiple submit buttons depending on the context.


You can disable this button in the following ways:

  1. You can customize the Workspace interface in Flex Builder
  2. You can modify the standard rendering services (for e.g. you can remove the route to the last two steps “Workspace enable” and “Reader extend” in the LC7UpgradeRender service)
  3. Use multipe in-direct submit buttons on the form, that contain a call to the click event of the hidden FS_SUBMIT button


The submit/complete button will still be available on the card/list view in the Workspace todo list.  This enables users to submit the form without even opening the form itself in Workspace.  In order to disable this button in the card view, you have two choices.  Firstly you can specify the ‘Form must be saved’ setting in ‘Form Data Mappings’ in Workbench.  The other option is to change the “client_routes_formViewOnly” to “true” in the workspace global settings, as described here:

under: Workspace Administration Help > Importing and Exporting Global Settings > Workspace ES global settings

Additional Information

To understand the situations when the complete button is displayed, and when the form submit buttons are displayed, please refer to the following description of the Inject Form Bridge service.


Adds javascript code to an Adobe PDF form or Adobe Acrobat form to enable it to function within LiveCycle Workspace ES. The PDF form must have been created using Adobe LiveCycle Designer ES, version 8.2, or Adobe Acrobat 7.0.5 or later.

If your process uses Adobe XML forms (XDP files), you can render the form to PDF and then use the Inject Form Bridge operation. To render to PDF, you use the renderPDFForm operation that the Forms service provides.

Workspace ES provides a Complete button that users click to submit their forms. However, forms can also include submit buttons. When the Inject Form Bridge operation is used on a form, Workspace ES either hides the submit button, or disables the Complete button.

Form design


The form includes no submit button.

Workspace ES disables the Complete button and users cannot submit the form.

The form includes one submit button.

Workspace ES hides the submit button and enables the Workspace ES Complete button.

The form includes a button (indirect submit) that points to a submit button (direct submit)

Indirect-submit buttons always take precedence over direct-submit buttons, even if multiple submit buttons exist. Workspace ES always shows the indirect submit buttons.

Workspace ES hides the submit button and enables the Workspace ES Complete button.

The form includes multiple indirect-submit buttons that point to one or more direct-submit buttons.

Workspace ES disables the Workspace ES Complete button. The user must click the appropriate button on the form to submit it.

The user can still save a draft version of the form or take the form offline

The form includes either an indirect- or direct-submit button in a repeating subform.

Workspace ES excludes these buttons for submitting the form in Workspace ES.

Note: When the submit button, that was added to the form design with the Process Fields,  is hidden, the button still provides the functionality for submitting the form.

Submit requests are handled by Workspace ES, which acts as an intermediary between the LiveCycle ES server and the form. Also, forms can be used both offline and online.

reference: (180833713)

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

LiveCycle ES: ALC-DSC-000-000: com.adobe.idp.dsc.DSCRuntimeException: Internal error.


When reading XML data into a process variable in LiveCycle ES you may receive the following exception:

Target exception: ALC-DSC-000-000: com.adobe.idp.dsc.DSCRuntimeException: Internal error.
at bsh.BSHMethodInvocation.eval(
at bsh.BSHPrimaryExpression.eval(
at bsh.Interpreter.eval(
at bsh.Interpreter.eval(
at bsh.Interpreter.eval(
at com.adobe.workflow.qpac.script.ScriptService.execute(

This particular exception occurred using the Script QPAC to read in the XML data using script as follows:

String clean_xml = patExecContext.getProcessDataStringValue("/process_data/myxmlbranch");

clean_xml = clean_xml.replaceAll("(<)","<");

clean_xml = clean_xml.replaceAll("(>)",">");


This script works fine in LiveCycle 7, but after upgrading to LiveCycle ES, the script throws the error.


There are some unexpected characters in the XML data stream.


In this case there were quotation marks at the start and end of the XML stream.  Such characters were stripped away automatically in LiveCycle 7, but LiveCycle ES is more strict with the format of the incoming  XML.  You must remove the unexpected characters manually and then it will process the XML without problems.

Additional Information

If a LiveCycle 7.x process, that is upgraded to LiveCycle ES, includes the Script QPAC, the Script QPAC may contain script that was developed using the LiveCycle 7.x API. To ensure compatibility with LiveCycle ES, the script may need to be rewritten based on the LiveCycle ES API.

In this case the getProcessDataStringValue() and setProcessDataValue() methods of the patExecContext embedded object are available in ES just as they were in LiveCycle 7 so there were no changes necessary in the script.

reference: (180833653)

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

LiveCycleES: description of manual tasks after upgrading from LiveCycle 7

For anybody looking for more information about migration from LiveCycle 7.x to LiveCycle ES, there are some manual steps involved which you should know about so that you can plan your resources and testing around this.

The main manual tasks are:

  1. Upgrade process using Upgrade tool
  2. Delete init-forms
  3. Change each form variable type from ‘lc7form’ to ‘xfaform’
  4. Set render/submit service for each xfaform variable
  5. Remapping User QPAC’s input and output variables (in LiveCycle 7.x, the input can be a variable name, but in LiveCycle ES, it must be an xPath expression), if multiple User QPACs are used in a process, you have to remap the input/output one-by-one.
  6. Activate the new process version

You can find more information on each of the steps above in the LiveCycle Workbench ES documentation below.
Upgrading processes in LiveCycle Workbench:
…see the section under Creating Processes > Upgrading processes, particularly the section on Performing Upgrades.

For LiveCycle Workbench ES2.5 you should read the following documentation:

More information about the tasks involved in upgrading a process that uses an init-form bound to a schema:

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