If you have installed ES3 SP1 (10.0.3) to your LiveCycle ES3 server and Workbench ES3 you may encounter a problem creating new processes. Selecting the menu item to create a new process does not have any effect. If you look in the Workbench log file (C:\Users\<YOUR_USER_NAME>\Workbench ES2\.metadata\.log) you may notice the following exception:
!ENTRY org.eclipse.ui 4 0 2012-05-31 21:58:28.424
!MESSAGE Unhandled event loop exception
ALC-DSC-110-000: com.adobe.idp.dsc.registry.endpoint.EndpointStoreException: endpoint registry failure.
Caused by: com.adobe.pof.schema.AttributeNotFoundException: Attribute: parent_oid does not exist on object-type: dsc.sc_category.
at sun.reflect.GeneratedMethodAccessor546.invoke(Unknown Source)
ES3 SP1 includes some feature enhancements in Process Management. This involved addition of new columns and tables to the existing ES3 DB schema and hence requires a DB re-initialization when running LCM.
You should always read the installation steps in the ES3 SP1 readme (link below) before attempting the installation. In this case, you will need to re-run LCM and select the step to initialize the database.
You can download ES3 SP1 here:
In LiveCycle ES it is possible to track the dependencies of parent forms to form fragments and vice versa using the functionality in Workbench ES.
In LiveCycle ES2 it is also possible to view the form fragments used by a parent form in Workbench > Form Design > Properties:
It is not possible to track the dependencies from a form fragment to see in which parent forms the fragment is used. This is due to the architectural changes related to the new application model in LiveCycle ES2.
In LiveCycle ES3 it is again possible to track the dependencies of parent forms to fragments and vice versa.
If you have a requirement to track the dependencies from fragments to parent forms in LiveCycle ES2, then you can do this using the LiveCycle API using code similar to below:
ResourceRepositoryClient repositoryClient = new ResourceRepositoryClient(myFactory);
String fragmentUri = "/Applications/TestApplication/1.0/fragments/AddressFragment.xdp";
List relations = repositoryClient.getRelated(fragmentUri, false, Relation.TYPE_DEPENDANT_OF);
Here is a full sample class you can execute to test this functionality against a running LC server (you will need to adjust the settings for your environment): ListDependencies.java
When using LiveCycle Designer 9 through LiveCycle Workbench 9 to create and modify XDP templates with static text and floating fields, you may notice that saving the form in this situation creates duplicate <body> nodes in the XML source.
There is an issue with the integration between Workbench and Designer and the auto-checkout functionality when saving changes to a file.
This issue will be addressed in a future release. Currently there is a quick fix available for LiveCycle ES2 SP2. Contact Adobe Enterprise Support to obtain this quick fix.
As a workaround you use the Save button on the Designer toolbar, rather than the File>Save menu item.
This issue can be reproduced using the following steps:
- Open Workbench 9.5.
- Create new application.
- Right-click new application and create new form in Workbench, click Finish.
- Add a static text object.
- Menu: Insert->Floating field.
- Save and close XDP.
- Checkin form in Workbench.
- Double-click form in WB to open in Designer.
- Delete some chars from static text label.
- Click on File menu (yes to checkout).
- Then view XML.
Duplicate <body> node in the static text field object.
This behaviour means that only the first node, with the old text label, will be used when the form is rendered, and shown in Designer design view. It also produces an “Invalid append operation” error in the server log, and in Designer log.
When you use Date objects in a LiveCycle ES 8.2.1 orchestration after migrating from LiveCycle 7, the following exception may occur:
ALC-DSC-119-000: com.adobe.idp.dsc.util.InvalidCoercionException: Cannot coerce object: Apr 07, 2010 of type: java.lang.String to type: class java.util.Date
This exception occurs if you are trying to use the parseDate() or parseDateTime() functions in your XPath expressions. In LiveCycle ES, it’s not necessary to use these functions to convert Strings into Date objects. These functions cannot handle formatted date strings. For more information about the date functions, see the LiveCycle online Help: http://livedocs.adobe.com/livecycle/8.2/wb_help/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Workbench_ES&file=000812.html.
Use a direct assignment in the XPath expression to convert the String into a Date variable.
If you are using a proxy between Workbench and the LiveCycle ES Server, you may want to limit the connection to provide a higher level of security. For the standard installation Workbench communcates with the LiveCycle server over HTTP with servername and port number as follows:
Using a proxy server, you could limit the connection further to just two URLs:
This is subject to change, especially in later versions and must be tested thoroughly to ensure there are no conflicts or unexpected problems. Adobe will investigate issues related to such a configuration but in some cases the only solution may be to return to the default settings, without limiting the connection to specific URLs.
When you have migrated from LC7 to ES and you setup the LDAP Search component (with the refresh or build buttons), you receive the following error:
Cannot instantiate class com.sun.jndi.ldap.Ldap.CtxFactory
The initial_context_factory parameter (in the deployment settings of this component) has been changed during the migration process by mistake from null to com.sun.jndi.ldap.Ldap.CtxFactory.
Change this parameter to the correct value: com.sun.jndi.ldap.LdapCtxFactory.
When a null value was used in LiveCycle 7, the server interpreted it as com.sun.jndi.ldap.LdapCtxFactory by default. This no longer happens in LiveCycle ES, so you cannot use null values for this parameter.
More information about the mapping of the LDAP Search component in LiveCycle ES can be found under:
If you are attempting to upgrade a LC7 process in Workbench you may encounter the following error related to a SetValue QPAC:
None (Error finding upgrades: org.xml.sax.SAXParseException:
The processing instruction target matching "[xX][mM][lL]" is not allowed.)
The SetValue QPAC is not upgraded, but other QPACs are upgraded successfully to LC ES components.
The error is caused by the presence of the XML declaration <?xml version=”1.0″ encoding=”iso-8859-1″?> at the start of an XPath value in a SetValue expression. The upgrade tool cannot handle this XML declaration correctly and throws the error. If you remove this XML declaration manually before upgrading the process, it will upgrade successfully.
This issue is fixed in Workbench ES2. There is a patch available for LC Workbench ES 22.214.171.124, so you can contact enterprise support if you require this patch.
After upgrading a process from 7.x to 8.2 in workbench, the value expressions that existed in the 7.x SetValue activity no longer exist and appear as blank assignments in the 8.2 SetValue activity.
7.x SetValue Settings:
/process_data/myXMLVar = '<node>value</node>'
/process_data/myStringVar2 = 'test string'
/process_data/myXMLVar3 = '<node>value</node>'
8.2 SetValue Settings (post upgrade):
/process_data/myXMLVar = ''
/process_data/myStringVar2 = 'test string'
/process_data/myXMLVar3 = '<node>value</node>'
The upgrade appears to be removing XML based strings (unless escaped).
This is a bug in LC 126.96.36.199 and is caused by the loss of XML data encoding:
- encoded XML attribute values are read from the input process action template and decoded during read by Xerces
- decoded values are rewritten as XML elements (not attribute values) and never re-encoded.
- the subsequent symptom is that the unencoded XML data is (rightly) interpreted by an XML parser, but should have been interpreted as text data.
This issue will be fixed in Workbench ES2. There is a patch available for LC ES 188.8.131.52, so contact enterprise support if you require this patch.
When working with namespaces in the SetValue and Script objects in LC7, you may receive an error saying the “path” is unreachable, or similar errors pointing to problems in the expressions, after migrating to LC ES.
These errors can occur in LC ES when using namespaces such as in the following example:
LiveCycle ES now validates XPath expressions more strictly than it did in LiveCycle 7. LC ES requires you to define the namespaces in the process, whereas Lc7 did not have this requirement.
Adding the namespace to the process properties will fix the issue. You only need to add these namespaces once for each process, and all the Script and SetValue activities in that process will be able to reference those namespaces.
To add the namespaces:
Open the process properties and go to the Advanced > Registered Prefixes for Namespaces used in XPaths and enter the prefix (i.e. soap), and the namespace (i.e. “http://schemas.xmlsoap.org/soap/envelope/“).
When importing a LC7 process map into Workbench, you may have some graphical display problems, where certain activities are running off the viewable area in the process editor panel. You can see the route lines leaving the page in Workbench and returning but you cannot access the activity, and so, cannot change it’s properties or move it back onto the page.
Here is an example of the problem on the process editor where you can see the route lines going outside the viewable area and coming back in, but you cannot see the related activities:
It can occur that the “x” and “y” position for some activities become negative during the import process. These values define the positions on an x-y axis, and so, if they are negative, they will not appear in the viewable area in Workbench. This is a product bug in Workbench ES.
This issue has been fixed in Workbench ES 184.108.40.206, 220.127.116.11 and later versions of Workbench. For Workbench ES 18.104.22.168 there is a patch available. Please contact your Adobe support contact if your require the patch for 22.214.171.124.
The other option (although not recommended) is to modify the process XML, and just remove the minus sign from the x and y values as required. Be sure not to change the “x-offset” or “y-offset” values. These are relative values, and so, can be negative.
If you install the patch or are using a later version of Workbench then the values will be restored correctly. Here is the result of making the manual changes in the process XML for the gateway activity, bringing it back onto the viewable area:
When running the Upgrade Tool in Workbench to upgrade a LiveCycle 7 process to a LC ES orchestration, you may receive the following error:
java.lang.RuntimeException "Branch: <Name> already exists"
When working with Split activities in LiveCycle 7 it was allowed to have duplicate branch names in the list of branches for a particular Split activity. For example:
In LiveCycle ES however, this is no longer allowed. All branch names must be unique
This issue has been fixed in Workbench 126.96.36.199, 188.8.131.52 and later versions. There is a patch available for Workbench ES 184.108.40.206. You should contact Adobe support if you require this patch.
The fix now handles the duplicate branch names by appending an index onto the branch names, for example:
When trying to upgrade a LC7 process in Workbench, which is working fine under the LC7 compatibility layer you may receive an internal error in the upgrade report, with the following exception in the detail dialog:
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.copyOutRoutes(Unknown Source)
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.copyRouteInformationToBranch(Unknown Source)
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.processBranch(Unknown Source)
at com.adobe.lcide.upgrade.lc8.dom.impl.ProcessRepositoryImpl.orchestrateProcess(Unknown Source)
at com.adobe.lcide.upgrade.lc8.app.UpgradeEngine.performUpgrade(Unknown Source)
at com.adobe.lcide.upgrade.lc8.pres.wizard.page.UpgradePageModel$UpgradeJob.run(Unknown Source)
This will be related to a particular QPAC in the process which does not have the correct mapping file for the Upgrade Process Tool. The report will show you on which QPAC the exception occurred, or you can remove each QPAC from the process one after the other, and re-test to isolate the problem QPAC.
Once you know what QPAC causes the issue, you should ensure you have the current upgrade mapping file for that QPAC loaded in Workbench. If the QPAC is from another vendor, then contact that vendor for the latest mapping file, and load it into Workbench under Preferences -> Upgrade Process Tool.
When opening Workbench after migrating from LC7, or after manually deploying many LC7 QPACs in the LC7.x components view, you may receive the following error:
Caused by: java.lang.OutOfMemoryError: Java heap space ; nested exception is:
java.lang.OutOfMemoryError: Java heap space
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationConte xt.java:1087)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
This may be accompanied with internal errors in Workbench, or other memory warnings and messages.
The OutOfMemoryError occurs as the server is loading all of the LC7 component configurations at the same time and sending all of this information to the Workbench client. It cannot handle this amount of data at one time, and so, throws the memory errors. The server may also be hitting some memory limitations depending on the heap size and platform (i.e. weblogic uses a lot more RAM than JBoss).
This issue has been fixed in Workbench ES 220.127.116.11 and later versions. There is a patch available for both the server and workbench 18.104.22.168. You should contact Adobe support if you require this patch.
The patch will expose a new parameter in the workbench.ini file to control the pageSize for the communication between the LiveCycle server and Workbench. You can check this parameter in <Workbench_Home>/Workbench/workbench.ini. The parameter should be set to 3 to resolve the OOM situation:
After making any such changes to the configuration of Workbench you may need to start Workbench cleaning out the temp files. You can do this by starting Workbench from the command line from the directory listed above using the -clean console command line switch.
You should also try increasing the JVM heap size for both the server and Workbench, and run Workbench on a separate machine to the LiveCycle server, if you are not already doing so.