A warning about changing the default Super Administrator password

aem_warningOne thing you should always do in your production instance is change the default passwords. Everyone does that right? riiiight

Well when you decide to change the default Super Administrator (administrator) password in AEM Forms Workflows 6.1 or 6.2 there is an unexpected side effect. After changing this password you would notice that it works fine when you test it so you go about your other tasks. Then you will notice that after a period of time you are automatically locked out!

Under the hood, there is an OSGi service that links the OSGi CRX instance to the JEE instance. This is called the Adobe LiveCycle Client SDK Configuration. This service constantly attempts to log into the JEE instance and do stuff. If you change the default administrator password, and don’t change this password, this service will lock your Super Administrator account out.

Great. How do I stop this?

It’s easy. Just open the OSGi system console and change the password in the configuration screen. You can open the config item directly from a browser. e.g.



Ok…I’m already locked out. Now what?

The default unlock time is set to 30 minutes after 20 incorrect attempts, so you can change the OSGi password and wait 30 minutes…or you are super impatient like me and can bust out some SQL-fu.

Remember the password you set on the database when you installed the instance? You’re going to need that now. Don’t remember it? Sorry – you now have to wait. Go browse Reddit for a bit and come back…

First, start by installing a SQL editor for your particular database (I’m going to show MySQL since that is in the turnkey edition)

  1. First log in to your MySQL instance using the root account
    Manage Server Connections_mysql.png

2. Then enter the password by clicking Store in Vault… (this is the password that you used when you installed the instance). Click OK


3. Click Test Connection


4. You should see a couple of adobe database instances (these will be the database names you specified during setup) I usually call mine ‘adobe’ or ‘adobe_wf’


5. Now locate the Super Admin account using the following SQL:

SELECT * FROM adobe.edcprincipalentity where canonicalname = 'SuperAdmin';

6. You should see the column countauthfailure has a number > 20 and islocked is set to 1 (locked)


7. Now you can either use the GUI to change the value or run the following SQL:

UPDATE adobe.edcprincipalentity 
SET islocked = 0 
WHERE canonicalname = 'SuperAdmin';

8. You should be able to log in to your Super Administrator account now

Its probably a good idea to create a second Super Administrator account just in case this happens again.


Adaptive Forms reserved words

There are a number of reserved words that you should not name your form elements in your Adaptive Forms. It is also suggested you should not use them in your schema for element or attribute names.

As a rule of thumb:

  1. Any property that is defined on the panel should not be used as the name of an element. Because that will restrict access to that property and lead to problems in the code. Examples (case-sensitive)
    1. panel
    2. repeatable
    3. toolbar
    4. instanceManager
    5. title
    6. summary
    7. enabled
    8. visible
    9. id
    10. name
    11. children
    12. items
    13. bindRef
    14. shortDescription/longDescription
    15. index
    16. any other API mentioned in https://helpx.adobe.com/aem-forms/6-1/javascript-api/Panel.html
  1. Some other words that are used in the generated script should not be used in the scripts or element names. e.g.
    1. Calculate
    2. Visibility
    3. Enabled
  2. You should not have field names starting with _, to prevent future name collisions with any of Adobe’s private APIs.

Edit: It wasn’t related to the schema elements per se, but the ‘elements’ in the adaptive form. Since dragging a schema object onto the form automatically names the form element the same name as the schema element or attribute, the form will stop working.

Edit 2: Ok it seems that naming your schema elements and attributes any of the above is aactually not recommended.

CRXDE Lite code formatting


One thing I always missed in CRXDE Lite was the lack of any code formatting tools. I always had to copy the code out into Notepad++ or Eclipse to format the code and then paste back into my JSP files. Not very convenient.

Today I accidentally stumbled across what I expect is an undocumented feature in CRXDE Lite – Code Formatting!


If you select any or all of the code on a page, and then hit Shift-Tab, it doesn’t tab the code back one tab stop (as you would expect), it actually formats the code.






This was done with CRXDE Lite in CRX 2.4.23 (CQ that comes with Adobe Livecycle ES4.  It seems to work in Chrome, Firefox and Intenet Exploder 10.

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)




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