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():

Syntax

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

Parameters

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")

 

LiveCycle configuration parameters – Part 2

Implementing an application configuration process using configuration parameters.

What is an Application configuration process?

A typical enterprise LiveCycle application would consist of many assets, including Processes, Schema, Templates, etc. The chance of two or more processes having shared configuration parameters across an application is highly likely.

Read Part 1 – an introduction to LiveCycle Configuration parameters.

Duplicating each configuration parameter across each process is a waste of application assets and also a maintenance headache when you need to update each parameter. It also robs you of precious process variables. Implementing a shared configuration file using XML is always dependent on having the latest version deployed at run-time and also assumes you have access to the location of the configuration file if you want to change something.

An application configuration process is a simple short-lived process that reads in a set of configuration parameters for an application, maps them to an XML schema and passes that variable back to the calling process.

When would you use one?

Typically you would use one if you have two or more processes in a LiveCycle application that shares one or more configuration parameters. These could be directories, usernames, passwords, endpoints, etc. Anything that changes from environment to environment and shouldn’t be hard-coded.

OK – how do I do this?

It’s actually very simple:

1. Create a new short-lived Process and call it ReadApplicationSettings or similar.

Create a short-lived process

Create a short-lived process

Add start points later

Add start points later

2. Create a new XML Schema (XSD) and call it ApplicationSettings.xsd or similar.

Create New File

Create New File

New XML Schema

New XML Schema

3. Add a couple of elements to the Schema, strVersion and strOutputDirectory, both of type xs:string.

Add elements to schema

Add elements to schema


4. Once you have created and checked in the Schema, go back to your new Process (ReadApplicationSettings) and create a new XML Variable. Name it xmlSettings, type of String, “output” checked and Import Asset… and locate the Schema you created in step 2.

Create XML variable

Create XML variable

5. Now create two new variables in the process, strVersion and strOutputDirectory. Make them both of type String and both Configuration parameters. Assign a default value of “1.0” to strVersion and “D:\PDF\Output” to strOutputDirectory.

strVersion

strVersion

strOutputDirectory

strOutputDirectory

6. Add a setValue activity and call it Map Settings and connect it to the Start Point.

Add SetValue activity

Add SetValue activity

7. Now add two XPath mappings to the setValue activity. One for the variable strVersion and one for strOutputDirectory. Assign the XML node on the left and the configuration parameter on the right.

Add SetValue mappings

Add SetValue mappings

8. Save the process and check-in all assets.
9. Create another short-lived process. In that process, create a new variable called xmlSettings. Type is XML and Import the XSD you created in step 2.
10. Now drag down the Sub-Process Activity Picker utility onto the Process (the + symbol) and search for ReadApplicationSettings. Select the Process and add it to this new process.

Pick sub-process activity

Pick sub-process activity

11. In the Output settings for the Activity you just added, set the Application Settings XML variable to be the xmlSettings variable you created in Step 9.

Set activity output

Set activity output

12. Save the Process and Deploy. Done!

Now your configuration parameters you created in the previous process are available via the xmlSettings XML variable in your new process. You are free to do whatever you like with those parameters and no matter how many you add, they still only take up one variable in your process.

13. If you want to test the process, make the xmlSettings variable an Output variable and Invoke the ExampleProcess Process. It should return the settings XML to you from ReadApplicationSettings.

Test Application

Test Application

As you add more configuration parameters, you will need to open your xmlSettings variable and refresh the schema otherwise your schema that is mapped will not contain the latest configuration parameters.

The bonus is, if you add new variables to the schema that are used in one process but not another, you do not need to update the xmlSettings variable in the old process as it will not need it (provided you didn’t remove any configuration parameters). You can do it if you like, but the application will not fail if the Schema in xmlSettings has an old reference.

Accessing the variables at run-time

The other advantage of one process for all of your configuration parameters is that they are easier to find at run-time to change. Just open up AdminUI and browse to the ReadApplicationSettings process and all of the config parameters will be listed on the one page.

Sample application

Download the LCA I used in the example (ES2+)

Move Workbench application storage location

ScreenShot012

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)

-Duser.home=[yourNewPath]

e.g.

-Duser.home=D:\Workspaces\

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)

Problem

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.

Options

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:

WebServiceSettingBean:

  • 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-0.0.0.0-8080-2) 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

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

Options

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

Example

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.

WebServiceSettingBeanTest.lca

SoapUI

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.

http://www.soapui.org/

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.

aemblog

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

/home/bkondepudi

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.

XFA@Mobile

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

Code Monkey

Ramblings of a Developer