Often times, one would like to be able to assert some influence over the runtime behavior of a BPEL process even though it is "code-complete". As of now, we externalize certain process properties and wirings in a deployment descriptor known as deploy.xml. However, we stop short of exposing those properties in the BPEL process, which is a known limitation.
What we need is a mechanism to reference properties, which are defined at deploy-time, directly in the BPEL process. To that end, we define a new extension XPath function that returns the node value corresponding to the qualified name of a process property, as shown below:
ode:process-property($name as item() ) as node()
where $name refers to any schema item that resolves to a QName, and
the return node value is the child of the property element with the given name.
Let us consider a scenario where a BPEL process invokes an external WSDL service, whose location is not know a priori. The best way to handle this is to define the endpoint reference (EPR) of that service at deploy-time as a process property. In the BPEL process itself, we reference the EPR property and assign it dynamically to the partner link corresponding to that service. For example, the snippet of deploy.xml below declares a process called "tns:negotiate", which is given a property called "auctionEpr" whose value is set to a BPEL <service-ref> element.
In the BPEL code, the dynamic assignment of the auction service partner link boils down to this statement:
<to partnerLink="auctionRegistrationService" />