This example shows you how the various parts of the mediation policy model interact, in a specific case.
The following example shows an SCA module, called applyDiscountPolicy, that receives messages containing the age of a ticket buyer. Mediation policies are used to retrieve the ticket discount that should be applied.
To achieve this design, the integration developer creates an SCA module that has one mediation flow component and one property group. The mediation flow component contains one Policy Resolution mediation primitive, which has one dynamic (promoted) property: discount, and one condition (Policy condition name): age. The condition has an XPath of: /body/input/age (which tells the run time whereabouts in the message the condition can be found). In addition, the mediation flow component contains two other mediation primitives: one to do a database query and one to process the output from the database query.
When the SCA module is exported, WebSphere Integration Developer creates one default mediation policy (because there is only one property group).
When the WSRR administrator loads the SCA module, the SCA module is loaded together with the default mediation policy. The WSRR administrator then creates two new mediation policies, both of which contain the discount property; and attaches the default mediation policy and the two user-defined mediation policies to the SCA module. Finally, the WSRR administrator creates conditions for the user-defined mediation policies. One mediation policy can only be used for people over the age of 59, and the other mediation policy can only be used for people under the age of 12.
At run time, the SCA module receives a message and queries the WSRR instance that has been loaded with the applyDiscountPolicy module, and its default mediation policy.