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

Advertisements

About Darren
I am a Senior Consultant and for BizTECH Enterprise Services (Australia) specialising in AEM Forms and Adobe LiveCycle, Document Services and Adobe Experience Manager.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

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

%d bloggers like this: