IBM WebSphere Developer Technical Journal : A guided tour of WebSphere Integration Developer -- Part 6

Document options Document options requiring JavaScript are not displayed Sample code New site feature Check out our new article design and features. Tell us what you think. Rate this page Help us improve this content

Level: Introductory

Jane Fung (jcyfung@ca.ibm.com), Advisory Software Developer, IBM
Greg Adams (Greg_Adams@ca.ibm.com), Distinguished Engineer, IBM
Richard Gregory (gregoryr@ca.ibm.com), Staff Software Developer, IBM
Randy Giffen (Randy_Giffen@ca.ibm.com), Advisory Software Developer, IBM

20 Sep 2006

This is the sixth article in a series exploring a service-oriented approach to application integration using IBM® WebSphere® Integration Developer. This article examines how you can make your running application dynamic and flexible so it can handle changing business conditions without requiring you to redeploy the application. We will look extensively at business rules, a key mechanism to achieve this flexibility.

From the IBM WebSphere Developer Technical Journal.

Introduction

In the last article, we dove deeper into business process creation using IBM® WebSphere® Integration Developer. As you might recall, a business process is any system or procedure that an organization uses to achieve a larger business goal. You can automate a business process, or you can create a number of steps that one or more users need to manually complete. Business processes can be short running, or take hours, days, weeks or more to complete.

Business processes often include key business decisions. For example, your enterprise might choose to provide gold customers with a 10% discount and silver customers with a 5% discount. The size of the discount is a key business decision based on the type of customer. Furthermore, a truly agile business does not want these key decision points hard-wired into their processes. Instead, they might want to adjust the discounts rapidly so they can lure gold customers during a holiday season. Perhaps, if they are feeling particularly giddy, they might give gold customers a 50% discount for December and January.

You could always hard-wire the decision and discount values into the processes and redeploy your application whenever you want to change the discount, but that is hardly agile and would require a user who simply wants to give good customers a 50% discount to actually modify a process and redeploy the application, rather than just typing two numbers. You could also consider building your application so that it uses a database, and then modify the database as business conditions change (for example, modify the database to change the gold discount to 50%). However, this option makes your application more complicated and requires that you have a database-savvy user on staff, instead of a user who just wants to type two numbers. Surely there must be something simpler?

Indeed there is! WebSphere Integration Developer provides a key component that greatly improves application flexibility: business rules. Business rules externalize and manage business logic separately from the main business process. They allow you to make changes at runtime to keep up with the evolving on-demand business environment.

Business rules are the business logic and constraints that shape an organization. For example, a business rule might state, "shipments over 300K in value require 2 supervisors to approve." Business rules in WebSphere Integration Developer live within a rule group, which is another way to implement a component. There are two kinds of business rules: rule set and decision table. A rule set typically consists of a number of if-then rules, and is normally used when complex logic is involved. A decision table captures simple rule logic in a table format. The selection of which business rule to invoke is based on date criteria that exists in the rule group.

In this article you will learn about

• Rule groups
• Rule sets
• Decision tables
• Putting it all together

Back to top

Rule groups

A rule group is a type of component implementation that logically groups rule sets and decision tables. Like other component types, a rule group implements one or more interfaces. For example, Figure 1 shows a rule group that implements the getBilling operation of the BillRecordInterface. When you call the getBilling operation, this rule group determines what action to take next.

When you invoke a rule group is, it selects a destination using the selection criteria and date range entries. A destination could be either a rule set or a decision table that contains the actual business logic. Selection criteria could be either a current date, an XPath expression that gets a date from a business object, or a Java snippet that returns a date.

A date range entry specifies a range of dates, during which a destination would be applicable. If the date returned from the selection criteria is within the boundary of the date range entry, then the corresponding destination is used. The date range entries are optional. If, in fact, no date range entry is supplied or if no date range matches, the default destination is invoked. Keep in mind that if you do not specify a default destination and no date range entry matches, then an exception will be thrown. Therefore, it is best to provide a default destination.

Looking at Figure 1 again, the rule group states that if the current date falls within June 20 and Sept 20 of 2007, then the destination getBillingRSsummer will be in effect. Any other date will put the default destination getBillingRS into effect.

Partner References

You need to define a partner reference in a rule group when a rule set or a decision table invokes another component. For example, you might want your rule group to perform a business decision based on the customer type (gold, silver) and then call another component to ship the order. For gold customers you might use air express, for bronze customers you might use the nearest snail. After creating the rule group, you need to add it to the assembly diagram with the partner references wired correctly before it is considered complete.

Figure 2 shows a rule group that contains two partner references. In the details pane, you can see that each partner reference has an associated interface. Partner references in a rule group work the same as they do in a business process.

Back to top

Rule sets

Rule sets are one type of destination in a rule group. Each rule set has its own namespace and name. There are two kinds of rules in a rule set: if-thenrules and actionrules. An if-then rule can have one or more conditions. When the if clause has more than one condition, you can choose to have it evaluate to true when any of the conditions are true or when all of the conditions are true. Figure 3 shows both kinds.

When the if clause evaluates to true, the corresponding actions in the then clause are performed. The actions can range from assigning a value to a variable to creating business objects or invoking other services. Most of these actions can co-exist with other actions in the same section, except for the invoke action. The invoke action cannot run with the other actions; it occupies the whole action section by itself.

The other type of rule is an action rule. An action rule doesn't have any conditions; it always performs the actions specified in the rule. The actions that are allowed in an action rule are the same as those that are allowed in the action section of the if-then rule. The actions in both the if-then rule and the action rule execute sequentially.

Variables

You can define local variables in a rule set. Local variables can be primitive or business object types. You define variables in the variables section of the rule set editor. When local variables are defined, they have no value and are not initialized. If you try to use them without initializing them, you will get a run-time exception. Therefore, you must first assign a new business object instance to a business object variable before using it. Figure 4 shows the variable section from a rule set editor.

Rule Templates

A rule template is a form that you can use to create similar looking rules. For example, if you had a rule stating that gold customers get a 50% discount and another where silver customers get a 5% discount, you could first imagine a template that in essence says "for a customer of type X give a discount of type Y". Now that you have this template, you can fill in gold and 50 to get a rule for your gold customers. Then you can fill in silver and 5 to create a second rule for silver customers. Because both rules were created from a template, you know that gold and 50 are parameters. That means that, at runtime, you can change those values to say 45or 65 quite easily. To modify the parameters in a rule instance at runtime, you use the Business Rules Manager, by right-clicking a server instance in the Server view, and selecting Launch - Business Rules Manager.

You can create a rule template for either an if-then rule or an action rule. There are two ways to create a template. You could create a regular rule and then convert it to a rule template or you could directly create a rule template. A rule template is shown in Figure 5. The presentation field is the text that describes the rule template to an administrator using the business rules manager, and it specifies the parameters that the rule template accepts. This presentation string is what users will see at runtime when they want to change the discount – they will not see the details of how you are implementing the rule. The parameters are inputs to the template and are listed under the parameters sections. This example is an if-then rule; therefore, you would see the if condition and its corresponding action. The if-then statement uses the parameter values that are passed in from a rule instance.

A rule that uses a rule template is known as a rule instance. Figure 6 shows a rule instance that uses Template_Rule1. The Template field specifies which rule template that this instance uses and the presentation field displays the presentation from the rule template. The Presentation field is where you can provide the parameter values. In this example, param0 (seen in the template in Figure 5) has a value of Pay As You Go and param1 has a value of 30.

Back to top

Decision tables

A decision table captures simple rule logic in a table format. There are two sections in a decision table: conditions and actions. You can specify conditions in the conditions section. For example, Figure 7 shows a decision table that has two conditions and two actions. The conditions state that if the usage_plan is "Pay As You Go" and destination1 is "Canada", then two actions will be performed. The first action will set 0.05 into the chargeOutput variable and the second action will set 10 into the total_charge variable.

You can toggle the orientation of a decision table condition so that you can view it either horizontally or vertically by clicking the Change Orientation of Condition button. Figure 8 shows the destination1 condition in the horizontal orientation.

Value templates

The concept of a template also applies to decision tables. You could convert any cell into a value template. Similar to a rule template in a rule set, a value template in the decision table has a presentation and parameters. Due to the nature of the decision table though, a template in a decision table typically has only one parameter, which is always an action rule. A value template in decision table is not reusable, but by using a value template, you can alter the parameters using the Business Rule Manager. Figure 9 shows a sample of a rule template for a decision table.

Back to top

Putting it all together

Now that you have seen the features of rule groups, rule sets, and decision tables, let's look at a scenario that you can implement using these concepts. Our scenario is a cell-phone billing system. Have you heard the term billing increment? A cell phone plan that uses a full-minute billing increment means that a one-second phone call will be billed as a full minute. That doesn't sound like a very good deal unless you are a phone company. To stay competitive, cell phone companies might need to change billing rates or introduce a new promotional plan in real time. In this example, we examine how a company uses business rules to define the billing rules and to externalize and modify them on the fly.

We have created some projects, business objects, and interfaces for you since you already know how to do that from earlier articles. As in the last article, you just need to import the pre-built parts of the application so you can focus on the business rule aspects of it.

In this scenario, you create two rule groups. The first contains a decision table that captures the international rate plan. The other rule group contains a rule set that invokes a component to calculate the phone charges. Finally, we will show you how to change rules at runtime.

Cell Phone Billing System

Many cell phone companies use a two-leg billing system that bills each leg of the call separately. Our application uses the same system. The first leg of the call starts as soon as the caller makes the call and is billed as follows: Leg 1 rate x Leg 1 duration. The second leg of the call begins as soon as the destination party or answering device answers the telephone. It is billed as follows: Leg 2 rate x Leg 2 duration. The customers probably thought that they didn't have to pay unless they answer the phone. Sadly, they do, and while we're ruining your day, the Easter Bunny is also not real (we think).

If a customer makes a call from the US to Europe, the first leg begins as soon as the caller starts calling. When the destination party picks up the call, the second leg begins. The rate table is shown in Table 1.

Imagine that the first leg, from the U.S., is 61 seconds and the second leg, to Europe, is 56 seconds. After adjusting the durations with a billing increment of 30 seconds, the first leg becomes 90 seconds (instead of 61) and the second leg becomes 60 seconds (instead of 56). Therefore, a 30-second billing increment means a one-second call will be charged as a 30-second call. The phone call charge is calculated as follows:

1. Charge of Leg 1: Leg 1 duration (90 seconds) x Leg 1 Rate (US = 0.05/min) = $0.075
2. Charge of Leg 2: Leg 2 duration (60 seconds) x Leg 2 Rate (Europe = 0.20/min) = $0.20
3. Total charge of the call is the sum of each leg which is $0.075 + $ 0.20 = $0.275

In your business rules you will use a decision table to capture the rate table. An existing component calculates each leg and the total charge. Finally, you will use a rule set to put everything together.

Step 1: Importing the existing projects

Since you probably just want to focus on the business rules, we'll start by importing some prebuilt business objects, interfaces and other artifacts:

1. Download the ratingsystembegin.zip file from the Downloads section.
2. Click File - Import - Project Interchange, and then click Next.
3. Click Browse next to the From zip file field, browse to the phonebillingbegin.zip file that you just downloaded, and click Open. This zip file is the Project Interchange file.
4. Check Select All, and then click Finish. The imported modules open in the Business Integration view and, as the project builds, you see a Building workspace message in the lower right corner of the workbench. Wait for the workspace to finish building.

Let's briefly look at what you have just imported. The RatingSystem module contains the BillingRecord and Rate business objects that you will use within the business rules. There are also three interfaces: BillRecordInterface, InternationRateInterface, and TotalChargeInterface. You will need these interfaces when you create the rules and call services from the rules.

The module also has an assembly diagram (to open it, expand the RatingSystem module in the Business Integration view and double-click RatingSystem). The assembly contains only a single business process component. If you double-click that component, you will see that it simply contains a snippet called calcCharge that calls a custom visual snippet called TotalCharge. You can view the details of the TotalCharge snippet by opening the details for calcCharge in the properties view, and then double-clicking the TotalCharge node in the visual snippet. In the TotalCharge snippet, you will see two uses of the TotalChargePerLeg custom visual snippet that calculates the rate for each of the two legs of a call according to the rules we discussed earlier.

You'll use this component, and its snippets in the business rules that you will create in the following sections.

Step 2: Create the InternationalRateRG rule group

It's time to create a rule group that uses a rate plan decision table.

1. In the Business Integration view, expand RatingSystem - Business Logic - Rule Groups.
2. Right-click the Rule Groups category and select New - Rule Group.
3. Enter InternationalRateRG for the name. Click Next.
4. From the interface list, select InternationalRateInterface. Click Finish. The rule group editor opens.

Now you will implement the operation of the interface you just selected that this component will support. After all, there is not much point to a rule group if it doesn't do anything. The next steps add a decision table as a destination for the group:

1. In the rule group editor, select getRate. The rule sets or decision tables that you define in the right pane will implement the getRate operation.
2. In the right side of the editor, click the Default Destination field. A list of choices opens as shown in figure 10.
3. Select New Decision Table from list of choices. A new decision table dialog box opens.
   
   Figure 10: Creating a default destination
   
   
   
4. Enter RateTable for the name of the decision table. Click Finish. A decision table editor opens.
5. Switch back to the InternationalRateRG rule group editor and save it. This will get rid of the red X that indicates there are no destinations.

Step 3: Add Conditions to the RateTable Decision Table

The Interface section of the decision table editor displays the input and output variables of the interface, as shown in Figure 11. Although the input1 variable has the same type as the output1 variable, the type is not automatically copied to the output1 variable. Instead, a new Rate business object instance automatically gets created and assigned to output1. Time to fill in your decision table with some conditions!

1. In the RateTable decision table editor, click the condition cell where it says Enter Term.
2. In the list that opens, expand input1 and select destination as the condition term.
   
   Figure 12: Creating a new condition
   
   
   
3. Click the first condition value cell where it says, Enter Value.
4. From the list that opens, select String
5. In the floating text field, enter Canada, and press Enter.
   
   Figure 13: Entering a new condition value
   
   
   
6. In the same manner, enter US in the adjacent cell.
7. Right-click the table and select Add Condition Value. This adds a condition value after the last one.
8. To add another condition value, select the Add Condition Value menu again. The table should look like the one in Figure 14.
   
   Figure 14: The RateTable after adding two extra condition values
   
   
   
9. For the third and fourth condition values, enter Asia Pacific and Europe respectively.

Now that you have the conditions defined, let's fill in the actions for each condition:

1. Click the actions cell where it says Enter Term. Expand output1 and select rate as the action term.
   
   Figure 15: Entering a new term for the action
   
   
   
2. Select the first action value cell where it says Enter Value, and then select Number.
3. In the floating text field, enter0.05.
4. In the second, third, and fourth action value fields, enter 0.05, 0.15 and 0.20 respectively.
5. Save the RateTable editor.

Figure 16 shows the final decision table is shown. The value of output1.rate will be set according to the value of input1.destination.

Step 4: Create and test the InternationalRateRG rule group component

To allow other components and other modules to use your rule group and its decision table, you need to ensure that you add the rule group to the assembly diagram. When you have added it to your assembly diagram, you can quickly test your new component.

1. In the Business Integration view, open the RatingSystem assembly diagram.
2. Drag the InternationRateRG rule group that you just created onto the canvas.

Adding the rule group to the assembly diagram creates a new component. Before continuing, catch your breath and try out the new component using the WebSphere Integration Developer test facility:

1. Right-click the canvas in the assembly diagram and select Test Module.
2. In the test client that opens, type US for destination. Click Continue.

The InternationalRateRG component, which uses the RateTable decision table, is invoked by default because there were no other components or operations to select. The resulting rate is 0.05, as shown in Figure 17. You might notice that the result the destination of the output variable is null. Why is that? As mentioned earlier, a new Rate instance is automatically assigned to the output1 variable. To keep things simple, you only assigned values to the output1.rate variable and not to the output1.destination variable. Therefore, it is null.

In earlier versions of WebSphere Integration Developer, not all changes were picked up when a module was deployed to the server. It's a good idea to remove the project from the server before continuing.

1. Right-click the server and select Add and remove projects.
2. In the configured projects list, select RatingSystemApp, click Remove, and then Finish.

Step 5: Create a BillRecordRG

Follow these steps to create a rule group named BillRecordRG that contains a rule set with if-then conditions:

1. Create another rule group in the RatingSystem project the same way as you created the InternationalRateRG rule group. This time, name the rule group BillRecordRG.
2. For the interface, select BillRecordInterface. The interface was included in the module that you imported in Step 1.
3. In the rule group editor, select the operation named getBilling on the left pane.
4. On the right side of the editor, click Enter Destination in the DefaultDestination cell. A list of available destinations opens.

Last time you were at this point, you created a decision table. This time, you will create a rule set:

1. Select New Ruleset from the destinations list.
2. Enter getBillingRS for the name, and then click Finish.

To invoke these components, your rule group needs to have references that you can connect to the destination components.

1. Switch back to the BillRecordRG editor after the rule set editor opens. In the left-hand pane, click Add Partner Reference in the References section.
2. In the ReferenceDetails section, enter InternationalRateRGRef for the name.
3. Click the Interface field and, from the list of interfaces that opens, select InternationalRateInterface.
4. In the same manner, add another partner reference. This time, name it TotalChargeReference, and select the TotalChargeInterface interface.
5. Save the editor.

Figure 18 shows the final BillRecordRG rule group.

Step 6: Add rules to the getBillingRS rule set

The getBillingRS rule set contains six rules:

• Two if-then rules that determine the billing increment based on the usage plan. Both use the same if-then rule template.
• An action rule that creates new business objects for the internal variables and assigns some values to them.
• Two rules invoke the InternationalRateRG rule group component that you created earlier. The InternationalRateRG contains the RateTable decision table that determines the rate for each leg of the call.
• The last rule invokes the TotalCharge Java component that calculates the total charge of the phone call by adding the charges per leg together.

Rules in a rule set are always applied in the order that they appear. For this reason, they are sometimes called simple or sequential rules.

Create local variables

In this step, you will create three local variables: rate1, rate2 and increment. The rate1 and rate2 variables are Rate business objects and the increment variable is a primitive double type. Since business object variables are not automatically initialized, an action rule, described later in the article, will create a new business object instance and assign the new instance to these variables. The following steps create these variables:

1. In the getBillingRS rule set editor, click Add Variable.
2. Change the name of the variable to rate1. In the Type cell, click Select Type, and then select Rate from the list of types.
3. In the same manner, create two more variables. Name one rate2, with the type Rate, and name the other increment with the type double.

Figure 19 shows the variables.

Create the first two rules and the rule template

Rules 1 and 2 are if-then rules that determine the billing increment based on the usage plan. They are created based on the same rule template. Now let's create these rules and their template.

1. In the getBillingRS editor under the Rules section, right-click and select Add If-Then Rule. This adds a new rule named Rule1 to the canvas.
2. In the If cell, click Condition.
3. Expand billingRecord and select usage_plan as shown in Figure 20.
   
   Figure 20: Selecting a condition in the rule set editor
   
   
   
4. In the same cell, select == from the list of choices, as shown in Figure 21. (The double equal sign is used for comparisons, rather than setting values.)
   
   Figure 21: Selecting == for the condition
   
   
   

As you add to an expression for a rule, the list of available choices changes. At any time, you can simply type what should appear or you can select from the list.

5. In the same cell, select String and enter Pay As You Go in the floating text field. Press Enter.
   
   Figure 22: Entering "Pay As You Go" in the condition
   
   
   

The "if" clause is complete. The next steps create the "then" clause:

1. In the Then cell, click Action, and then select increment from the list of choices.
2. Select = (single equal sign). Use the single equal sign to assign a value to a variable, unlike the double equal sign (==), as in the previous condition, which compare the values.
3. In the location after the single equal sign, enter 30. Save the editor.

Rule1 should appear as in Figure 23.

The next steps convert Rule1 into a template and then create Rule2, which uses the same template as Rule1.

1. Right-click Rule1 and select Convert Rule to Template. This step creates Template_Rule1 in the Templates section and makes Rule1 a rule instance that uses Template_Rule1.
2. Right-click in the Rules section again and select Add Template Rule - Template_Rule1. All available templates appear in the list (there is only one at this point). This step creates Rule2.
3. In the Presentation cell of Rule2, click Enter Value next to the If cell, and then enter Regular.
4. At the second Enter Value, enter 6, and then save the editor.

Your editor now should look like Figure 24.

Create Rule3

You defined some local variables in the previous section. As we mentioned before, variables that are business objects are not automatically initialized. If you try to use them without initializating them, they will throw exceptions at runtime. In the rule set, you have already created two business object variables. Rule3 initializes these two variables by creating a new business object and assigning some values to them. Each rule set contains built-in methods for creating and copying business objects. You will see these methods from the action list.

1. In the Rules section, right-click and select Add Action Rule, which creates Rule3.
2. Click the Action cell in Rule3, select rate1, select = (single), and then select Create BO.
3. The Business Object Selection dialog box appears. Select Rate and click OK.
4. To create an additional action in the Action cell, press Enter at the end of the first line.

At this point, an Action item appears after the first line in the Action cell, as Figure 25 shows. Next, you need to specify what the actions are. In the following steps you define the actions to create the rate1 and rate2 business objects, and then assign values to their destination attribute:

1. Click Action at the bottom of the Action cell.
2. Expand rate1, select destination, and then select =.
3. Expand billingRecord and then select destination1.
4. At the end of the second line, press Enter to add another action.
5. In the same manner, create another Rate business object for the rate2 variable, assigning billingRecord.destination2 to rate2.destination.
6. Save the editor.

Rule3 should now look like Figure 26.

Creating Rule4 and Rule5

Rule4 and Rule5 are actions rules that invoke the InternationalRateRG rule group. You might recall that two partner references are specified in the BillRecordRG rule group. One of the partners is InternationalRateRGRef, which refers to the interface file of the InternationalRateRG. The interface file of the InternationalRateRG is the rule group that contains the RateTable decision table. In Rule4, you invoke this partner reference using the rate1 variable. Rule5 uses the rate2 variable to invoke this partner reference.

Follow these steps to create these rules.

1. To create Rule4, select Add Action Rule in the Rules section.
2. This time, when you click Action in the Action cell, select Invoke.
3. Click the Partner cell and select InternationalRateRGRef from the list of available partners.
4. Select getRate in the Operation cell, rate1 in the Input cell, and rate1 in the Output cell.

Rule4should now look like Figure 27. This rule invokes the service to which the InternationalRateRGRef reference is wired, with rate1 as the input. The output from that partner gets written back to the rate1 variable.

1. To create Rule5, repeat steps 1 to 4 that you followed to create Rule4. This time, select rate2 for both the input and output variables.
2. Save the editor.

Create Rule6

Rule6 is an action rule that invokes the TotalChargeReference component. We provided this component in the module you imported. It's implemented using a business process, and its operation takes four input variables.

1. In the rules section, select Add Action Rule.
2. In the same manner as in the previous steps, create another Invoke action with TotalChargeReference as the Partner, and operation1 as the Operation.
3. For the Input, select billingRecord for record, rate1 and rate2 for the rate1 and rate2 variables respectively, and increment for increment_in_sec.
4. For the Output variable named total_charge, select chargeOutput.
5. Save the editor.

The completed Rule6 should look like Figure 28.

Just to put things in perspective, figure 29 shows the entire completed rule set.

Step 7: Create and test the BillingSystem component

You have just finished creating your rule group that uses a rule set and if-then rules. Now we'll add the rule group to your assembly diagram and test it.

1. In the Business Integration view, under the Rule Groups category, select BillRecord and drag it to the assembly diagram.

The BillRecordRG rule group component has two partner references that need to be connected to the corresponding components, as you might remember from the second and third, articles. Follow these steps to connect the partner references to the corresponding components:

1. Connect the top reference of BillRecordRG to the InternationalRateRG component.
2. Connect the bottom reference to the TotalCharge component.

To clean up the assembly diagram, drag the components around to match Figure 31, or just right-click the editor and select LayoutContents. Either way, you're done! Now you can test the entire module.

1. Right click the canvas in the assembly diagram and select Test Module.
2. In the integration test client input editor, select BillRecordRG as the component.
3. Enter the parameters shown in Figure 31, and then click Continue.

Figure 32 shows the result.

Step 8: Using the Business Rules Manager

The Business Rules Manager is a Web client that helps you administer and configure your rules at runtime, based on changing business conditions. By default, the Business Rules Manager is not installed, so run a command line script to install it.

1. While the server is running, open a command prompt.
2. Change directories to <WID_INSTALL>\runtimes\bi_v6\bin, and then run the following command:

   wsadmin.bat –f installBRManager.jacl

   
   

This script installs the Business Rules Manager, and you should see the message shown in Figure 33.

1. In the Servers view, right-click the server and select Launch - Business Rules Manager.
2. In the Business Rules Manager, you see the two rule groups that you created in this article. If you expand both of them, you see getBillingRS and RateTable.
   
   Figure 34: The Business Rules Manager
   
   
   
3. Click the RateTable link to see the details on the decision table. Recall that, because no rule template is used inside the decision table, you cannot edit any of the parameters, even if you click the Edit button.
   
   Figure 35: The Rate Table in the Business Rules Manager
   
   
   
4. Click the Rule Books link in the navigation frame on the left of the manager.
5. Expand BillRecordRG and click the getBillingRS link.
6. Click Edit.

You are now in the edit page. Unlike in the RateTable, here you can modify the parameters in the rule set, because you used a rule template in the rule set. In the next steps we'll make a change in the rule parameters and add a new business rule based on the existing template:

1. Change the increment of the Pay As You Go plan from 30 to 60, as shown in Figure 36.
2. Type RulePromo for the name, Promo for the usage_plan, and 1 for the increment.
   
   Figure 36: Changing parameters in the Business Rules Manager
   
   
   
3. Click Add.
4. Click the up arrow on RulePromo to move it all the way to the top.
   
   Figure 37: Add a new business rule in the Business Rules Manager
   
   
   
5. Click Save at the top of the page.

The change is only temporary until you publish it to the server.

1. In the navigation frame in the manager, click the Publish and Revert link. You will see that getBillingRS has one change, as Figure 38 shows.
2. Click Publish.

Now that you have made two changes to the getBillingRS rule set, let's rerun the BillRecordRG in the test component again and see what result we get (Select the Invoke event in the test client and then select Rerun). If you recall, the total charge before the change was 0.475. After you have changed the increment from 30 to 60, the total charge becomes 0.5, as Figure 39 shows:

Remember that you also added a new rule for the Promo usage plan, that has a billing increment of one second. Now, re-run the test (click the Invoke button in the top right corner of the test client) and use Promo as the usage_plan parameter. The total charge is 0.356667, as figure 40 shows, which is a much better deal then the billing increment of 30 and 60 seconds.

Back to top

Conclusion

Business rules are a crucial part of the WebSphere Business Integration portfolio. Business rules can externalize and manage business logic separately from the main business processes. Off-loading the most volatile logic to business rules offers great flexibility to your company.

Back to top

Downloads

Description	Name	Size	Download method
Starter project interchange file	ratingsystembegin.zip	12 KB	FTP|HTTP
Final project interchange file	ratingsystemcomplete.zip	17 KB	FTP|HTTP

	Information about download methods

Resources

• A guided tour of WebSphere Integration Developer -- Part 1: Get a driver's view of the WebSphere Integration Developer landscape
  
  
• A guided tour of WebSphere Integration Developer -- Part 2: SOA development with WebSphere Integration Developer
  
  
• A guided tour of WebSphere Integration Developer -- Part 3: Building a simple service-oriented application
  
  
• A guided tour of WebSphere Integration Developer -- Part 4: Unleashing visual snippets and business state machines in your service-oriented application
  
  
• A guided tour of WebSphere Integration Developer -- Part 5: Business processes in a service-oriented world
  
  
• Creating WebSphere Process Server Custom Selectors with WebSphere Integration Developer
  
  
• Business Process Execution Language for Web Services version 1.1
  
  
• Business Process with BPEL4WS: Understanding BPEL4WS
  
  
• WebSphere Integration Developer product information
  
  
• WebSphere Process Server product information
  
  
• WebSphere Process Server: IBM's new foundation for SOA
  
  
• Build a Hello World SOA application
  
  
• Service Component Architecture
  
  
• Common Event Infrastructure
  
  
• developerWorks: WebSphere Process Server and WebSphere Integration Developer resources
  
  
• developerWorks: WebSphere Business Integration zone
  
  
• developerWorks: WebSphere development tools zone
  
  
• Meet the experts: WebSphere Integration Developer
  
  

• Download the WebSphere Business Modeler trial
  
  
• Download the Rational Application Developer trial

• WebSphere Integration Developer forum
  
  
• developerWorks blogs
  
  

About the authors

		Jane Fung is an Advisory Software Developer at IBM Canada Ltd, where she is responsible for developing the Business Process Execution Language (BPEL) and Business Rules debuggers in WebSphere Integration Developer. Prior to that, she was the team lead of the WebSphere Studio Technical Support team.

		Greg Adams was the lead architect for the user interface in the award-winning Eclipse platform, and more recently, has been the lead architect and development lead in the core WebSphere Business Integration Tools, including WebSphere Studio Application Developer Integration Edition and WebSphere Integration Developer. Greg led the delivery of IBM's first complete services oriented architecture (SOA) tools stack and the first BPEL4WS standards supporting Business Process Editor; both critical deliverables in support of IBM's On Demand strategy.

		Richard Gregory is a software developer at the IBM Toronto Lab on the WebSphere Integration Developer team. His responsibilities include working on the evolution and delivery of test tools for WebSphere Integration Developer.

		Randy Giffen is an advisory software developer at the IBM Ottawa Lab on the WebSphere Integration Developer team. He was responsible for WebSphere Integration Developer's business state machine tools and the visual snippet editor. Prior to to this he was a member of user interface teams for WebSphere Studio Application Developer Integration Edition, Eclipse, and VisualAge for Java.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top