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
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.
Figure 1: A sample rule group
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.
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.
Figure 2: Partner references in a rule group
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.
Figure 3: Rule set conditions
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.
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.
Figure 4: A rule set variable section
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
50 to get a rule for your
gold customers. Then you can fill in
5 to create a second rule for silver customers. Because both
rules were created from a template, you know that
50 are parameters. That means that, at runtime, you can
change those values to say
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.
Figure 5: A rule template
A rule that uses a rule template is known as a rule instance.
Figure 6 shows a rule instance that uses
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
param0 (seen in the template in Figure 5) has a
Pay As You Go and
param1 has a value of
Figure 6: A rule instance
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
Figure 7: A decision table
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.
Figure 8: Changing the orientation of a decision table
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.
Figure 9: A rule template for a decision table
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
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
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.
Table 1: International rate table
|Rate / min||0.05||0.05||0.15||0.20|
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:
Charge of Leg 1: Leg 1 duration (90 seconds) x Leg 1 Rate (US = 0.05/min) = $0.075
Charge of Leg 2: Leg 2 duration (60 seconds) x Leg 2 Rate (Europe = 0.20/min) = $0.20
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:
- Download the
ratingsystembegin.zipfile from the Downloads section.
- Click File - Import - Project Interchange, and then click Next.
- Click Browse next to the From zip
file field, browse to the
phonebillingbegin.zipfile that you just downloaded, and click Open. This zip file is the Project Interchange file.
- 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 workspacemessage 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
Rate business objects that you will use within the
business rules. There are also three interfaces:
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
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.
- In the Business Integration view, expand RatingSystem - Business Logic - Rule Groups.
- Right-click the Rule Groups category and select New - Rule Group.
InternationalRateRGfor the name. Click Next.
- 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:
- 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.
- In the right side of the editor, click the Default Destination field. A list of choices opens as shown in figure 10.
- Select New Decision Table from list of choices. A
new decision table dialog box opens.
Figure 10: Creating a default destination
RateTablefor the name of the decision table. Click Finish. A decision table editor opens.
- 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
variable, the type is not automatically copied to the
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!
Figure 11: RateTable editor interface section
- In the RateTable decision table editor, click the condition cell where it says Enter Term.
- In the list that opens, expand input1 and select
destination as the condition term.
Figure 12: Creating a new condition
- Click the first condition value cell where it says, Enter Value.
- From the list that opens, select String
- In the floating text field, enter
Canada, and press Enter.
Figure 13: Entering a new condition value
- In the same manner, enter
USin the adjacent cell.
- Right-click the table and select Add Condition Value. This adds a condition value after the last one.
- To add another condition value, select the Add Condition
Value menu again. The table should look like the one in
Figure 14: The RateTable after adding two extra condition values
- For the third and fourth condition values, enter
Now that you have the conditions defined, let's fill in the actions for each condition:
- 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
- Select the first action value cell where it says Enter Value, and then select Number.
- In the floating text field, enter
- In the second, third, and fourth action value fields, enter
- 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
Figure 16: The completed RateTable
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.
- In the Business Integration view, open the RatingSystem assembly diagram.
- 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:
- Right-click the canvas in the assembly diagram and select Test Module.
- In the test client that opens, type
USfor destination. Click Continue.
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.
Figure 17: Testing the InternationalRateRG rule group
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.
- Right-click the server and select Add and remove projects.
- 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
that contains a rule set with if-then conditions:
- Create another rule group in the RatingSystem project the same way as
you created the
InternationalRateRGrule group. This time, name the rule group
- For the interface, select BillRecordInterface. The interface was included in the module that you imported in Step 1.
- In the rule group editor, select the operation named getBilling on the left pane.
- 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:
- Select New Ruleset from the destinations list.
getBillingRSfor 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.
- 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.
- In the ReferenceDetails section, enter
InternationalRateRGReffor the name.
- Click the Interface field and, from the list of interfaces that opens, select InternationalRateInterface.
- In the same manner, add another partner reference. This time, name it
TotalChargeReference, and select the TotalChargeInterface interface.
- Save the editor.
Figure 18 shows the final BillRecordRG rule group.
Figure 18: The BillRecordRG rule group
Step 6: Add rules to the getBillingRS rule set
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
InternationalRateRGrule group component that you created earlier. The
InternationalRateRGcontains the RateTable decision table that determines the rate for each leg of the call.
- The last rule invokes the
TotalChargeJava 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:
rate2 variables are
Rate business objects and
increment variable is a primitive
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:
- In the
getBillingRSrule set editor, click Add Variable.
- Change the name of the variable to
rate1. In the Type cell, click Select Type, and then select Rate from the list of types.
- In the same manner, create two more variables. Name one
rate2, with the type Rate, and name the other
incrementwith the type double.
Figure 19 shows the variables.
Figure 19: Variables in the getBillingRS rule set editor
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.
- In the getBillingRS editor under the Rules section, right-click and
select Add If-Then Rule. This adds a new rule named
Rule1to the canvas.
- In the If cell, click Condition.
- Expand billingRecord and select
usage_plan as shown in Figure 20.
Figure 20: Selecting a condition in the rule set editor
- 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
- In the same cell, select String and enter
Pay As You Goin 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:
- In the Then cell, click Action, and then select increment from the list of choices.
- 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.
- In the location after the single equal sign, enter
30. Save the editor.
Rule1 should appear as in Figure 23.
Figure 23: The completed Rule1
The next steps convert
Rule1 into a template and then create
Rule2, which uses the same template as
- Right-click Rule1 and select Convert Rule to
Template. This step creates
Template_Rule1in the Templates section and makes
Rule1a rule instance that uses
- 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.
- In the Presentation cell of Rule2, click
Enter Value next to the If cell,
and then enter
- At the second Enter Value, enter
6, and then save the editor.
Your editor now should look like Figure 24.
Figure 24: The completed Rule1, Rule2, and Template_Rule1
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.
- In the Rules section, right-click and select Add Action
Rule, which creates
- Click the Action cell in Rule3, select rate1, select = (single), and then select Create BO.
- The Business Object Selection dialog box appears. Select Rate and click OK.
- 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
rate2 business objects, and then
assign values to their
Figure 25: Creating actions in Rule3
- Click Action at the bottom of the Action cell.
- Expand rate1, select destination, and then select =.
- Expand billingRecord and then select destination1.
- At the end of the second line, press Enter to add another action.
- In the same manner, create another
Ratebusiness object for the
- Save the editor.
Rule3 should now look like Figure 26.
Figure 26: The completed Rule3
Creating Rule4 and Rule5
Rule5 are actions rules that invoke
InternationalRateRG rule group. You might recall that two
partner references are specified in the
group. One of the partners is
refers to the interface file of 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
Rule5 uses the
rate2 variable to invoke this partner reference.
Follow these steps to create these rules.
- To create
Rule4, select Add Action Rule in the Rules section.
- This time, when you click Action in the Action cell, select Invoke.
- Click the Partner cell and select InternationalRateRGRef from the list of available partners.
- 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
rate1 as the input. The output from that partner
gets written back to the
- 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.
- Save the editor.
Figure 27: The completed Rule4 and Rule5
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.
- In the rules section, select Add Action Rule.
- In the same manner as in the previous steps, create another Invoke action with TotalChargeReference as the Partner, and operation1 as the Operation.
- For the Input, select billingRecord for record,
rate1 and rate2 for the
rate2variables respectively, and increment for
- For the Output variable named
total_charge, select chargeOutput.
- Save the editor.
Rule6 should look like Figure 28.
Figure 28: The completed Rule6
Just to put things in perspective, figure 29 shows the entire completed rule set.
Figure 29: The completed getBillingRS 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.
- In the Business Integration view, under the Rule Groups category, select BillRecord and drag it to the assembly diagram.
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:
- Connect the top reference of BillRecordRG to the InternationalRateRG component.
- Connect the bottom reference to the TotalCharge component.
Figure 30: The BillingSystem assembly diagram
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.
- Right click the canvas in the assembly diagram and select Test Module.
- In the integration test client input editor, select BillRecordRG as the component.
- Enter the parameters shown in Figure 31, and then click Continue.
Figure 31: Testing the BillRecordRG
Figure 32 shows the result.
Figure 32: The BillRecordRG test 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.
- While the server is running, open a command prompt.
- 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.
Figure 33: Instaling the Business Rules Manager
- In the Servers view, right-click the server and select Launch - Business Rules Manager.
- 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
Figure 34: The Business Rules Manager
- 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
- Click the Rule Books link in the navigation frame on the left of the manager.
- Expand BillRecordRG and click the getBillingRS link.
- 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:
- Change the increment of the Pay As You Go plan from
60, as shown in Figure 36.
RulePromofor the name,
Promofor the usage_plan, and
1for the increment.
Figure 36: Changing parameters in the Business Rules Manager
- Click Add.
- 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
- Click Save at the top of the page.
The change is only temporary until you publish it to the server.
- In the navigation frame in the manager, click the Publish and
Revert link. You will see that
getBillingRShas one change, as Figure 38 shows.
- Click Publish.
Figure 38: Publishing the getBillingRS rule set in the Business Rules Manager
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:
Figure 39: Testing the modified getBillingRS
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
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.
Figure 40: Testing the modified getBillingRS with "Promo" as the usage_plan
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.
|Starter project interchange file||ratingsystembegin.zip ( HTTP | FTP )||12 KB|
|Final project interchange file||ratingsystemcomplete.zip ( HTTP | FTP )||17 KB|
- 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