IBM BPM, V8.0.1, All platforms > Programming IBM BPM > Enterprise Service Bus programming > Mediation flow with mediation policy

The mediation policy resolution process

The mediation policy resolution process draws together the mediation policy concepts and describes the parameters that can be set on the Policy Resolution mediation primitive.

A mediation flow, built in IBM Integration Designer, contains a Policy Resolution mediation primitive and some downstream mediation primitives with promoted properties. A .ear file is generated from the mediation module and deployed to IBM BPM. The .ear file is also imported into WSRR and mediation policy gate conditions are applied to the properties. When a message passes through the mediation flow, at the Policy Resolution mediation primitive WSRR is checked to see whether any policy documents associated with the mediation module have gate conditions that apply to some aspect the current message. If so, information about the properties and the values to be set are extracted from the policy document and written into the dynamic property context area of the SMO. Any downstream mediation primitives that have promoted properties that correspond to items in the dynamic property context area of the SMO will be updated with the appropriate values.

Policy Resolution mediation primitive settings

You can use several parameters to configure the Policy Resolution mediation primitive.

Registry Name

The Policy Resolution mediation primitive needs to query WSRR and therefore the mediation primitive must know how to communicate with WSRR. WSRR definitions can be created in the IBM BPM administrative console (Service integration > WSRR definitions), which define how IBM BPM can communicate with WSRR instances. If only one WSRR definition is created, that definition becomes the default registry and the default value for the Registry Name field, <Use default registry>, uses that WSRR instance. If you do not want to use the default you can specify the actual name of the WSRR definition created in the administrative console.

Policy Scope

The default behavior for the Policy Resolution mediation primitive module is to search for mediation policies that are attached to the module containing the Policy Resolution mediation primitive. The mediation flow module containing the Policy Resolution mediation primitive must be exported as a .ear file and loaded into WSRR as an SCA module for the function to work.

An alternative use is for the mediation primitive to search for mediation policies attached to a Target Service; that is, a service to which the mediation containing the Policy Resolution mediation primitive is going to call out. Information about the target service must be loaded into WSRR and the service must have mediation policies attached to it.

You can load target service information into WSRR in several ways. One way is by using WSDLs that describe the service or by loading an SCA module. In Target Service mode the Policy Resolution mediation primitive looks at the /headers/SMOHeader/Target area of the SMO to determine which entity to check for policy attachments. Although you can set this area of the SMO manually (using a Message Element Setter mediation primitive), it is generally set by a Lookup mediation primitive (such as an Endpoint Lookup, Gateway Endpoint Lookup or SLA Endpoint Lookup), which obtains the target information for the current message context from WSRR.

There are three different scopes that policies can be attached to within the Target Service scope. A policy can be attached to the whole service, it can be attached to a particular endpoint (the port of a WSDL) or it can be attached to a particular operation.

If both Module and Target Service policies are available in WSRR then the mediation primitive can use the Intersection of Module and Target Service, which combines both module and target service mediation policies.

Conditions

You can create policy conditions to apply mediation policies based on the message context. By creating policy conditions you specify a part of the message whose value is then used to evaluate a gate condition, the result of which determines whether a specific mediation policy must be applied in this particular message context. The gate condition is created in WSRR and is applied to a policy attachment on the SCA module. To create a policy condition first specify a policy condition name. Creating a policy condition is important because it is the name that will be used in the gate condition in WSRR.

Next, the part of the message that provides the value to be used in the gate condition is specified using an XPath expression. An optional description of the condition can be provided.

For example, if the message element that provides the context for varying the flow is the customer type you might set:

Policy condition name

CustomerType

XPath

/body/custRequest/Customer/type

A downstream mediation primitive might have a promoted property with an Alias LogRoot and Alias value /body to specify how much of a message to log. This policy condition becomes the default policy document for the mediation module when it is loaded into WSRR.

In WSRR you can create a policy document that sets the value of the downstream promoted property LogRoot to a value of /body/custRequest/Customer. This new policy can then be attached to the SCA module containing the Policy Resolution Mediation primitive, which has been loaded into WSRR. A gate condition can be added to this policy attachment with a condition CustomerType=”Premium”.

The gate condition checks the value associated with the condition name CustomerType, which in this case is the message value at /body/custRequest/Customer/type, against the value given in the gate condition definition ("Premium").

If the condition evaluates to true then this policy can be applied; if not, the policy is not applicable in this context.

For this example, a message containing the body /body/custRequest/Customer/type=”Premium” would cause a downstream mediation primitive with a promoted property called LogRoot to take the value /body/custRequest/Customer, but for other messages the LogRoot promoted property would take the value /body.

Propagate mediation policy to response flow

When a Policy Resolution mediation primitive detects a policy appropriate to the current message context, that mediation primitive writes the details of what is to be set (the promoted property alias name and its value) to an area of the SMO context called the Dynamic Property Context. By default this area of the SMO context is cleared as soon as the request flow completes. There might be mediation primitives in the response flow that have promoted properties which can be affected by policies accessible to this Policy Resolution mediation primitive. Selecting the Propagate mediation policy to response flow box ensures that the dynamic property context is not cleared when the request flow is completed, and that it is available in the SMO during response flow processing.

Classification URIs

WSRR can be used to govern the way that services are used.

For example, a service might go through lifecycle phases Development, Test and Production, and WSRR can apply these lifecycle classifications to the service during the appropriate phase. WSRR can then apply rules about how the service is to be used based on the current classification. Classifications can be applied to policy documents in the same way.

The classifications are encoded as URIs.

For example:

Development: http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Development

Test: http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Test

Production: http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Production

For example, in the policy resolution mediation primitive you can add the Classification URI for the lifecycle phase Development. This means that the mediation primitive obtains policies from the policy document only if it also has the Development classification attached to it.

Mediation flow with mediation policy

Related concepts:
Mediation policy concepts
Mediation policy usage scenarios

Related tasks:
Applying policies using Business Space