Contact us...
Configuring the Business Application Module
When our business analyst authored the application and its business service, she had no exposure to the notion of a dynamic assembly implementation component. And up to this point, nothing was done to associate the SCA modules to the content authored in business space.
Map Business Services and Channels
In this section, we will perform some mappings that configure the dynamic assembly components to execute policies authored in Business Space.
- In the Business Application Explorer, double-click the composite service named LoanOrigination to open it. In the Composite Service editor that appears, do the following: (
)
- Click the Business Application tab
- Check the box Maps to a Business Application Module to enable the rest of this page
- Click the Browse button
- In the Application Selection window, select Loan Origination and click OK (
)
- The Business Service Mapping and Channel Mapping choices appears (
)
- Business Service Mapping
For each Dynamic Assembly Component, choose the business service task that it represents - Click the Browse button of the desired Dynamic Assembly Component
- Select the desired Business Service (
)
- Repeat steps 1 to 2 as required
- Channel Mapping
For each export in the module, select the Business channel that will be invoking it - Click the Browse button of the desired Channel Mapping
- Select the desired Channel (
)
- Repeat steps 1 to 2 as required
- After these mappings, the tab should look like this (
)
- The business channel associated to the export
- The application associated with the module
- The business service and optional role associated with each DA Component.
At runtime, these mappings allow the system to use the active export, module, and DA component to find:
These business dimensions are then made available in the context for invoking business and technical policies.
Important: Policies authored in the business tooling will only be considered by dynamic assembly components that have been configured, in this way, as part of a business application module.
Associate Endpoints with Process Variations
A dynamic assembly component uses policies to determine the most appropriate endpoint at runtime. When a business policy establishes that a given process variation of a business service should be selected, the system looks for an endpoint that declares that it supports this process variation (review Getting Started with IBM WebSphere Business Services Fabric V6.1 for further details).
In general, there may be several endpoints capable of supporting a given process variation and technical policies may enforce additional constraints on the selection. But for now, we have one endpoint for each variation. Let's configure them.
- In the Business Application Explorer, double-click Endpoint\processes/Automatedcreditcheck/AutomatedCreditCheck, switch to the Assertions tab and click the Add button (
)
- In the Select Assertion Type window (
), select Process Variation Assertion and click OK (
).
- Set the following as follows:
- Required Box = Check
- Business Services = Check Credit
- Variations = Automated Credit Check
- Click OK (
)
Setting required on an endpoint assertion means that the endpoint will only be considered if the selection policy contains a matching assertion. It's a good practice to set Required when adding Process Variation assertions.
Set up all process variation assertions as follows using the same steps as above:
| Endpoint | Business Service | Process Variation Assertion |
| AutomatedCreditCheck | Check Credit | Automated Credit Check |
| AutomatedUnderwriting | Final Review | Automated Underwriting |
| HumanUnderwriting | Final Review | Human Underwriting |
| AutomaticNotification | Notify Customer | Automatic Notification |
| HumanNotification | Notify Customer | Human Notification |
| HumanCollateralReview | Review Collateral | Human Collateral Review |
| NoCollateralReview | Review Collateral | No Collateral Review |
Define Context Specifications
The next step is to identify the context elements necessary for a dynamic assembly component to apply the policies that have been implemented by the business user.
A context specification specifies the context that is needed at runtime to make a dynamic assembly decision. There are several advantages to using a context specification.
Context is central to the operation of the Dynamic Assembler.
The Dynamic Assembler uses context to make decisions on which endpoint should receive a request. The Dynamic Assembler performs a policy match on the context to determine which policies should be used in making the endpoint routing decision.
Since the context at runtime determines how policies are applied, it is important that all needed context is provided with each invocation. A context specification that indicates a particular dimension is required will ensure that the dimension has filled in the context at runtime. A context specification clearly indicates which items in the context are relevant for a particular decision point, and provides a prebuilt set of entry fields for new simulations of a dynamic assembly decision.
A context specification is used to ensure that all dimensions declared as required are made available at runtime. At design time a context specification also determines what context dimensions will be available for test simulations of dynamic assembly.
A new context specification automatically includes certain well-known context dimensions that will be provided automatically, such as the Service Interface and Business Service dimension. Generally, it is necessary to determine what additional business concepts are used in policy conditions and include these in a context specification as well.
Let's configure a context specification for Check Credit, the first business service in our flow. From looking at the business policies, we can tell that the policies need to know whether the customer applying for the loan is a new or existing customer. Also, we can tell that the amount of the loan is needed for processing.
Business Service | Business Service process variations | Business Service policies | Input/Output |
Check Credit | Automated Credit Check (Since there is only 1 process variation, it will be selected all the time) |
|
|
| Policy Name | Description | FOR (business Service or Application) | WHEN (No conditions, click to add) | THEN (No results, click to add) |
| Credit Check default ( | N/A | Check Credit | None | Select Automated Credit Check in Check Credit |
| Internal Credit Check by Default ( | Policy sets the internal credit check service as the default. Applications can override this to go to a third-party service | Check Credit | None | Set Credit Check Type to Internal |
| Premium Credit Check Requirement ( | N/A | Check Credit | Field Name: Amount of Loan Comparator: is greater than Value: 25,000 | Set Premium Credit Check to True |
- Create a Context Specification
- In the Business Application Explorer, right-click Loans Origination App Project and select New\Context Specification (
)
- Provide a name CheckCredit CTX, and click Finish. The newly created specification will open as an editor (
)
- Switch to the Dimensions tab of the editor (
). Under Vocabulary Dimensions, click the Add button.
- Select Amount of Loan, and click OK (
)
- Follow the same steps to add New Customer as second Vocabulary dimension. The resulting specification looks like this (
)
The Required option is selected by default for newly added dimensions. It is a good idea to mark a context dimension as required if it should always have a value. If a dimension is only sometimes available in the context, deselect required. The system will not signal any error if an optional dimension is not provided.
A default value can be specified for a vocabulary dimension. Setting a default value has the same meaning as using a context extractor (next chapter) to specify a hard-coded value, but with the advantage that these values can be modified without changing or redeploying code. Use a default value if the value for a given decision is fixed. In our examples, we derive all values from business objects and other policies, so there is no need to set default values. - Associate a dynamic assembly component to a context specification
- Double-click Composite Service\LoanOrigination\CreditCheck dynamic assembly component to open it. Select the Overview tab and click Browse button (
)
- Select Check Credit CTX and click OK (
)
- Note that a validation warning appears for any dynamic assembly components that do not have context specifications associated with them. Check for these validation warnings to make sure that this configuration step is not forgotten.
Define additional Context Specifications
Use this table to define context specifications for the remaining DA (Dynamic Assembly) components ():
Dynamic Assembly Component Context Specification Additional Context Requirements CreditCheck CreditCheck CTX New Customer, Amount of Loan CollateralReview CollateralReview CTX Line of Business FinalReview FinalReview CTX Amount of Loan, Loan Status NotifyCustomer NotifyCustomer CTX Loan Status
Related links
- Modeling, developing, assembling, deploying and managing an application
- Working with the Fabric templates in Business Space
- Business Space Information Center
No comments:
Post a Comment