Binding Expressions in MDW

Binding expressions are everywhere in MDW. For example, when a workflow process uses a subprocess activity to invoke another process, it can assign values for the subprocess's input variables through binding expressions. Generally, for activity attributes in MDW Studio, binding expressions can be used where a dynamic value is required from the runtime environment. Other examples where expressions are used to embed dynamic values include:

• Activity Attributes
• Notification Templates

Although MDW supports multiple scripting languages for data binding expressions, the preferred syntax is the standard Java Expression Language.

Evaluation Context

In most cases the evaluation context for an MDW Java EL expression is a runtime context for a process, activity or task. In this context your process variables are available as top-level entities, or they can be the base for further evaluation:

    ${productType}
    ${customer.name}
    ${mySuit == 'hearts'}
    ${myVar}_hardCodedSuffix

Besides process variables, certain other runtime values are available for binding. In fact the RuntimeContext itself is implicitly bound as context, so through this you can access any values described by the javadocs for the relevant context:

• ProcessRuntimeContext
• ActivityRuntimeContext
• TaskRuntimeContext
• MockRuntimeContext

As an example, if for whatever reason in your document web service adapter you wanted to point the URL to the Employee.wsdl endpoint hosted in the same MDW environment, on the Design tab for this activity in MDW Studio you could specify:

  ${context.servicesUrl}/SOAP/Employee.wsdl

In a more likely scenario, suppose you're invoking the Employee service at an endpoint specified in your configuration file as employee.service.url. In that case you can take advantage of the props shortcut access:

  ${props['employee.service.url']}

Document Variables

MDW document variables are available as full-blown objects in your expressions. For instance, if you have a JAXBElement variable named order in your workflow based on the DesignOrder XML, you can access the orderNumber element as follows:

  ${order.orderNumber}

Note: Do not try this type of access through getProcessInstance().getVariables(). For documents this returns only a DocumentReference, which cannot be treated as an object.

When a TaskRuntimeContext is extant, or for notification XHTML templates, document variables which are XML types (JAXB, DOM, XMLBeans) can use XPath syntax to pull values. In this case the above example could be replicated as follows (see the Custom Web and Notifications docs for details):

  ${variables['order']['/orderNumber']}