The subject matter described herein relates to a unifed type system including a rules engine that can work with different heterogeneous calling applications to provide calibration alerts.
An increasing number of software applications are utilizing rules engines to execute rules when triggering actions occur. However, the rules engines for such applications are typically proprietary requiring custom rule definitions having unique formats to be generated for each application.
A rules engine is provided that can work with various heterogeneous calling applications. Such a rules engine can be part of a larger framework which, for example, can provide calibration alerts and the like when certain rule conditions are met. In some implementations, the framework can allow for the identification and mitigation of bias against certain employees and/or classes of employees within a larger organization.
In an interrelated aspect, an application programming interface (API) of a rules engine receives a request from a calling application to apply rules. Thereafter, it is resolved which objects should be exposed in response to the request. It can then be determined whether one or more fields in the objects to be exposed meet one or more conditions specified by the rules specified in the request. Data characterizing the determination can then be provided to the calling application.
The resolving can be supported by a meta data access component that identifies which objects should be exposed in response to the request.
A property resolver component can be called to determine additional properties associated with the request that are not specified in such request by the calling application.
A function implementation component can be called to execute additional functions associated with the calling application in application of the rules.
The rules can be associated with a bias determination within a company. In some cases, in response to the provided data (and optionally the data additional resolved by the rule engine and/or the executed functions), at least one alert is provided via a graphical user interface indicating the presence of potential bias.
The request can further specify object instances against which the rules are to be applied. In some variations, the request further encapsulates the object instances.
Non-transitory computer program products (i.e., physically embodied computer program products) are also described that store instructions, which when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform operations herein. Similarly, computer systems are also described that may include one or more data processors and memory coupled to the one or more data processors. The memory may temporarily or permanently store instructions that cause at least one processor to perform one or more of the operations described herein. In addition, methods can be implemented by one or more data processors either within a single computing system or distributed among two or more computing systems. Such computing systems can be connected and can exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc.
The subject matter described herein provides many technical advantages. For example, the current subject matter enables the application of rules using a meta data approach that enables different heterogeneous applications to utilize a single external rules engine.
The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims.
The current subject matter is directed to a rules engine that can work with various heterogeneous calling applications. Such a rules engine can be part of a larger framework which, for example, can provide calibration alerts and the like when certain rule conditions are met. In some implementations, the framework can allow for the identification and mitigation of bias against certain employees and/or classes of employees within a larger organization.
The rules engine 130 can also include a rules engine runtime component 134 which can be called by calling applications 135. The calling applications 135 can specify which rules are to be run against which object instances and, in some variations, the calling applications 135 can also provide the object instances themselves. The rules engine runtime component 134 can provide information about which rules are to be executed and the effective time for such rules to be executed. The calling applications 135 can use heterogeneous formats which are either harmonized by the rules engine runtime component 134 or are responded to using a single format. Stated differently, the rules engine runtime component can provide top level/entrance data for rule execution. The objects returned by the rules engine runtime component 134 can be in a different phase than what is provided by the application so that the rule can be applied.
The rules engine runtime component 134 can delegate requests (by passing applicable objects) to a different rules engine such as rules engine utilizing MVFLEX Expression Language (MVEL). Further, the rules engine 130 can call a property resolver component 124 that can help identify any properties that are not specifically identified and which can affect the execution of applicable rules. Further, the rules engine 130 can call a function implementation component 126 for applications that have unique or otherwise new functions for use in connection with specific rules.
As one example, the calling application 135 can specify a rule—IF a.b.c=“124”—The calling application 135 can pass object instance corresponding to ‘a’ to the rules engine 130. The rules engine 130 can ask the property resolver 124 for ‘a’ to return value for ‘b’ on object instance of ‘a’. The property resolver 124 can then return an object instance of type ‘x’ (corresponding to the field type of ‘b’). Further, the rules engine 130 can ask property resolver 124 for ‘x’ to return value for ‘c’ on object instance of ‘x’ (a.b). The property resolver 123 can then return a string to the rules engine 130 which, in turn, then compares such string with ‘124’.
The exposing of the objects can be an iterative process. In particular, in some variations, not all objects are resolved at once—but only those which are required for each part of the condition criteria or actions. This iteration can be done in a way to reduce processing resource consumption (only read those objects which are required because if one of the criteria is not met, the condition is not executed any further). If none of the conditions (if, else if, else if . . . ) are met, the rule is not executed any further. For everything which is not executed, no objects/properties are resolved.
In one implementation of the architecture of
One or more aspects or features of the subject matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) computer hardware, firmware, software, and/or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
These computer programs, which can also be referred to as programs, software, software applications, applications, components, or code, can include machine instructions for a programmable processor, and/or can be implemented in a high-level procedural language, an object-oriented programming language, a functional programming language, a logical programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and/or device, such as for example magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs), used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable data processor. The machine-readable medium can store such machine instructions non-transitorily, such as for example as would a non-transient solid-state memory or a magnetic hard drive or any equivalent storage medium. The machine-readable medium can alternatively or additionally store such machine instructions in a transient manner, such as for example as would a processor cache or other random access memory associated with one or more physical processor cores.
The computer components, software modules, functions, data stores and data structures described herein can be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code. The software components and/or functionality can be located on a single computer or distributed across multiple computers depending upon the situation at hand.
In one example, a disk controller 548 can interface one or more optional disk drives to the system bus 504. These disk drives can be external or internal floppy disk drives such as 560, external or internal CD-ROM, CD-R, CD-RW or DVD, or solid state drives such as 552, or external or internal hard drives 556. As indicated previously, these various disk drives 552, 556, 560 and disk controllers are optional devices. The system bus 504 can also include at least one communication port 520 to allow for communication with external devices either physically connected to the computing system or available externally through a wired or wireless network. In some cases, the communication port 520 includes or otherwise comprises a network interface.
To provide for interaction with a user, the subject matter described herein can be implemented on a computing device having a display device 540 (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information obtained from the bus 504 to the user and an input device 532 such as keyboard and/or a pointing device (e.g., a mouse or a trackball) and/or a touchscreen by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback by way of a microphone 536, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input. In the input device 532 and the microphone 536 can be coupled to and convey information via the bus 504 by way of an input device interface 528. Other computing devices, such as dedicated servers, can omit one or more of the display 540 and display interface 524, the input device 532, the microphone 536, and input device interface 528.
In the descriptions above and in the claims, phrases such as “at least one of” or “one or more of” can occur followed by a conjunctive list of elements or features. The term “and/or” can also occur in a list of two or more elements or features. Unless otherwise implicitly or explicitly contradicted by the context in which it is used, such a phrase is intended to mean any of the listed elements or features individually or any of the recited elements or features in combination with any of the other recited elements or features. For example, the phrases “at least one of A and B;” “one or more of A and B;” and “A and/or B” are each intended to mean “A alone, B alone, or A and B together.” A similar interpretation is also intended for lists including three or more items. For example, the phrases “at least one of A, B, and C;” “one or more of A, B, and C;” and “A, B, and/or C” are each intended to mean “A alone, B alone, C alone, A and B together, A and C together, B and C together, or A and B and C together.” In addition, use of the term “based on,” above and in the claims is intended to mean, “based at least in part on,” such that an unrecited feature or element is also permissible.
The subject matter described herein can be embodied in systems, apparatus, methods, and/or articles depending on the desired configuration. The implementations set forth in the foregoing description do not represent all implementations consistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject matter. Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and/or variations can be provided in addition to those set forth herein. For example, the implementations described above can be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed above. In addition, the logic flows depicted in the accompanying figures and/or described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Other implementations may be within the scope of the following claims.