LiveCycle configuration parameters – Part 2
July 23, 2013 Leave a comment
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.
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.
2. Create a new XML Schema (XSD) and call it ApplicationSettings.xsd or similar.
3. Add a couple of elements to the Schema, strVersion and strOutputDirectory, both of type xs:string.
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.
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.
6. Add a setValue activity and call it Map Settings and connect it to the Start Point.
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.
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.
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.
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.
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.