Sunday, September 5, 2010

Configuring Technical Policies

Websphere Business Services Fabric v7.0
Contact us...

Configuring Technical Policies

Within the Automated Credit Check process variation we have placed a dynamic assembly component (ChooseCreditCheck) responsible for selecting which credit service to use. To configure this endpoint selection, we will create some policies. Policies created in Composition Studio are not visible to business users using the Fabric authoring space, but the business has specified the following two concerns that are controlled with business policies:
  1. Credit Check Type = whether to use an internal credit check system or to get a fresh report from a third-party credit reporting agency.
  2. Premium Credit Service = whether to require the use of a credit service that offers better data, though probably at a higher cost.

A policy can be thought of as a statement with the following form:
FOR <Policy Target>

From <effective date>
To <expiration date>

When <conditions>

Then <assertions>

Policies do not directly specify a desired outcome, such as the selection of a particular endpoint. Instead, a policy provides 1 or more assertions that establish what must be considered when the policy is enforced. The dynamic assembler, as a policy enforcement point, filters out endpoints that are not consistent with a policy established for the invocation.

Set-In-Context Assertion

A Set-In-Context Assertion specifies a value for a business concept that should be set in the context. When the dynamic assembler sees this assertion in a composite policy, it will establish the specified content dimension with the specified value in the business context before invoking the selected endpoint.

In our example, we have a business –authored policy that sets a value for Credit Check Type (either Internal or Third-Party) in the context before invoking the Automated Credit Check Process Variation.

Notes:

  1. Using Set-In-Context does not allow for forward-chaining in the evaluation of policies for a single dynamic assembly decision. In other words, the assertion impacts the context available for the endpoint that is invoked. It does not cause the system to reevaluate the policies for the current assembly step.
  2. A Set-In-Context Assertion is ignored for the purposes of selecting an endpoint. In fact, this assertion may only be added to policies. The required setting, since it only applies to matching assertions may be ignored.

Using fill from context for a set-in-context assertion would be nonsense since that would direct the system to establish a value in the context that already exists.

Matching Endpoints with Vocabulary-Based Assertions

A Vocabulary Constraint Assertion, or constraint, is used to define an expression that serves as a constraint for endpoint selection. For example, a statement like “the value of Credit Check Type must be equal to INTERNAL” would be expressed with this type of assertion.

A Vocabulary Assertion, or fact, is used to define facts that are considered when evaluating constraints specified with Vocabulary Constraint Assertions. For example, the statement “Credit Check Type is set to INTERNAL” would be represented as a fact.

During the Find Candidates stage of processing, the system first narrows the set of endpoints by eliminating endpoints that do not meet the requirements of the selection policy. Constraints in the policy are compared to facts about the same concept declared via Vocabulary Assertions on the endpoint. If the facts don't satisfy the constraints, the endpoint is rejected.

After filtering the endpoints by selection policy, the system considers constraints on the endpoint against facts declared in the selection policy and eliminates endpoints whose constraints are not satisfied.

Use the required option for constraints. If the assertion is not marked as required on the policy side, the system may arrive at a slightly worse score for an endpoint instead of filtering it out-right. On the endpoint side, a missing required flag will cause the constraint to have no effect on selection. Since facts are not actively involved in filtering, the required flag has no effect.

The Fill from Context option is only available for assertions in policies. When this option is used, it means that the value field for the assertion should use the value for the selected concept as established in the context. In our example, business policies use the set-in-context capability to establish values in the context. We'll be using the fill-from-context option to pick up these business settings endpoint matching purposes.

Next, we'll create our first technical policy. Extending the pseudo-grammar introduced earlier, we want our policy to express:

FOR <ChooseCreditCheck>

WHEN always

THEN Assert the FACT (Credit Check Type is <fill-from-context>)

This policy will cause the business policies that set values for Credit Check Type to play a role in how the endpoint selection decision is made.  

The completed vocabulary-based assertion should look like this when you have completed the steps below ()
  1. In the Business Application Explorer view, right-click the Composite Service\CheckCredit\ChooseCreditCheck DA Component and select New\ Policy from the context menu ()
    When creating a policy, the system will use the selected element as the policy target, if possible. You can also select the target explicitly in the create wizard.
  2. Name = Match on Credit Check.  Click Finish ()
  3. Select the Policy Expression tab of the policy editor and click the Add button to add a new assertion ()
  4. We'll be configuring a fact, so choose Vocabulary Assertion ()
  5. Assertion Options
    1. Required = check
    2. Fill from Context = check
  6. Assertion Property Values
    1. Business Concept = Credit Check Type
    2. Concept Value = Internal (See notes below)
      Sometimes, a validation error will occur if the Concept Value field is not filled. If you see this error, it can be resolved by picking any value for the concept. If fill from context is enabled, the system will always replace any value you select with the active value in the context. However, if no value is supplied in the context, the system will use the value you specified. If a value from context must always be used, set the vocabulary dimension as required in the context specification and the system will never allow the value entered here to be used. On the other hand, if the value will not always be available in the context, make the dimension optional and the value supplied here will be used as a default.
  7. Click OK ()

Creating a Policy to Enable the DA (Dynamic Assembler) to Enforce Business Decisions

Next, we'll create a second policy that will allow the dynamic assembler to enforce the business decision about when to use a Premium Credit service. In pseudo-grammar:

FOR <ChooseCreditCheck>

WHEN Premium Credit Check = True AND New Customer = True

THEN Assert Constraint (Premium Credit Check must equal True)
After you complete the steps below, the resulting policy should look like this ()
  1. Create a second policy (as done above) targeted at ChooseCreditCheck with the name: Premium Credit Checks for New Customers When Needed 
  2. Create a policy expression that looks like the following ():
    AND
            Premium Credit Check = True
            New Customer = True
    1. Right-click inside the Expression canvas and select Add\Operator\AND from the context menu ()
    2. Right-click the AND operator that you previously created and select Add\Condition\Business Concept from the context menu ()
      1. Business Concept = Premium Credit Check 
      2. Comparator = equals sign
      3. Concept Value = check the box 
      4. Click OK ()
    3. Right-click the AND operator again to add a second business concept expression. Fill it in to express New Customer = True
      1. Business Concept = New Customer
      2. Comparator = equals sign
      3. Concept Value = check the box 
      4. Click OK ()
  3. Add a policy assertion that looks like the following ()
    1. Click the Add button to add a new assertion to the policy then select Vocabulary Constraint Assertion and click OK ()
    2. Use the dialog to express the constraint Premium Credit Check = True ()
  4. Create a new context specification as shown earlier and call it Choose Credit Check CTX. Add the following vocabulary dimensions:
    1. Credit Check Type, required
    2. Premium Credit Service, optional
    3. New Customer, required
  5. Open the editor for the ChooseCreditCheck Dynamic Aassembly Component and associate the new context specification.

Related links

  1. Modeling, developing, assembling, deploying and managing an application
  2. Working with the Fabric templates in Business Space
  3. Business Space Information Center

No comments:

Post a Comment