Using process variables as constants

A common pattern that’s used in process design is establishing ‘constant’ values that you refer to a few times in the process. To establish a constant value, you either:

  • Create the variable and configure the default value at design time (i.e. in Workbench ES), or

  • Save a value that is either passed into the process or returned by a service operation at run time.


    As an example, I’ll use a purchase request process to describe a simple use of the variable-as-constant pattern. In this process, the dollar amount of the purchase determines who needs to review the request. Purchases of $1000 or less are reviewed by a direct supervisor. More costly purchases are reviewed by a higher-level manager. Here, 1000 is the constant value that is saved in a variable. XPath expressions in routing conditions would refer to this variable to make routing decisions.Configuration Parameters Make Things EasyLiveCycle ES, version 8.2.1 introduced configuration parameters. The values of this special type of process variable can be set in the LiveCycle Administration Console, which means you can change the values in the production environment without having to modify the process. (See Configuration Parameters in Workbench ES Help.)Let’s say, in our purchase request process example, the company changes its policy so that instead of $1000, only $200 purchases can be reviewed by a direct supervisor. If this value is stored as a configuration parameter in the process, all you need to do is log into LiveCycle Administration Console and change the value. You do not need to change the process. (See About applications and services in Applications and Services Help.)Configuration parameters can only be simple data types though (boolean, int, long, short, and string). So you can’t use them with complex data types.Using Constant Values of Complex Data Types Let’s get busy with a more complicated example! We’ll use a complex data type and some Xpath expressions.In the same purchase request process that I described earlier, we now want to set reminders on the tasks that are sent to the supervisor and the high-level manager. We want to give both people the same amount of time to review the purchase request before the reminders occur. Task Reminder values can be used to configure reminders on Assign Task operations. Also, Task Reminder values include Task Date values as data items, which actually set the length of time that passes before reminders occur. So, we can use a Task Date variable to establish the length of time that passes before a reminder occurs as a constant.Here’s one way to do that:1. Create a Task Date variable and configure the default value to be the length of time that passes before the reminder occurs. (See Task Date in Workbench ES Help.)2. Create a Task Reminder variable and configure default values for all of the properties except for the length of time that passes before the reminder occurs. We’ll use the Task Date variable to configure that in the next step. (See Task Reminder in Workbench ES Help.)3. Use the Set Value service to copy the value of the Task Date variable into the Task Reminder variable. We’ll need to add two mappings in the Set Value:/process_data/taskReminderVar/object/reminder = /process_data/taskDateVar/process_data/taskReminderVar/object/repeatReminder = /process_data/taskDateVarSee Set Value in Workbench ES Help.4. Configure the Reminder property of the Assign Task operations to use the taskReminderVar variable. (See Sending reminders about tasks in Workbench ES Help.)Now, if you need to change the length of time that is allowed before a reminder occurs, you only need to reconfigure the Task Date variable. Once that is done, all of the reminders of the Assign Task operations are updated as well.

    VN:F [1.9.22_1171]
    Was this helpful? Please rate the content.
    Rating: 0.0/10 (0 votes cast)

Comments are closed.