System and method for customizing and processing business logic rules in a business process system6868413Abstract Systems and methods for customizing business logic rules within a business process automation system and for processing business logic rules in a business process automation system are disclosed. The method for customizing business rules of a business logic application generally comprises serving a content page to a client browser of a client by a server that allows entering and modifying of data relating to a business logic rule, generating data by the server according to a predefined format such as a predefined XML format from information received via the content page, and automatically committing the generated data in the predefined format into a database. Preferably, a verification process such as by using DTDs (Document Type Definitions) is performed by the server prior to committing the data. The database stores data including data relating to business logic rules for implementing business logic as entries in the database and the generated data is committed into a corresponding entry in the database. Upon committing, the committed database business rule entry is ready for execution by the business logic application. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE I
COLUMN DATA TYPE DATA DESCRIPTION
SEQUENCE NUMBER Unique ID
LASTMODIFIED DATETIME When record was last modified
MODULE NUMBER Module of the event that the rule
intercepts
METHOD NUMBER Method of the event that the rule
intercepts
NAME VARCHAR Name of business rule
DESCRIPTION TEXT Textual description of business rule
REV_HISTORY TEXT Text field for entering revision
history/rule changes
ENABLED BOOLEAN Enable/disable execution of rule
Business Rules Conditions User Interface 230 FIG. 4 is an exemplary user interface 230 for entering or modifying and displaying conditions of the selected business rule or a new business rule. The business rule conditions are conditions that need to be met in order for the actions defined by the business rule to be triggered. In other words, the conditions are the "if" part of an "if . . . then . . . " statement. Each business rule preferably specifies one or more conditions 232, 234 to be evaluated upon an occurrence of a pre-defined event, e.g., create 236 or update 238, associated with a business rule module 240 such as Help Desk. Preferably for each condition, two expressions 242, 244 and a comparison operator 246 for comparing values of the two expressions as well as a logical operator 248 for allowing grouping of conditions may be specified. The two expressions 240, 242 may be created by the administrator using an expression builder as will be described in more detail below. Examples of comparison operators 236 include equal to, not equal to, less than, less than or equal to, greater than, greater than or equal to, contains, does not contain, and none. Examples of logical operators 238 include and, or, exclusive or, and none. Any other suitable comparison operators and/or logical operators may be utilized. The business logic application preferably processes each condition line by line beginning with the first condition specified in the user interface 230. In the example shown in FIG. 4, the business logic application would evaluate or process the first condition 232 prior to evaluating or processing the second condition 234, if at all. In particular, the business logic application evaluates the first condition 232 to determine if the transaction data for state is equal to C. If the first condition 232 is met, then the business logic application proceeds to evaluate the second condition 234. Alternatively, if the first condition 232 is not met, then the business logic application preferably does not evaluate the second condition 234 as an "AND" logical operator 238 links the first and second conditions 232, 234. TABLE II is an exemplary table that may be utilized to facilitate storage of conditions data of a business rule. The table may optionally be cached in metadata for purposes of efficiency.
TABLE II
COLUMN DATA TYPE DESCRIPTION
SEQUENCE NUMBER Unique ID
LASTMODIFIED DATETIME When record was last modified
SEQ_BL NUMBER Business rule the condition relates
to in the general information
table (TABLE I)
METHOD NUMBER Method (Create, Update, Delete,
Fetch) the rule is called on
POSITION NUMBER Used to control order of testing
DATA TEXT Condition data
Business Rules Actions User Interface 250FIG. 5 is an exemplary user interface 250 for entering or modifying and displaying one or more actions 252 of the selected business rule or a new business rule. In particular, the business rule actions are actions that are to be performed when the conditions are met. In other words, the actions are the "then" part of an "if . . . then . . . " statement. Each business rules includes one or more actions 252. Typically for each action 252, a method 254 to be performed by the action, a module 256 that the action affects, a form 258 to be associated with the action to be performed, as well as details 260 regarding the action may be specified. The method 254 may be selected from, for example, create, update, delete, and fetch. Examples of modules 256 include Help Desk, Notification, and Create Email. The form 258 may be a default form or a customized form corresponding to the selected module 256. Details 260 for the action 252 to be performed may include, for example, values for fields associated with the form 258 and/or any other suitable values. For example, details for a notification form may include subject, message content of and/or recipient of the notification. It is noted that an action may call a module without writing or modifying a record in the database. For example, an action may be "send notification" that calls a notification module upon occurrence of a specified event and does not modify any record in the database. TABLE II is an exemplary table that may be utilized to facilitate storage of action data of a business rule. The table may optionally be cached in metadata for purposes of efficiency.
TABLE III
COLUMN DATA TYPE DESCRIPTION
SEQUENCE NUMBER Unique ID
LASTMODIFIED DATETIME Date that record was last modified
SEQ_BL NUMBER Business rule the condition relates
to in the general information
table (TABLE I)
POSITION NUMBER Used to control order of execution
NAME VARCHAR Name of action
DESCRIPTION TEXT Description of what action does
REV_HISTORY TEXT Revision history
DATA TEXT Action data
Business Rules Schedule User Interface 270 FIG. 6 is an exemplary user interface 270 for entering or modifying and displaying a schedule for the selected business rule or a new business rule. In particular, the business rule may be scheduled to run via the schedule user interface 270. The schedule user interface 270 allows specification of when the business logic rule is to run. The business rule may be scheduled to run immediately 272 and/or at a later time 274. In the example shown in FIG. 6, the rule is to be run immediately. Regardless of the immediate or deferred specification, execution of business rules will generally be performed asynchronously to the operation that they intercepted. If the later time option 274 is selected, the scheduling may be determined utilizing either data 276 or a placeholder for current or transactional data as specified via the expression builder 278. For example, a specific start time 280 may be specified or a start time 280 may be described utilizing the expression builder 278 option. In addition, an optional offset 282 may be specified such that the action of the business rule would be delayed by an amount specified by the offset 282 after the specified start time 280. In the preferred embodiment, the offset 282 may be set only when the data option 276 is selected. The schedule user interface 270 further allows the administrator to set an optional repeat interval 284, an optional time to repeat 286 such as a finite number 288 or indefinitely or infinitely 290. A work schedule 292 and/or a time zone 294 may also optionally be set. With a specified work schedule 292, if the business rule is set for "at a later time" and that time is outside of the specified work schedule 292 for the specified time zone 294 or the default time zone if no time zone is specified, then, according to one embodiment, the rule will not fire until it is within the work schedule 292. The customizable business logic application preferably disallows enabling of the business rule until all requisite information has been defined, such as via the exemplary general information, condition, action, and schedule user interfaces. The requisite minimum information may include, for example, general information, one condition, one action, and one scheduled time. In addition, once the administrator has completed designing the new or modifying the selected business rule, the new or modified business rule can be saved and committed to the database. Prior to committing a business rule to the database, the customizable business logic application preferably performs a design time validation process to validate the rule conditions, actions data, and schedule of the business rule. Alternatively, the customizable business logic application may only perform the validation process on enabled business rules while allowing the saving of a non-enabled business rule that may not be valid or may only be partially specified to the database. TABLE IV is an exemplary table that may be utilized to facilitate storage of schedule data of a business rule. The table may optionally be cached in metadata for purposes of efficiency.
TABLE IV
COLUMN DATA TYPE DATA DESCRIPTION
SEQUENCE NUMBER Unique ID
LASTMODIFIED DATETIME Date that record was
last modified
SEQ_BL NUMBER Business rule condition
relates to in the general
information table (TABLE I)
RUN_IMMEDIATELY BOOLEAN Run rule immediately when
event occurs
RUN_DEFERRED BOOLEAN Run rule at a later time
INTERVAL VARCHAR Specifies interval at which
rule will run (Supports
business logic expressions)
REPEAT_TIMES VARCHAR Maximum number of times
rule will run (supports
business logic expressions)
WORK_SCHEDULE VARCHAR Allows specification of a
work schedule for the rule
(supports business logic
expressions)
TIME_ZONE VARCHAR Allows specification of a
time zone for the rule
(supports BL expressions)
DATE_TIME VARCHAR Specifies a date/time to
run the rule (once only)
(Supports BL expressions)
DATE_TIME_OFFSET VARCHAR Specifies an offset adjustment
that will be applied to the
DATE_TIME
Building Expressions Using Expression Builder Utility FIG. 7 is an exemplary expression builder utility user interface 296 for entering or modifying expressions for business rules of the customizable business logic application. As discussed above, some of the conditions and schedule information of the business rule may be expressed as expressions that may be entered via an expression builder. Thus, the customizable business logic application preferably provides an expression builder utility to facilitate the administrator in entering expressions as part of defining business rules and/or business rules templates. The expression builder utility preferably allows the administrator to enter expressions that contain, for example, one or more business logic symbols and any optional text. Expressions are values that are entered by the administrator that can contain a set of symbols to be resolved at various stages of the business rule execution cycle. The symbols allow access to various event-related and/or other system-related information that can be directly inserted into, for example, grammatical sentences used as the body of an e-mail message. Symbols generally refer to recognized text strings. When used in a string specified as a property on a field, symbols allow access to information that is variable at the time the business rule instance is created and/or executed. The following are examples of expressions in which symbols are designated with brace characters { }. Examples of expressions include: Hello, the time is {TIME}. The Help Desk Ticket {TR, Problem No.} was created in response to your request on {DATE} at {TIME}. {DB, Clients, Client ID, "Sequence"=1221} As shown in the sample expression builder user interface 296, symbols may represent various types of data such as current record data, transaction data, symbolic values, system environmental variables, and/or database lookup, business rules templates, mathematical operations, and/or action return sequence. Each of these is described in more detail below. Current record data and transaction data are transient data that may be represented in an expression. Transient symbols are collections or record data that is made available to business logic when rules are being executed. In other words, transient symbols are used to refer to data that is made temporarily available during the execution of business rules. Transient data allows business rules to refer to or examine data items such as the transactional data and current data. Transaction data refers to data that is sent to a business logic call that the business rule intercepted or that is otherwise used to perform the operation that the given business rule intercepted. For example, where the intercepted method is update and causes the business logic to fetch the record set that is to be updated prior to the operation to allow comparisons to be made in business logic, the transaction data represents the current state of a specified set of rows in the database. Transaction data may also be utilized where the method is create and represents the new data that is to be saved to an existing or new record for create and update operations. In contrast, current data refers to data that existed in the database prior to the operation that the given business rule intercepted for update and delete operations, i.e., data in the database before the record was deleted or updated. Symbolic values generally represent data that is substituted when the symbol is resolved or evaluated as part of an expression. Although not necessarily constant, symbolic values represent static data that are resolved at the time the business logic executes. Examples of symbolic values include current time, current time zone, current date, name of database server being used, type of database (e.g., Oracle or MS SQL), current event module, current event method, version of the business logic, description of the business logic, version of the database, user who initiated the event, name of application server, sequence number of the rule, name of the rule, description of the rule, and name of virtual directory of the application server. System environmental variables generally represent the values of specified environment variables on the server. System variables typically are evaluated with data obtained from the application server. Database lookup allows a query to find and use data in the database and represents a fetch operation from the database when resolved. Database lookup is preferably performed at the time of the business rule execution particularly if the rule is scheduled for deferred or repeat execution. Typically a database fetch operation may be used in place of adding a virtual field to a table or for conditions where there is no relationship between the transactional or current data and a particular table that stores information for which access is needed. Preferably, business rules templates are provided. Business rules templates are predefined and reusable text items that can be defined, stored, and reused by various business rules. Templates are especially suitable for reuse of large text strings such as for sending out a standard email message via several different business rules. Templates are typically stored in the database and managed through the presentation layer or top tier. Templates allow the same string of text to be re-used by multiple business rules. Business rules templates typically are notifications and other text string templates. For example, various types of help desk notification messages typically all include certain common information such as the help desk ticket number, the problem number, open and/or close date, severity, expected resolution time, problem description, and/or problem resolution. The expression builder preferably supports mathematical operation symbols. A mathematical calculation symbol accepts argument(s) and hands them off to the back end database for processing. In the absence of having another symbol to solve a problem, the mathematical calculation allows the use of SQL (Structured Query Language) for advanced calculations. The expression builder preferably also supports action return sequence symbols. An action return sequence may be used in a business rule with multiple actions to find out the sequence of the record that a specified action affected. In particular, actions are indexed by a number that corresponds to their position as displayed in the user interface. An action return sequence symbol is generally only valid in a context of executing business rule actions such that if an action return sequence symbol is used in a business rule condition, an empty string may be returned. It is noted that embedded expression symbols are preferably supported. An example of embedded expressions is: {DB, Help Desk, Problem Description, "Problem #"={TR, Problem #}} In the example above, the inner symbol {TR, Problem #} is embedded within the outer symbol {DB . . . }. When embedded symbols are resolved, the inner most symbols are preferably resolved first followed by each successive outer symbol. Symbol resolution is a phase of business rule execution that searches an expression for business logic symbols and replaces each symbol with a corresponding resulting value of that symbol. Depending upon the symbol, the symbol can be resolved when the business rule instance is created, i.e., pre-queue, or when the business rule instance is executed, i.e., post-queue. Pre-queue symbol resolution is a phase of business rule execution that resolves all symbols in an expression that are to be resolved when the business rule instance is created in a job queue. Post-queue symbol resolution is a phase of business rule execution that resolves symbols in an expression that are to be resolved when the business rule instance is executed from the job queue. Job queue will be described in more detail below. TABLE V illustrates examples of transaction, current, and database fetch operation symbols as well as whether resolution of which is pre-queue or post-queue.
TABLE V
Symbol Description Example(s) Resolution
{TR,} Transaction data {TR,Status} Pre-Queue
{TR,Sequence}
{TR,23}
{CUR,} Current data {CUR,Client} Pre-Queue
{CUR,LastUser}
{CUR,12}
Symbolic Static data substituted in when {DATE}
Post-Queue
symbol is evaluated/resolved. {TIME}
Post-Queue
{EVENTMODULE} Pre-Queue
{EVENTMETHOD} Pre-Queue
{APPSERVER} Post-Queue
{DBSERVER} Pre-Queue
{DBTYPE} Pre-Queue
{MAGICDBVERSION} Pre-Queue
{TZ} Post-Queue
{BLVERSION} Pre-Queue
{BLDESCRIPTION} Pre-Queue
{BLUSER} Pre-Queue
{RULESEQUENCE} Pre-Queue
{RULENAME} Pre-Queue
{RULEDESCRIPTION} Pre-Queue
{VIRTUALDIR} Pre-Queue
{ENV,} Sever environment variable {ENV,COMPUTERNAME}
Post-Queue
{ENV,USERDOMAIN}
{ENV,WINDIR }
{DB,} Database fetch {DB,Clients,ClientID, Post-Queue
"SEQUENCE"=222}
{TEMPL,} Template text substituted {TEMPL,name} Pre-Queue
{MATH,} Mathematical calculation {MATH,1 + 2} Post-Queue
{MATH,100/50}
{AR,} Action Return Sequeuce {AR,1} Post-Queue
{AR,5}
[sequence of database
record involved in 1.sup.st and
5th actions, respectively]
FIG. 8 is a flowchart illustrating a business logic customization process 300 for creating, modifying, and managing customized business rules in a customizable business logic application. At step 302, the administrator enters or modifies general information regarding a new or selected existing business rule such as via a general information business rules user interface. At step 304, the administrator enters or modifies condition information regarding the new or selected business rule such as via a condition business rules user interface. At step 306, the administrator enters or modifies action information regarding the new or selected business rule such as via an actions business rules user interface. At step 308, the administrator enters or modifies schedule information for the new or selected business rule such as via a schedule business rules user interface. Examples of each of these user interfaces are described above. It is noted that all of steps 302-308 are preferably performed for a new business rule. However, for modifying an existing business rule, any number of steps 302-308 may be performed in order to modify the existing business rule. In addition, steps 302-308 need not be performed in the order as described. Further, the administrator may return to any of steps 302-308 in order to further modify or add new information. Next, at step 310, XML is generated from data regarding the new or modified business rule as entered or modified via the user interfaces. It is noted that as discussed above, some of the conditions and schedule information of the business rule may be expressed as expressions containing various symbols. Thus, such information expressed in XML may include expressions having symbols. At step 312, the new or modified business rule is verified in a design time verification process. At step 314, the verified new or modified business rule is committed to the database. Each of the design time verification process 312 and XML format are described in more detail below. Design Time Verification Process 312 FIG. 9 is a flowchart illustrating the design time verification process 312 in more detail. The design time verification process 312 is part of an effort to minimize problems resulting from malformed or invalid business logic statements. The design time verification process 312 ensures against any obvious problems with the business logic. For example, problems such as those that may cause a server hang are pinpointed and corrected prior to allowing the administrator to commit the business rule to the database. It is noted that another verification process, a runtime verification process, is preferably also performed on the business logic rules at runtime. In particular, at step 322, verification of expressions, modules, operations, and/or operators specified in the business rule is performed. In particular, the rule conditions, actions data, and schedule of the business rule are verified. For example, step 322 may ensure that the expressions, modules, operations, and/or operators are specified in the correct context and have valid values for their defined data types is performed. Preferably, step 322 utilizes DTDs (Document Type Definitions) to verify business rules represented in XML. Next at step 324, the design time verification process determines if there are any errors. If no errors are found, then the process 312 is complete. Alternatively, if any errors are found, such errors are reported to the administrator via a user interface at step 326. Once the administrator reaches the design time verification process 312 such as by selecting to commit the business rule at the database, the design time verification process 312 returns to step 322 until all errors have been corrected. XML Format XML (Extensible Markup Language) is preferably utilized to represent and store data regarding the business rules in the database. In particular, condition and action data are preferably represented in XML and stored in the XML format in the database. The use of XML to represent business rules allows the use of DTDs (Document Type Definition) for validation of the business rule information and thus facilitates in preventing malformation of business rules. Specifically, conditions of business rules are preferably stored in a defined XML format in a logical layout. Similarly, actions of business rules are preferably stored in a defined XML format with a logical layout that allows calls to be made to actions with a set of action parameters (as defined via action details in the example shown in FIG. 5). Thus, the XML representation provides a simplistic approach to building and validating basic IF . . . THEN constructs. It is noted that XML representation of conditions and actions of business rules may include expressions that are to be resolved during execution of the business rule. TABLE VI illustrates an exemplary format of the condition data as stored in the database according to one preferred embodiment. In addition, the following is an example of a business logic condition as represented in XML which may be stored in the database: <ROOT> <CONDITION 01="TR.7" CO="NOT_EQUAL" 02="Joe" LO="AND"/> <CONDITION 01="TR.1002" CO="EQUALS" 02="C"/> </ROOT>
TABLE VI
ROOT CONDITION OPERAND COMPARISON OPERAND
LOGICAL
NODE NODE 1 OPERATOR 2
OPERATOR
<ROOT>
<CONDITION O1="{EXPR}" CO="{
O2="{EXPR}" LO="{ >
EQUALS
AND.vertline.OR}"
.vertline.NOT_EQUALS.vertline.
GREATER_THAN.vertline.
LESS_THAN_OR_EQ.vertline.
LESS_THAN.vertline.
GREATER_THAN_OR_EQ.vertline.
CONTAINS }"
<CONDITION>
. . .
</ROOT>
TABLE VII illustrates an exemplary XML format of the action data as stored in the database according to one preferred embodiment. In addition, the following is an example of a business logic action as may be stored in the database: <ROOT> <ACTION MODULE="27" METHOD="2"> <PARAM NAME="1002">C</PARAM> <PARAM TYPE="HTMLFORM" NAME="1003">23 </PARAM> <PARAM TYPE="VALUE" NAME="1004">23</PARAM> <PARAM TYPE="VALUE" NAME="1005">{Tr.User} has closed help desk ticket {TR.Ticket #} at {Time}</PARAM> <PARAM TYPE="VALUE" NAME="1006">{Date} {Time} <PARAM> </ACTION> </ROOT>
TABLE VII
ROOT ACTION MODULE TO METHOD TO
NODE NODE CALL CALL
<ROOT>
<ACTION MODULE="..." METHOD="{Create.vertline.
Update.vertline.
Fetch.vertline.
Delete}"
PARAM
NODE NAME VALUE
<PARAM NAME="..." text value
</PARAM>
. . .
</ACTION>
</ROOT>
As is evident, the business logic customization process 300 is a front-end process that provides easy to use user interfaces through which the administrator may non-programmatically, i.e., without directly writing computer software code within the business logic application, customize business logic. Such a customization process typically allows more flexibility and is more efficient in terms of both time and costs than, for example, a back-end customization process that requires programming or hard-coding computer software code in order for customization. Furthermore, the business logic customization process 300 is ideally a dynamic process in which once a given customized business logic rule is committed to the business logic application, the customized business logic rule is ready for execution. In one embodiment, when a newly created or a modified business rule is committed to the database, a row of XML is added or modified within the database by the customizable business logic application. The business logic customization process is generally also reusable within different areas of the business logic application. For example, the business logic customization process may be utilized to facilitate migration from a legacy business logic application to the customizable business logic application. Business Rule Execution Process After a business rule is committed to the database, it is ready to be executed within the customizable business logic process. FIG. 10 is a block diagram illustrating some components of the application/web server 120 for processing and executing processes of the customizable business logic application. As shown, the application/web server 120 generally includes a job queue module 126 and a notification module 128. Each of the job queue module 126 and the notification module 128 may be implemented within the server 120 as filters that run on the application/web server 120 until they are shut down. Job Queue Module 126 The job module 126 process jobs in the job queue. The job queue is a service or processing mechanism that runs on the application/web server and continues running until, for example, IIS (Internet Information Server) and MTS (Microsoft Transaction Server) are shut down. The job queue is responsible for processing event jobs created or reported by the business logic application and for processing business rule instances created from event jobs. In other words, the job queue actually executes the business rule instances. In addition, the job queue mechanism is preferably responsible for implementing the timing of business rule execution. In particular, the job queue performs business rule scheduling tasks such as delay or reschedule job execution, e.g., with respect to a time zone and/or a work schedule specified for the particular business rule, and/or recalculate repeat times for instances of business rules in a queue. The job queue also suspends business rule instances that fail in unexpected or expected conditions. Preferably, the job queue provides methods for easy manipulation of the jobs via user interface. Notification Module 128 A notification process is a service that, similar to the job queue, is called once and remains active until it is shut down. The notification process may handle incoming and outgoing notification tasks and report events to the business logic system. For example, the notification module 128 may monitor incoming e-mail help desk requests for a specified MAPI profile using CDO (Collaboration Data Objects). When a matching incoming e-mail message arrives, the notification process reports the events to the business logic system. For outgoing notification tasks, the notification module 128 may also handle outgoing notification events such as sending out mail, pager, telalert and/or netsend notifications. Preferably, the notification process supports multiple messaging platforms such as MS Exchange, Lotus Notes, and Novell GroupWise, MAPI as well as SMTP e-mail. The notification module 128 may include or, alternatively, may communicate with a mail queue for notification-related tasks. The mail queue is a processing mechanism that facilitates the listening of incoming e-mail and the delivery of outbound e-mail. As is evident, any number of business logic rules may be based around a given event reported to the business logic system by the notification module 128. Thus, any number of business rule instances may be created as a result and any number of actions may be taken as a result of the one event reported by the notification module 128. FIGS. 11A and 11B are flowcharts illustrating a process 700 for business rule execution upon each event occurrence. At step 702, an event occurs. At step 704, the business logic system determines if there are any business rules based around the event that occurred. If there are no business rules based around the event occurrence, then process 700 ends. Alternatively, if there is at least one business rule based around the event occurrence, then at step 706, any embedded pre-queue-type symbols in expressions of the business rule based around the event occurrence are resolved. At step 708, an event job corresponding to the business rule is written to the job queue. An event job is a job that is created in the job queue when an event occurs in the business logic application system. Each event job may contain information about the event module and method, the transaction data, and the current record data. It is noted that any number of business rules may be based around a given event occurrence. However, for purposes of clarity only, the business rule execution process 700 is described with reference to one business rule being based around the event occurrence. Next, a conditions pre-evaluation is performed at step 710 in which the business logic system determines if all the conditions for an instance of the business rule are met prior to writing the business rule instance into the job queue. If the conditions are false, i.e., not met, a business rule instance is not created and the original event job is deleted from the job queue at step 712 and the business rule execution process is complete. Alternatively, if the conditions are true, i.e., met, a business rule instance is created and written to the job queue and the original event job is deleted from the job queue at step 714. One advantage of the conditions pre-evaluation step is that it facilitates in decreasing unnecessary build-up of business rule instances in the job queue that would eventually evaluate to false. A business rule instance is a copy of a business rule that is supplemented by information about the event and additional scheduling calculations. When a given event occurs multiple times, many instances of the business rule are created in the job queue. Referring now to FIG. 1B, at step 716, at a scheduled time for execution, the business rule instance is read from the job queue and any embedded post-queue-type symbols in expressions of the business rule instance are resolved. At step 718, the business logic system determines if all the conditions for the business rule instance are met. If not, then the business rule instance is removed from the job queue at step 720 and the business rule execution process is complete. Alternatively, if the conditions for the business rule instance are met, then at step 722, one or more actions specified by the business rule are executed and/or rescheduled based on business rule instance scheduling parameters and the business rule instance is removed from the job queue. Runtime Verification Process Although not expressly shown, the business rule process 700 also includes a runtime verification process. In particular, the runtime verification process checks that correct data types are being compared and assigned and checks for errors in conversion of data types, handling module and module parameter related errors, and elements of expressions that may not be available in various situations. Runtime errors that occur may be reported through, for example, a system message monitor. The runtime verification process, in addition to the design time verification process, minimizes problems resulting from malformed or invalid business logic statements. The runtime verification process is preferably run during step 706 (pre-queue resolution), 710 (condition evaluation), 716 (post-queue resolution), and 722 (actions execution). Resolution of Pre- and Post-Queue Symbols in Expressions FIG. 12 is a flowchart illustrating a symbol resolution process 750. In particular, the symbol resolution process 750 is a phase of business rule execution that searches an expression for business logic symbols and replaces each symbol with the resulting value of that symbol. Depending upon the symbol, the symbol can be resolved when the business rule instance is created, i.e., pre-queue, or when the business rule instance is executed, i.e., post-queue. Pre-queue symbol resolution is a phase of business rule execution that resolves all symbols in an expression that are to be resolved when the business rule instance is created in the job queue. Analogously, post-queue symbol resolution is a phase of business rule execution that resolves symbols in an expression that are to be resolved when the business rule instance is executed from the job queue. The symbol resolution process 750 preferably resolves symbols in an expression by hierarchically parsing and employing a recursive algorithm. In particular, the recursive process builds an XML tree in memory that allows for efficient management of the symbols and text in an expression. The symbols preferably support embedding such that the hierarchical parsing of this information is made easier via XML. XML also allows automatic validation of this data and XSLT (Extensible Stylesheet Language Transformations) is preferably used to instantaneously extract the data once the XML tree is built in memory. In particular, at step 752, an expression is parsed for the hierarchically highest symbol(s). At step 754, the resulting symbols from step 752 are resolved. For example, with symbols are embedded within other symbols, inner-most symbols are resolved first while the outer-most symbols are resolved last. At step 756, it is determined if there are any symbols remaining to be resolved. If so, then the process 750 returns to step 752 to parse the expression for the next symbol(s) to be resolved. Alternatively, if all the symbols have been resolved in the expression, then the symbol resolution process 750 is complete. General Purpose Computer System for Use By The Business Logic Application FIGS. 13 and 14 illustrate a schematic and a block diagram, respectively, of an example of a general purpose computer system 1000 suitable for executing software programs that implement the methods and processes described herein. The architecture and configuration of the computer system 1000 shown and described herein are merely illustrative and other computer system architectures and configurations may also be utilized. The illustrative computer system 1000 includes a display 1003, a screen 1005, a cabinet 1007, a keyboard 1009, and a mouse 1011. The mouse 1011 can have one or more buttons for interacting with a GUI (graphical user interface) that may be displayed on the screen 1005. The cabinet 1007 typically house one or more drives to read a computer readable storage medium 1015, system memory 1053, and a bard drive 1055, any combination of which can be utilized to store and/or retrieve software programs incorporating computer codes that implement the methods and processes described herein and/or data for use with the software programs, for example. Examples of computer or program code include machine code, as produced, for example, by a compiler, or files containing higher level code that may be executed using an interpreter. Computer readable media may store program code for performing various computer-implemented operations and may be encompassed as computer storage products. Although a CD-ROM and a floppy disk 1015 are shown as exemplary computer readable storage media readable by a corresponding CD-ROM or floppy disk drive 1013, any other combination of computer readable storage media can be utilized. Computer readable medium typically refers to any data storage device that can store data readable by a computer system. Examples of computer readable storage media include tape, flash memory, system memory, and hard drive may alternatively or additionally be utilized. Computer readable storage media may be categorized as magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and specially configured hardware devices such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and ROM and RAM devices. Further, computer readable storage medium may also encompass data signals embodied in a carrier wave, such as the data signals embodied in a carrier wave carried in a network. Such a network may be an intranet within a corporate or other environment, the Internet, or any network of a plurality of coupled computers such that the computer readable code may be stored and executed in a distributed fashion. Computer system 1000 comprises various subsystems. The subsystems of the computer system 1000 may generally include a microprocessor 1051, system memory 1053, fixed storage 1055 (such as a hard drive), removable storage 1057 (such as a CD-ROM drive), display adapter 1059, sound card 1061, transducers 1063 (such as speakers and microphones), network interface 1065, and/or scanner interface 1067. The microprocessor subsystem 1051 is also referred to as a CPU (central processing unit). The CPU 1051 can be implemented by a single-chip processor or by multiple processors. The CPU 1051 is a general purpose digital processor which controls the operation of the computer system 1000. Using instructions retrieved from memory, the CPU 1051 controls the reception and manipulation of input data as well as the output and display of data on output devices. The network interface 1065 allows CPU 1051 to be coupled to another computer, computer network, or telecommunications network using a network connection. The CPU 1051 may receive and/or send information via the network interface 1065. Such information may include data objects, program instruction, output information destined to another network. An interface card or similar device and appropriate software implemented by CPU 1051 can be used to connect the computer system 1000 to an external network and transfer data according to standard protocols. In other words, methods and processes described herein may be executed solely upon CPU 1051 and/or may be performed across a network such as the Internet, intranet networks, or LANs (local area networks), in conjunction with a remote CPU that shares a portion of the processing. Additional mass storage devices (not shown) may also be connected to CPU 1051 via the network interface 1065. The subsystems described herein are merely illustrative of the subsystems of a typical computer system and any other suitable combination of subsystems may be implemented and utilized. For example, another computer system may also include a cache memory and/or additional processors 1051, such as in a multi-processor computer system. The computer system 1000 also includes a system bus 1069. However, the specific buses shown are merely illustrative of any interconnection scheme serving to link the various subsystems. For example, a local bus can be utilized to connect the central processor to the system memory and display adapter. The computer system 1000 may be illustrative of the computer system of any or all of the computation nodes represented by the client, the server, and/or the database, for example, of a computing system in which the customizable business logic application system and method may be implemented. While the preferred embodiments of the present invention are described and illustrated herein, it will be appreciated that they are merely illustrative and that modifications can be made to these embodiments without departing from the spirit and scope of the invention. Thus, the invention is intended to be defined only in terms of the following claims.
|
Same subclass Same class Consider this |
||||||||||