Simulate (Test) Business Service Decisions

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

1. Simulate (Test) Business Service Decisions
1. Testing the Choose Credit Check Decision
2. Submitting Changes for Approval
2. Related links

Simulate (Test) Business Service Decisions

A simulation in Composition Studio is a test that represents how the dynamic assembler behaves in a given business situation. It is a good idea to define a set of scenarios that represent the various inputs and expected outcomes for a given decision. For example, we have policies that determine whether we should review collateral based on line of business. To test this, we should have at least one case where the line of business causes a collateral review and one where it does not.

Let's create our first test for the CreditCheck dynamic assembly component.

1. From the Business Application Explorer,  right-click Loans Origination App Project and select New\Simulation ()
2. Enter the following information into the Dynamic Assembly Simulation window and click Finish ()
   

Name	DA Component	Description
Automated Credit Check for Existing Customers	CreditCheck	New Customer = False  Amount = 20,000 ---------------------------- Select Automated Variation & Establish Credit Check Type = INTERNAL

3. This is the new simulation ()
Since you may have several simulations for each Dynamic Assembler, it's a good idea to name your simulations to identify the test scenario. The description field is a good place to summarize the inputs and expected outcome of the simulation.
Note that the Business Service and Application dimensions are automatically provided under “Simulation Context”. The simulator is using the Business Application mappings that we established earlier to provide these fields. If you do not see these fields provided automatically, it is a good indication that the mapping was not performed and that the dynamic assembler will not consider policies authored in business space.
4. Fill out the context elements in the simulation editor. Click Edit… for Amount of Loan. Enter 20000. Click OK ()
   
5. This simulation is for an existing customer, so set New Customer = False, i.e make sure the box is NOT checked ()
6. Click Run ()
   
   
   The results of running a simulation display the results for three phases of dynamic assembly. A green check mark shows up for each phase that successfully executed, or a red X will display on the first step that fails to execute. Keep in mind that an “all green” simulation may still be reflecting incorrect results. It is good idea to inspect the result of each phase.
   
   
   
   During the build selection policy phase, the system finds all policies that apply given the simulation input settings. It then merges these policies into a Composite Policy. During the merge, priority rules may cause a setting of one policy to override another. Inspecting the composite policy shows which settings made it into the resulting composite policy and indicates which policy won out in contributing each setting. It is a good idea to check these results to make sure that policies are being applied in the way you expect.
   
   
   
   During the find candidates phase, the system finds all endpoints that support the given interface and matches these endpoints against the composite policy. If an endpoint's assertions don't match required assertions in the composite policy, the output will indicate that the endpoint was filtered using the selection policy. An endpoint will also be rejected at this phase if a required assertion on the endpoint is not satisfied by the selection policy. Remaining endpoints are according to increasing cost and a suitability score based on the closeness of the match for non-required policy assertions. This rank is referred to as a tier.
   
   
   
   During the select endpoint phase, the system selects an endpoint with the lowest tier value from the remaining candidates. If an endpoint is not available at the given time due to endpoint status, hours of operations, or other temporal concerns, that endpoint is rejected and the next best endpoint is considered.
   
   
   
   Note that the simulation had no failures and that an endpoint supporting the automated credit check was successfully chosen.
   
   
7. Click the “Details” link for the Build selection policy phase. Verify that the policy sets the Credit Check Type to Internal ()
   
8. Create simulations for the other business service decisions as indicated by the table below.
   

Name	DA Component	Settings/Expected Results
Premium Credit Check for New Customers	ChooseCreditCheck	Business Service = Check Credit Application = Loan Origination Interface = getCreditReport Credit Check Type = Third-Party New Customer = True  Amount = 30,000  ------------------------------------------- Select Automated Credit Check  Premium Credit Service = True
Standard Credit Check for New Customer	ChooseCreditCheck	New Customer = True  Amount = 20,000  ------------------------------------------- Select Automated Credit Check  Credit Check Type = Third-Party
No Collateral Review for Auto Loans	CollateralReview	Line of Business = Auto  -------------------------------------------- Select No Collateral Variation
Human Collateral Review for RV Loans	CollateralReview	Line of Business = RV -------------------------------------------- Select Human Collateral Review
Automated Underwriting for Small Loans	FinalReview	Loan Amount = 10,000  Loan Status = In Progress  -------------------------------------------- Select Automated Underwriting
Human Underwriting for Large Loans	FinalReview	Loan Amount = 30,000  Loan Status = In Progress  -------------------------------------------- Select Human Underwriting
Automatic Underwriting Pass Through for Rejected Loans	FinalReview	Loan Amount = 50,000  Loan Status = Rejected  -------------------------------------------- Select Automatic Underwriting
Automated Notification for Approved Status	NotifyCustomer	Loan Status = Approved  -------------------------------------------- Select Automated Notification
Human Notification When More Info Needed	NotifyCustomer	Loan Status = More Info  -------------------------------------------- Select Human Notification

Testing the Choose Credit Check Decision

We'll need to create a few more simulations to test our policies and other configuration for the ChooseCreditCheck decision. Create the following simulations for the ChooseCreditCheck dynamic assembly component.

Name	DA Component	Settings/Expected Results
Select Internal Credit	ChooseCreditCheck	Credit Check Type = Internal New Customer = False -------------------------------------------- Select Internal Endpoint
Select Premium, Third-Party Credit	ChooseCreditCheck	Credit Check Type = Third-Party Premium Service = True New Customer = True -------------------------------------------- Select Experian
Select Normal Credit Service (Weekdays)	ChooseCreditCheck	Day of Week = Mon-Friday Credit Check Type = Third-Party Premium Credit Service = (not supplied) New Customer = True -------------------------------------------- Select TransUnion
Select Normal Credit Service (Weekend)	ChooseCreditCheck	Day of Week = Saturday or Sunday Credit Check Type = Third Party Premium Credit Service = (not supplied) New Customer = True -------------------------------------------- Select Experian

By default, a new simulation will fill in the time and date fields with the current date and time. In situation, where it is important to test hours of operation or other temporal concerns such as the effective date range for policies, use the date and time controls to specify exactly what time/date is being simulated.

For example, we can test a weekend request by picking any Saturday on the calendar:

Submitting Changes for Approval

We're done configuring the necessary metadata and testing of endpoint selection. Now we need to submit our changes to the Fabric Server so that this configuration is available on the server at runtime.

A Fabric Tool Pack install configures a Fabric Server Unit Test Environment to automatically approve and publish changes submitted from Composition Studio. For the purpose of this guide, we'll show the full process.

1. Right click on the Fabric Project (i.e Loans Origination App Project) in the Repository Changes View (Select Window\Show View) and select Submit Change Set. Select the project, and click Next.
2. Click the Add All button to select all changes. Provide a short description of the changes for the reviewer. Click Finish.
3. Click Yes if you are asked Are you sure you want to submit your changes?
4. A dialog notifies the successful submission of the change set and provides a numeric ID for the change set.
   
   
   After submitting the changes, all objects in the change set become read-only until an update tells the system that the change set has been published or that the changes were rejected.
   If auto-publish is turned on, the submitted changes will be automatically approved and published to the repository. Auto-Publish is turned on by default on a profile created by a Fabric installer (development/standalone profiles).
   
   
   
   For more details on turning on/off auto-publish please see the Manage Changes section under Fabric for Administrators.
   
   
   
   Note: The following Steps 4 to 7 are not required if your system is configured to auto-publish change sets.
5. Our Administrator, Andy, logs into Business Space and opens the governance tab of the Fabric Administration space. The change set submitted from Studio should appear as an active change set with a status of Pending.
   
6. Open the change set and review the details.
   
7. Click the Approve Change set button and provide a comment.
   
8. Click the publish button.
   
9. Back in WID, click the Update Project button
   
10. Select the project to be updated, click Finish.
    The system will first replicate any changes from the server. These changes may include our own change submission, or changes made by other users.
    
    The system tells us what version of the repository the project is now synchronized with and provides the current status of any outstanding change sets. After performing the update, the pending change set disappears since the project has now been updated to incorporate changes that took place on the server. Objects that were read-only while pending are unlocked so that further edits can take place.
    
    Next, we'll need to switch to the Business Integration perspective to finish the assembly of our modules and perform some testing.

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