Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 3 A Quick TIBCO Object Service Broker Tutorial : Task E: Using Exceptions to Handle Data Errors or Inconsistent External Data

Task E: Using Exceptions to Handle Data Errors or Inconsistent External Data
In this task you will write an exception handler to handle the situation where the team acronym from the external data source does not correspond to the team alias. Use the GAME_SCHEDULE table to confirm and finalize the update if the record in the external data source is otherwise valid.
Requirements to Update a Record
Let us establish what we consider enough information about the game to update a team’s record, even if the team name in the result file does not matching the alias expected.
The information about the opposing team has to match up with the record from the result file and the record from the game schedule table.
Acceptable Match
As an example, records:
 
20061005 0011 cgy 1 edm 3 final
 
11 Thu Oct 5 CALGARY AT EDMONTON 08:00 P
are considered to be an acceptable match because the game number is the same for both, and the acronym in the result file “edm” for EDMONTON matches the alias used for EDMONTON in the TEAM_STATS row. Therefore, the result with acronym ‘cgy’ will be applied to the TEAM_STATS row for CALGARY.
Unacceptable Match
On the other hand, records:
 
20061026 0138 fla 0 njd 2 final
 
138 Thu Oct 26 FLORIDA AT NEW JERSEY 07:30 P
are not considered as an acceptable match, because even with the same game number, neither team’s alias corresponds to the value used in the result file.
Logic Flow
Well-written TIBCO Object Service Broker rules are short programs that accomplish a specific business logic operation. Each rule encapsulates all implementation details.
The following picture outlines the execution flow through the set of rules implementing , Task E: Using Exceptions to Handle Data Errors or Inconsistent External Data.
Implementation Details of the Rules
The following section outlines implementation details for each of the rules in the solution:
FIND_TEAM
We need only minimal changes to the existing code: instead of printing Message Log information when the GETFAIL exception is signaled, the custom exception handling rule VERIFY_GAME is invoked. This only happens if the rule FIND_TEAM cannot locate the correct row of the table TEAM_STATS as per the GAME_RESULT alias; if a GETFAIL exception is raised, the custom exception handler VERIFY_GAME is called.
To be able to verify if the other team in the result record provides us with the acceptable match, we have to carry information pointing to the team that could not be located in the TEAM_STATS table using the rule FIND_TEAM. We update FIND_TEAM to set the value of the local variable TEAM_TO_FIND before attempting to get the row. If the exception handler VERIFY_GAME is invoked, the local variable TEAM_TO_FIND is set and available.
As the VERIFY_GAME rule handles the exception generated in the FIND_TEAM rule, the control returns to the caller of FIND_TEAM, the rule PROCESS_RESULT. If the rule VERIFY_GAME successfully locates the row from TEAM_STATS that should be updated (the GAME_SCHEDULE is checked, an acceptable match found, and the team found by referencing the team full name from GAME_SCHEDULE), this row will be updated by the UPDATE_TEAM rule that is invoked after FIND_TEAM.
Alternatively, if VERIFY_GAME cannot locate the acceptable match, the UPDATE_TEAM will not be called.
VERIFY_GAME
The exception handler identifies the other team from the GAME_RESULT row using conditional processing at the beginning, and saves that information as the local variable OTHER_TEAM.
The game number from the rule GAME_RESULT is used to retrieve the game schedule from the GAME_INFO table. The rule CHECK_TEAMS is then invoked to verify if the records are a match as defined according to the requirements.
Note that this rule provides error handling for a situation where:
The local variable TEAM_TO_FIND is not equal to either team alias from the GAME_RESULT row. This indicates an error in processing logic.
The game with the game number as per the GAME_RESULT row does not exist in the schedule recorded in the GAME_SCHEDULE table. This indicates an inconsistency between external data sources.
CHECK_OTHER_TEAM
This rule verifies that the other team from the GAME_RESULT row corresponds to the team from the schedule found in the GAME_SCHEDULE table.
If either the HOME_TEAM or VISITING_TEAM field from the GAME_SCHEDULE table corresponds to the local variable OTHER_TEAM, we now know that the team we could not identify is the other one.
To locate the correct TEAM_STATS record to update, we now use the full team name of the “other team”. Note the WHERE clause on the GET statement.
Also, note that conditional section at the top of CHECK_TEAM uses two short functions (rules that return a value) to return both HOME_TEAM and VISITING_TEAM aliases based on the team name from the GAME_SCHEDULE table:
RECORD_BAD_DATA and RECORD_FIX_DATA
These two rules are used to keep track of the external data source information that is found to be inconsistent with the reference table or another external data source, and of the action that the application has taken to fix it if possible.
Both rules insert a row in the native TDS table BAD_DATA defined as:
This table hosts all the information from the external data source that was considered inconsistent, the details about inconsistency provided at the time processing was done, and the date of processing. It is defined to be an IDGen table, meaning that TIBCO Object Service Broker will generate a unique key for each row inserted in the table.
These two rules are almost identical. The significant difference is statement number 8 in the RECORD_BAD_DATA rule. This statement signals the custom exception BAD_DATA which is designed to prevent the update of the TEAM_STATS table if the correct row could not be located.
If the GAME_RESULT row is accepted as having an “acceptable match” the RECORD_FIX_DATA will be invoked instead of RECORD_BAD_DATA, and the update of the TEAM_STATS will proceed with the row that was located in the VERIFY_GAME exception handler.
The exception BAD_DATA is caught inside of the rule PROCESS_RESULT and causes the UPDATE_TEAM to be skipped. There is no additional processing associated with this exception; its only purpose is to change the flow of execution to avoid UPDATE_TEAM.
The updated rule PROCESS_RESULT is coded as follows:
 

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved