Log file viewer for Workbench

LCLiveCycle Workbench includes a Server Log Viewer by default but sometimes you want to view multiple log files and have syntax highlighting to help you debug your applications while you work on your LiveCycle application. I also found the built-in viewer extremely limited and it didn’t always tail the server.log file properly and also required you to be logged into LiveCycle to use it!

Eclipse Labs logviewer

For both Eclipse and Workbench I use the logviewer Eclipse plugin to look at any log files I am generating during development. It’s simple, very configurable, has syntax highlighting and allows you to open multiple files at once.


Wizard Install

Installation is simple since Adobe left in the Eclipse Software Updates feature:

1. Open Help > Software Updates > Find and Install…

Find and Install...

Find and Install…

2. Select Search for new features to install then Next >

Search for new features to install

Search for new features to install

3. Click New Remote Site… and copy the Update Site URL from the logviewer page and click OK

New Update Site

New Update Site



4. Click Finish then Select logviewer feature checkbox and then click Next >

Select logviewer feature

Select logviewer feature

5. Select I accept the terms in the license agreement and Next >, Finish then Install All

Feature License

Feature License



Feature Verification

Feature Verification

6. Click Yes  to Restart Workbench

Restart Workbench

Restart Workbench

7. Once Workbench has restarted, click Window > Show View > Other…

Show View

Show View

8. Select Log Viewer plugin from within its folder and click OK

Log Viewer Plugin

Log Viewer Plugin

9. Enjoy a decent log viewer / file tailer with plenty of features!

Bonus: you don’t even need to be logged into LiveCycle to use it…

Log Viewer action shot

Log Viewer action shot

Manual Install

If the install above is all too hard or you are a manual-eclipse-plugin-installer-kinda-developer, then:

1. Copy the latest Jar from here: http://logviewer.eclipselabs.org.codespot.com/git/de.anbos.eclipse.logviewer.update/plugins/

2. Bung it in the Workbench plugins folder (probably something like C:\Program Files (x86)\Adobe LiveCycle Workbench ES4\workbench\plugins)

3. Start Workbench and tail away…


Enable JDBC testing

JDBCOne useful feature of Workbench is the ability to test your SQL statements directly from the JDBC activity editors.  However, since ADEP / ES3, this feature was turned off by default in Livecycle. Fortunately, it’s very easy to re-enable this feature.


Disabled by default

Disabled Test Feature

Disabled Test Feature


Steps to enable

1. Open AdminUI and browse to Home > Services > Applications and Services > Service Management and filter services by typing jdbc into the name field

Service Management

Service Management

2. Click the JdbcService 1:0 link

3. Check the Enable Testing checkbox and click Save

Enable JDBC Testing

Enable JDBC Testing

4. Go back into Workbench and the Test button should now be enabled

Enabled JDBC Testing

Enabled JDBC Testing

Generating useful current-dateTime() values

setvalueOne common operation that you find yourself doing as a developer is time-stamping various operations. Creation DateTime, Save DateTime or Submission DateTime values are very useful when processing data. However, in Livecycle there are some small gotchas when dealing with system generated dateTime strings that they don’t make you aware of.

current-dateTime() default Timezone

Even in the latest help file for current-dateTime() XPath function, they don’t tell you that when you make a call to this function, it will always return the time string as GMT+0 no matter what timezone the server is running in. Now this is fine if you live in London, Burkina Faso or Tórshavn but no good if you live anywhere else in the world.

Adjusting the default

Adjusting this value to your default timezone is fairly easy as the format-dateTime() function does this for you if you feed it right. You just need to know what values to put in for the four optional fields and how to source them. Adobe give some help to the values on the Date and Time parameters help page and I will demonstrate using format-dateTime():


format-dateTime(strDateTime, (language, country, variant, timezone)?)


So, to get the real current-dateTime() string for an application based in Auckland, New Zealand you would do the following:

format-dateTime(current-dateTime(), "en", "NZ", "WIN", "Pacific/Auckland")


Move Workbench application storage location


By default, Workbench stores any Applications that it retrieves from the LiveCycle server into your user profile directory. In some circumstances this isn’t ideal. Maybe you have a domain policy that restricts your profile space or you want them stored on a network drive so they are backed up.

As Workbench is just eclipse, you can move the workspace folder wherever you want, but Adobe disabled the menu items to do this in the GUI (because you would never want to change your workspace directory ever – right?)

Just add this line to the workbench.ini file (usually located in the C:\Program Files (x86)\Adobe LiveCycle Workbench ES4\workbench folder – or wherever you installed Workbench)




LiveCycle configuration parameters – Part 1

What is a configuration parameter?

LiveCycle configuration parameters are one of the most useful and overlooked tools in the Enterprise LiveCycle developer’s toolbox. Simply put, they allow you to edit application variables from the Administration interface (AdminUI) to directly apply to the application you have developed and deployed to the LiveCycle server. This allows you to easily make changes to the application after deployment without having to change, re-deploy and test the application.

Configuration parameters (Adobe Docs)

Why would I use one?

1. Best Practices

As a developer, it is always good practice to make your applications as highly portable and uncoupled from the environment as possible which, in practice, means never hard-coding properties like directories, usernames, passwords, URI’s, etc. that your application may use during run-time. There are limitations in every environment that make this unavoidable in practice (LiveCycle is no exception here) but as a general rule, you should never hard-code any configuration or environment properties in your application.

2. Change Control

In an environment that has a very tight change control process in place this can be invaluable. Raising a change request for an application configuration change is always an easier prospect than one requiring a new build version.

When should I use a configuration parameter?

Configuration parameters should always be used where something could possibly change in the environment that you have deployed your application into.

Some examples:

  • Directories – Document Output, Input, Logs, Failures, Watched Folders, etc. Anything in your process or linked DSC that refers to a local or UNC directory should always be set as a configuration parameter.
  • Usernames and Passwords – Any secure environment should change important passwords regularly. Consequently, these should never be hard-coded in any application.
  • External URI’s, Web Service endpoints, etc. – Any external calls that are not internal to the application should be a configuration parameter.

How do I implement a configuration parameter?

During development you can elect to make any variable a configuration parameter simply by selecting the Configuration parameter radio button when you create a new variable in Workbench:

Example Configuration Variable

Example Configuration Parameter

When you select the Configuration parameter radio button, you will notice a few things happen. Enduser UI Items section disappears, meaning you can no longer search or interact with the variable in Livecycle Workspace. Also, and more importantly, your available variable Type list becomes smaller. The only types available for a configuration parameter are:

  • Boolean
  • Integer
  • Short
  • String
  • Long

Setting a Default Value is highly recommended during development so you don’t need to constantly open AdminUI and set the parameter properties after you deploy the application.

Likewise, it is recommended to set a descriptive Title parameter as this is the text that will appear in the AdminUI page. If you don’t use a Title the Name of your variable will appear (strOuputDirectory in this case). As a competent developer you are already supplying adequate variable Titles and Descriptions in all of you applications anyway …right?

Once you have created the configuration parameter, you use it as you would any other variable you create in your processes. Updating the variable during the process does not change the default setting in the application.

For example:

Using the Configuration Parameter

Using the Configuration Parameter

To modify the Configuration parameter once you have deployed the application is easy. Just log in to the LiveCycle AdminUI and browse to the Application and the Process you created the variable in:

Changing configuration parameters in AdminUI

Changing configuration parameters in AdminUI

Now whenever you update the configuration parameter via the AdminUI, your application will automatically use the new value for strOutputDirectory and change the location of where your PDF’s are saved. All without opening the application, finding where the path is used, modifying all instances of the path, redeploying and testing.

Stay tuned for Part 2 – I will describe a practical way to organise your configuration parameters within an application you might create in the enterprise.

Increase Workbench Timeout

This is a simple one. If you hate being logged out every 2 hours while you are using Workbench, just edit the Session Timeout Limit in AdminUI. Apparently there was a bug with Livecycle ES 2.5 and below that didn’t allow this to be changed, but it seems to work in ES3/ADEP and above.

Increase it to the maximum (1440 minutes) and you wont get logged out during the day.

Session Timeout Limit (Minutes)

Session Timeout Limit (Minutes)

WSDL URL and WebServiceSettingBean

Invoke Web Service Icon

I recently discovered an issue in two concurrent projects that presented an interesting problem. The reason I have never seen this before is probably because I have never tried to use the Invoke Web Service activity in Livecycle before for a production system. It’s a simple enough activity with all of the usual parts to it and on the outside seems to work fairly well especially during development. The issue doesn’t present itself until you try to prepare it for deployment to multiple environments. I will try to explain (stick with me here)


In a typical environment you will configure system values that change via configuration parameters. This allows you to package an LCA up for deployment to another system and set the configuration parameters after deployment for that system. In any normal business you usually find a number of environments, for example, Development, Test (or SIT – system integration testing), UAT (user acceptance testing) and Production – all quite typical.

Getting back to the Web Service activity, you notice that in the first page that a number of the useful items like username, password, targetUrl, etc are all configurable via XPath which in turn allows for a configuration variable to be used here. But strangely, Adobe have left out XPath for WSDL URL.

WebService Settings Dialog

WebService Settings Dialog

Why is this a problem?

If WSDL URL is hard-coded and you try to migrate the application to another server, every time your InvokeWebService activity is called, it will try to call the original hard-coded WSDL URL for that activity during execution. So if your web services follow the same deployment pattern as your Livecycle applications i.e. DEV > SIT > UAT > PRD, when you execute the activity in your SIT environment, the DEV WSDL will be loaded by Livecycle before it is invoked. Which if it is unavailable, causes the whole activity to fail. So you can see that once it hits PROD and someone brings down the DEV web services for whatever reason, the PROD instance will fail.

Why is this built like this? Who knows. How do we work around it? Read on…

The hack (sorry – undocumented workaround)

Inside the activity, if you change the InvokeWebService activity Options parameter to a variable type you will notice that it accepts a WebServiceSettingBean as input.


InvokeWebService Options

A quick Google of the bean name and you get a few scattered posts on Adobe forums asking for help on parameters but no complete guide on how to use it or what all of the parameters are. It’s because no public API exists for this bean. You can use the object inspector after creating a bean variable and see what the bean parameters are but it crucially won’t tell you what the variable types are. Below is a full list of the variables it accepts and their types:


  • String wsdl
  • String username
  • String password
  • String port
  • String portBindingLocalName
  • String targetUrl
  • String operationName
  • String timeOut
  • String inputRequest (or org.w3c.dom.document – haven’t tried this)
  • String inputRequestTest
  • List (com.adobe.idp.Document) attachments
  • Map<String, String> wsdlMap
  • boolean enableMTOM
  • boolean authenticatePreemptively

Most of the above parameters can be figured out from the InvokeWebService activity component, but some I had to play with to get it to work properly.

  • portportBindingLocalName must be set to the actual web service portBindingLocalName otherwise you will get the following error:
2013-07-16 13:51:26,214 ERROR [com.adobe.workflow.AWS] (http- An exception was thrown with name com.adobe.idp.dsc.webservice.exception.WebServiceConfigurationException message:Configuration error - port specified is unavaliable:  while invoking service WebService and operation invoke and no fault routes were found to be configured.

note: The portBindingLocalName is never shown in the WebServiceSettingBean editor. There are two ways to find it:

1. Look into the WSDL xml and you will see:

 <wsdl:binding name="[portBindingLocalName]" type="...">

2. Use a soap tester like SoapUI that shows the binding name when it sets up the WSDL.

How to find the portBindingLocalName


The steps

1. Create a WebServiceSettingBean variable and assign it as the input Options for the InvokeWebService activity.

Create WebServiceSettingBean

Create WebServiceSettingBean

Select WebServiceSettingBean type

Select WebServiceSettingBean variable type


Set Activity Options

2. Create a simple process that maps all of the bean parameters from input variables to create the bean. This also allows you to use template parameters for the inputRequest that use embedded XPath.

CreateWebServiceSettingBean process

CreateWebServiceSettingBean process

3. In your process, call the Create Settings Bean process where you set all of the Bean variables, then call the InvokeWebService activity using the Bean created in #2 as input.

Main Process

Main Process


I have provided an example application so you can see the workaround in action. It creates an example WSDL that it calls itself to show how the settings are applied to the bean and then invoked. Adjust the server name and port and administrator account details as necessary. They are all default for a turnkey ES4 install.



SoapUI example

SoapUI example

Easily the best way to create your inputRequest and get the portBindingLocalName is using SoapUI. Using the Generate button in the activity doesn’t give you all of the input variables for the WSDL you are accessing. Plug the WSDL URL into SoapUI and you will get a proper view of the WSDL request query so you can XPath it as necessary.


Beware of the ?blob=base64 bug in later version though. I will do a post to highlight this issue in the future. For now I use version 3.6.1 for most of my work.


Everything AEM aka CQ5 based on my experience listed here.

Adobe AEM The Right Way

Best practices, tips, and tricks for your Adobe AEM project


A WCM journey with Day/Adobe CQ

Technoracle (a.k.a. "Duane's World")

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Adobe LiveCycle Blog

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.


A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Code Monkey

Ramblings of a Developer