SLA Check mediation primitive

Use the SLA Check mediation primitive to check that a service level agreement exists.

Introduction

You can use the SLA Check mediation primitive to check that a service level agreement (SLA) exists.

A message that is being mediated can be routed to a target service. Whether the consumer of this target service has a service level agreement in place to use the service can be enforced using the SLA Check mediation primitive, which checks that the correct SLA exists in WebSphere® Service Registry and Repository (WSRR).

The SLA Check mediation primitive has one input terminal (in), one fail terminal (fail), and two output terminals (accept and reject). The in terminal is wired to accept a message and the other terminals are wired to propagate a message. If the information passed on the incoming message is used to successfully find a matching SLA in WSRR, the accept terminal is fired. However, if a matching SLA is not found, the reject terminal is fired.

Usage

In order to find a matching SLA in WSRR, the SLA Check mediation primitive uses information in the incoming message. The SLA is matched on three parameters:

Endpoint. This field can be a literal value, or can be passed as part of the message, and identifies the target endpoint that the consumer wants to call. This field is mandatory, if not set, the reject terminal is fired.
Consumer Identifier. This field can be a literal value, or can be passed as part of the message, and identifies the consumer of the target endpoint. This is an optional field depending on whether the relevant artifacts in WSRR have the identifier defined. If a value is specified for the consumer identifier of the capability version in WSRR, the value specified for the Consumer ID property must match it exactly; if no value is specified then the Consumer Identifier property must be left empty. For more information, see the WSRR documentation about the governance enablement profile.
Context Identifier. This field can be a literal value or can be passed as part of the message and identifies the context under which the consumer's invocation of the target endpoint occurs. If a value is specified for the context identifier of the service level agreement in WSRR, the value specified for the Context Identifier property must match it exactly; if no value is specified then the Context ID property must be left empty. This is an optional field depending on whether the relevant artifacts in WSRR have the identifier defined. For more information, see the WSRR documentation about the governance enablement profile.

Note: If you are using a WSRR Version 8.0 governance enablement profile, this mediation primitive behaves differently to that in previous versions. The SLA Check mediation primitive uses a WSRR named query called SLACheck. In a query that uses the WSRR Version 8.0 profile only service level agreements that are in the active state are considered. Also, the service level definition of the provider must be in the subscribable state. The new behavior ensures that the WSRR objects that are being considered have reached a suitable level of approval. If you want to reproduce the behavior of previous versions, where these states were ignored, you can choose either of the following options:

Continue to use the same governance enablement profile you used on a previous version of WSRR.
Modify the named query on the supplied WSRR Version 8.0 profile by completing the following steps:
1. Log onto the WSRR by using the web user interface.
2. Change to the Configuration perspective.
3. Go to Active Profile > Named Queries.
4. Select SLACheck.
5. Replace the <xpath> query with the following code:
```
<xpath>/WSRR/GenericObject[classifiedByAnyOf(., 'http://www.ibm.com/xmlns/prod/serviceregistry/profile/v6r3/GovernanceEnablementModel#CapabilityVersion')and @gep63_consumerIdentifier='%1']/
		gep63_consumes(.)[@gep63_contextIdentifier='%2' and gep63_agreedEndpoints(.)/
		gep63_availableEndpoints(.)[@name='%3']
</xpath>
```
6. Select OK.
The new named query is now active.