This definition uses the TIBCO Object Service Broker field type C – Count for the fields that will be holding the score (HOME_SCORE, VISITING_SCORE). This is to ensure that arithmetic operations will be permitted with these fields, as we are likely to use those values in addition when calculating the overall number of goals that the team scored.
The number of records coming into the system for the application as described clearly is not overwhelming; it would not cause any problems to store all the results internally and generate statistics using internal information. In the real world, however, we may deal with an external data source that contains millions of records, and importing all of that content to be able to process it would be highly impractical. To illustrate how TIBCO Object Service Broker deals with that scenario, we do not store the results information internally. Instead the application uses the information directly from the external source.
The application output is a table, TEAM_STATS, containing one row per team playing in the league, with information about the overall number of wins, losses, overall number of goals the team has scored, and the overall number of goals against. The output table is defined as a TEM type table, which means that is never made persistent in the database but used to hold temporary data. The content of the TEM table is available within the life span of the database transaction and is discarded when the transaction is done. The table definition is shown below:
The rule CREATE_TEAM_LIST loops through the table GAME_SCHEDULE and calls the rule CREATE_TEAM_REC for every HOME_TEAM and every VISITING_TEAM from that table:
Note that running this rule does not create multiple rows per team. This rule works in conjunction with the rule CREATE_TEAM_REC which is designed to add a new row to the output table only if the row for the team did not exist in the table before:
The INSERT operation only takes place if the GET operation on the row where the NAME equals to the team name fails, therefore only the first time the processing comes across that team in the TEAM_STATS table as either a visiting or home team.
The field ALIAS of the TEAM_STATS table contains the first three characters of the team name. This is to handle the fact that the team names in the table GAME_RESULT are presented in a format different than the format of the team name in the GAME_SCHEDULE table. This situation is common when an application is accessing information from different external sources.
To devise the value of the field ALIAS, we use the shareable tools SUBSTRING and SEARCH_REPLACE. Shareable tools are programs supplied with TIBCO Object Service Broker that expedite rules language programming and application development by performing common functions and facilitating tasks such as string manipulation, mathematical calculation, and object handling. For more information about these and the other sharable tools, refer to the
TIBCO Object Service Broker Shareable Tools manual.
Using the UI select the rule you want to run in either the Rules Explorer view, or in the OSB Project view. Right-clicking on the name offers the menu option “Run As …”, as shown below:

As the rule CREATE_TEAM_LIST does not take any arguments, you only need to press the Run button to start the execution of the rule. Alternatively, you can use the Text Workbench ER execute rule menu item, type in the name of the rule and press Enter:
The result of running the rule CREATE_TEAM_LIST is a set of rows each describing one team. The table, however, is defined as TEM type table, which means that when the execution of the rule is over, the content of the table is discarded. If you try to browse or edit the table TEAM_STATS after running the rule CREATE_TEAM_LIST, the Table Editor shows an empty table.
While it is possible to use the MSGLOG shareable tool to print the rows of the table to the Message Log, formatting the print line to display the content of all fields can be a tedious task. Alternatively, you can temporarily switch the table type from TEM to SES while testing the rule from the Text Workbench. To change the table type, simply open the Table Definer Tool from the Text Workbench by typing the table name beside the DR define table menu item:
As a result the content of the table are not discarded when the transaction is finished, and it remains available for browsing inside of the same Text Workbench session:
The functionality to build game results based on requirements can be accomplished in many different ways. The solution presented is just one of many possibilities:
The initial rule BUILD_STATS calls the rule CREATE_TEAM_LIST described earlier. This sets up the team names and aliases in the TEM table TEAM_STATS. It then loops through the IMP table containing game results and processes each result:
Note that every row in GAME_RESULT contains the information about both contending teams. For each game result, the rule PROCESS_RESULT uses the rule FIND_TEAM twice, once for each team that played the game to retrieve its record from the table TEAM_STATS.
For each of the teams, PROCESS_RESULT then calls the rule TEAM_UPDATE, passing the number of goals the team scored and received as arguments.
The total of goals scored by and against for the team is increased by the values passed as arguments and the number of wins or losses is updated depending on the condition statement at the top of the rule. Depending on the game results the number of wins or losses, is incremented.
After running rule BUILD_STATS, you can verify the messages produced. If run from the Text Workbench, press the PF2 key to display any messages within the Message Log:
If you kept the table TEAM_STATS type as SES for testing purposes, you can verify the content of the table, and notice that for some teams there are no games recorded:
Closer inspection of the text file with game results verifies that the aliases used for those teams, built as first three characters of the team name, do not correspond to the team acronyms in the result file.
This situation roughly corresponds to the situation where the external data source contains invalid or inconsistent data. The rules language allows us to add functionality to record the instances of inconsistent information or even fix it, with minimal changes to the existing processing.