JP2005521111A - Business process policy object - Google Patents

Abstract

This application relates to methods, systems, and computer-readable media for employing and accessing objects that model and implement business process policy logic. The adoption of objects in business process policy computing manages and optimizes business processes and execution. In addition, business process policy objects simplify mitigating problems associated with incorporating business process policy logic across computer components, technologies, and boundaries. Thus, users of business process policy objects can focus on using technology to increase business value by executing business strategies, rather than focusing on technology integration issues. The methods, systems, and computer-readable media described herein relate to a dynamic, data-driven environment where business process policies are treated as generic objects in an object-based computing environment. The adoption of business process policy objects facilitates reusability, portability, simplified messaging, and simplified integration with disparate technologies and applications.

Description

(Claiming priority)
This application claims priority based on US Provisional Application No. 60 / 303,424, filed July 6, 2001, entitled “Systems and Techniques for Treating Business Practice Policies as Generic Objects”. Is.

  The methods, systems, and computer-readable media described herein generally relate to object-oriented programming, and more particularly to the adoption of objects in business process policy computing.

  Traditionally, logic that implements business process policies has been implemented in stand-alone computer applications that have been difficult to align with different computer components and technologies in a business environment. This problem occurs at least in part because conventional applications are designed to run on a single computer and / or using a single technology.

(wrap up)
The following provides a brief summary of the methods, systems, and computer-readable media associated with business process policy objects. This summary is not an extensive overview and is not intended to identify key or critical elements of the method, system, and / or medium, or to indicate the scope of the method, system, and medium. . This conceptually identifies the method, system, and medium in a simplified form as a prelude to the more detailed description that is presented later.

  This application relates to methods, systems, and computer-readable media for employing and accessing objects that model and implement business process policy logic. The adoption of objects in business process policy computing manages and optimizes business processes and execution. Furthermore, business process policy objects simplify mitigating problems associated with incorporating business process policy logic across computer components, technologies, and boundaries. Thus, users of business process policy objects can focus on using technology to increase business value by executing business strategies, rather than focusing on technology integration issues. The methods, systems, and computer-readable media described herein relate to a dynamic, data-driven environment where business process policies are treated as generic objects in an object-based computing environment. The adoption of business process policy objects facilitates reusability, portability, simplified messaging, and simplified integration with disparate technologies and applications.

  Accordingly, one aspect of the present application relates to a method for implementing business process policy logic within an object. This method provides access to data elements and / or methods through object-oriented messaging, providing data elements related to business logic modeling, providing methods related to business logic modeling Including providing an interface to business logic. The method also holds the data element, holds the method, instantiates an instance of an object that implements the interface, receives a message into the instance through the interface, and at least partially Includes selectively executing business logic in an instance of an object based on the received message, wherein the business logic includes one or more invocations of the method, and one or more Executed by at least one of the access to the data element.

  Another aspect of the present application relates to a computer in which a method for automatically applying business process policy logic implemented in a business process policy object is implemented. The method includes identifying a business process policy object to which the message is sent and sending a first message to the business practice policy object.

  Yet another aspect of the present application relates to a system for automatically executing business process policies. The system includes a business process policy object that models and implements business logic associated with business practices, and a business management device that performs business management by selectively interacting with the business process policy object.

  Certain illustrative aspects of the methods, systems, and computer-readable media are now described in connection with the following description and the annexed drawings. However, these aspects are indicative of only a few of the various ways in which the principles of the methods, systems, and media may be employed, and thus this example includes such aspects and equivalents. Other advantages and novel features will become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

(Detailed description of the invention)
Hereinafter, example methods, systems, and computer media will be described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the method, system, and computer-readable medium. It may be evident, however, that the methods, systems, and computer-readable media can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to simplify the description.

  An example of the method described herein is to enable implementation of business process policy logic within an object by providing modeling, instantiation, messaging, and selective execution of business logic based on messaging. To do. When a business process policy is modeled and implemented within an object, the object can be exposed to business applications via its instances to facilitate processes such as enterprise management, workflow management, and the like. In one example, objects can be published through a common environment. In this way, objects can be accessed from disparate computer components using interface protocols including but not limited to ODBC / XML, JAVA / EJB, C / C ++, COM and C # /. NET.

  FIG. 1 shows a computer 110 that includes a processor 102, a memory 104, a disk 106, an input / output port 110, and a network interface 112 operatively connected by a bus 108. The executable components of the systems described herein can be located on a computer such as computer 100. Similarly, the computer-executable methods described herein can be run on a computer, such as computer 100. Further, the business process policy object can reside on a computer such as the computer 100. It should be appreciated that other computers can also be employed in the systems and methods described herein.

  The processor 102 can be a wide variety of processors including dual microprocessors and other multiprocessor architectures. The memory 104 can include volatile memory and / or non-volatile memory. Non-volatile memory includes read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc. Including, but not limited to. Volatile memory includes, for example, random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), and double speed synchronous dynamic random access memory ( DDR SDRAM) and Rambus Dynamic Random Access Memory (DRRAM). The disk 106 includes, but is not limited to, devices such as magnetic disk drives, floppy disk drives, tape drives, Zip drives, flash memory cards, and / or memory sticks. Further, the disk 106 includes a compact disk read-only memory (CD-ROM), a writable compact disk drive (CD-R drive), a rewritable compact disk drive (CD-RW drive), and / or a digital versatile disk. Also included are optical drives such as read-only memory (DVD ROM). Memory 104 may store process 104 and / or data 116, for example. Disk 106 and / or memory 104 may store an operating system that controls and allocates resources of computer 100.

  Bus 108 may be a single internal bus that interconnects architectures and / or other bus architectures. The bus 108 may take various forms including a memory bus or memory controller, a peripheral device bus or external bus, and / or a local bus. Local buses include industry standard architecture bus (ISA bus), microchannel architecture bus (MSA bus), extended ISA bus (EISA bus), peripheral device interconnect bus (PCI bus), universal serial bus (USB bus), And various types including a small computer system interface bus (SCSI bus) and the like.

  Computer 100 interacts with input / output device 118 via input / output port 110. Input / output devices 118 may include, but are not limited to, a keyboard, microphone, positioning and selection device (mouse), camera, video card, display, and the like. The input / output port 110 may include, but is not limited to, a serial port, a parallel port, and a USB port.

  The computer 100 can operate in a network environment and is therefore connected to the network 120 by the network interface 112. Through the network 120, the computer 100 can be logically connected to the remote computer 122. The network 120 includes a local information communication network (LAN), a wide area communication network (WAN), and other networks, but is not limited thereto. The network interface 112 can be connected to a local information communication network technology including an optical fiber distributed interface (FDDI), a copper wiring interface (CDDI), Ethernet (R) /IEEE802.3, Token Ring / IEEE802.5, etc. . Similarly, the network interface 112 can be connected to wide area network technologies including fixed link and circuit switched networks such as Integrated Services Digital Network (ISDN), packet switched networks, digital subscriber lines (DSL), and the like.

  Turning now to FIG. 2, a business process policy object 200 is shown bridging various disparate computing platforms (eg, 210, 220, 230, 240). Traditionally, business process policy logic has been coded in a separate application rather than an object. Therefore, applications could not take advantage of object-oriented analysis, design, and programming. For example, benefits such as reusability, portability, data hiding, encapsulation, interface-based messaging, inheritance, and polymorphism have not been available. It has therefore been difficult to integrate these independent applications and / or span multiple disparate computing platforms. By taking advantage of object-oriented analysis, design, and programming, knowledge can be embedded in objects that mitigate problems associated with crossing various computing platforms (e.g., hardware, software, operating systems) It becomes like this. Similarly, business process policy objects help to interact with various business elements (eg, information management technology, enterprise management technology, rules-based intelligent technology, predictive technology). Thus, in one example, a business process policy object simplifies the interaction between human resources and applications such as workflow, finance, and supply chain. Rather than interacting with a unique stand-alone application where each can require its own coding, combining, messaging, etc., the business process policy object promotes a standard object-oriented messaging interface.

  In FIG. 2, an example business process policy object 200 is shown assisting in interaction between computing platforms 210, 220, 230, and 240. Each of these computing platforms can include various hardware, software, and operating systems in a unique non-uniform combination. The software includes one or more computer-readable and / or executable instructions that cause a computer or other electrical device to perform a function, act, and / or behave as required, It is not limited to these. Directives can be incorporated in various forms such as routines, algorithms, modules, methods, threads, and / or programs. The software can also run various loads and / or loads, including independent programs, function calls (local and / or remote), servlets, applets, instructions stored in memory, parts of the operating system, or browsers, etc. It can also be implemented in a possible format. Computer readable and / or executable instructions can be located in one computer component and / or distributed between two or more computers that perform communication, collaboration, and / or parallel processing. It should be appreciated that, as a result, it can be loaded and / or executed in serial, parallel, massively parallel, and other ways.

  Since the computing platform only needs to implement an interface with the business process policy object 200 and not with each computing platform that it wants to communicate with, the business process policy object 200 is an object-oriented message. -Simplify the interaction between computing platforms by implementing a zing interface. This alleviates the integration and interoperability issues associated with conventional systems.

  Turning now to FIG. 3, an example business process policy object 300 that is employed to enable status visualization of data in an environment that includes event management and business management is shown. One or more business process policy objects 300 are shown interacting with the GUI 310. The GUI 310 enables visualization of the status of data received from the event management device 320 and / or the event management device 330, for example. Event management device 320 and / or business management device 330 may receive data from various resources including business application 340, computer components connected through internet 342, data processing application 344, and other resources 346 and the like. A computer component refers to an entity associated with a computer, either hardware, firmware, software, a combination thereof, or running software. For example, a computer component can include, but is not limited to, a processor running on a processor, a processor, an object, an executable, a thread of execution, a program, and a computer. One or more computer components can reside in a process and / or thread of execution, and the computer components can be located on one computer and / or distributed between two or more computers. .

  Traditionally, a collection of sources, applications, and management devices would have implemented an interface to the GUI 310 separately. With the adoption of the business process policy object 300, the source need only implement an interface to the object 300. Although one GUI 310 is illustrated, it should be appreciated that the object 300 can interact with one or more GUIs 310. Thus, by implementing an interface to the object 300, the source benefits from being able to simplify interaction with the various GUIs 310 that allow context visualization.

  The object 300 can be part of a system that automatically executes business process policies. The system can be used to selectively interact with one or more business process policy objects 300 and one or more business practice policy objects 300 that model and implement business logic related to business practices, for example. A business management device 330 may be included to perform management. Further, the business process policy object 300 can be part of a system that includes an event management device 320 that provides messages to and / or receives messages from the business process policy object 300.

  One source (eg, others 346) from which business process policy object 300 can receive events, messages, etc., is a software robot (BOT). The business process policy object 300 receives information from the BOT and identifies when the event occurred (e.g. bankruptcy, merger, public disclosure, acquisition), why the event occurred (e.g. XYZ revenue To identify how things are related (e.g., XYZ acquired ABC six months ago, so XYZ and ABC revenue are directly related) Selectively execute business logic to answer critical questions. A BOT is an entity that functions as a small web browser that can access and / or generate information. The BOT can, for example, crawl the Internet, create a global resource location indicator (URL) index, correlate data (eg find prices for similar products), match patterns, etc. By way of example, business process policy object 300 may model and implement business logic for optimizing online physical product purchases. Accordingly, one or more BOTs will be released onto the Internet to search, analyze, and report on physical goods in a substantially continuous manner. The business process policy 300 can receive physical commodity data from the BOT and execute appropriate business logic based on the BOT data. The business process policy object 300 implements such logic by, for example, implementing object-oriented messaging, enabling heterogeneous platform implementation and integration, and simplifying logic reusability and extensibility, And is useful for performing such processing.

  Business process policy object 300 can receive information from BOTs at various levels of sophistication. For example, the business process policy object 300 can receive information from a spider BOT that crawls the Internet, indexes the Internet, and provides undiscovered, unindexed data that may be data mined. . Similarly, the business process policy object 300 can also receive information from intelligent BOTs that perform higher level functions such as correlation, pattern recognition, and fuzzy logic processing. In one example, the business process policy object 300 can receive information from a BOT that generates business events for input to the business process policy object 300. The BOT can create events including reference events, change events, threshold events, task end events, task failure events, and the like. A reference event, which can be a non-continuous event, can provide information such as the date the company filed the financial disclosure or a notification that the company has filed the financial disclosure. Change events can be employed to associate previous knowledge that has not yet been associated with other events. For example, a change event may provide information about when a product price page changes or when a company's stock price changes. Threshold events help a simple level of association between current knowledge and previous knowledge. For example, a threshold event can provide information about when a company's stock price has risen or dropped by more than 10% over the previous stock price. The task end event is related to business process knowledge and can therefore provide information about when the task has ended (eg, to inform the business process policy object that the download of financial disclosure data has been completed).

  Events can be associated and aggregated within the business process policy object 300 to facilitate comprehensive command and control by applying business knowledge. Further, the business process policy object 300 can utilize BOT in a certain type of data and event flow in an entity. Thus, the business process policy object 300 can be constructed to detect certain events within the enterprise management system.

  The business process policy object 300 can hold values related to the business practices that it models. Its value can be held in a data element. Data elements can include, but are not limited to values, arrays, lists, and the like. Similarly, the business process policy object 300 may hold computer-executable instructions that implement decisions related to modeling business practices with one or more methods. To allow access to the method and / or data element, the business process policy object 300 can selectively expose the method through an interface.

  Turning now to FIG. 4, an example set of business process policy objects 400 (e.g. 402, 404, 406, 408) is shown interacting with various sources and destinations through a global computer network 420 and event processor 410. Has been. In one example, the source and destination can be provided within the enterprise, and the event processor 410 can be an enterprise management system. In FIG. 4, a collection 400 of business process policy objects includes a local business computer 430, a customer computer 440, a supplier computer 450, a news server 460, an email server 470, a voice mail server 480, and a remote business computer 490. The state of communicating with such an entity is shown. It should be appreciated that business process policy objects can communicate with other entities. This communication occurs through the global computer network 420 (eg, the Internet). The set of business process policy objects 400 may perform services such as command and control services, event management services, workflow management services, and visualization management services. For example, the set of business process policy objects 400 helps define the workflow between the source and destination, checks the status of work in progress, starts the workflow, and / or stops the workflow, etc. A simple workflow management service can be executed.

  FIG. 5 illustrates example business process policy objects (eg, 510, 520, 530) that interact with a heterogeneous collection of applications through non-uniform coupling and common environment 500. For example, the first business process policy object 510 interacts with a business rules expert 512 (eg, CleverPath Aion Business Rules Expert provided by ComputerAssociates International, Inc.) and the common environment 500. Similarly, the second business process policy object 520 interacts with the intelligent technology 522 (e.g., Neugents Neurocomputer provided by ComputerAssociates International, Inc.) and the common environment 500, while the third business process policy object 530 interacts with other applications 532 and common environment 500. In one example, common environment 500 interacts with various applications through various connections. For example, common environment 500 can interact with application 540 through ODBC / XML binding 542. Similarly, common environment 500 can interact with JAVA / EJB application 550 through JAVA / EJB coupling 552. Furthermore, the common environment 500 can interact with the C / C ++ application 560 via the C / C ++ coupling 562 and with the C # /. NET application 580 via the C # /. NET582 protocol. In this way, by modeling and implementing business logic within a business process policy object, various heterogeneous applications can be connected to various applications through various connections through the common environment 500.

  FIG. 6 illustrates, as an example, through a system that employs a business process policy object 600 in combination with an event processing device 610 to selectively execute business logic in a computer component within a company 630 that generates a business event 620. The flow of data and control is shown. To facilitate the collection of additional information related to the business event 620 and / or processing performed by the event processor 610, the business process policy object 600 communicates with the enterprise 630 in a secondary two-way communication. Establishing 640 is shown.

  From the exemplary system shown and described herein, the implemented approach will be better appreciated with reference to the flow diagrams of FIGS. For ease of explanation, the illustrated technique is shown and described as a series of blocks, while some blocks occur in a different order and / or occur concurrently with other blocks therein. It should be recognized that the approach is not limited by the order of the blocks, as is possible. Further, some of the illustrated blocks may be required to implement an example technique. Still further, additional and / or alternative blocks may be employed in additional and / or alternative approaches.

  In the flow diagram, the rectangular blocks represent “processing blocks” that can be implemented, for example, in software. Similarly, the diamond shaped blocks indicate “decision blocks” or “flow control blocks” that can also be implemented, for example, in software. Alternatively and / or additionally, the processing and decision blocks can also be implemented in functionally equivalent circuits such as digital signal processors (DSPs), application specific integrated circuits (ASICs), etc.

  A flow diagram does not represent any particular programming language, technique, or type (procedural, object-oriented) format. Rather, the flow diagram shows functional information that can be adopted by those skilled in the art for programming software, designing circuits, and the like. It should be appreciated that in some examples, program elements such as dummy variables, routine loops, etc. are not shown.

  In one example, the techniques can be implemented as computer-executable instructions and / or actions, and the instructions and / or actions can be implemented in an application specific integrated circuit (ASIC), a compact disc (CD), a digital versatile disc ( DVD, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), disk, propagating wave, memory stick, etc. It can be stored on a computer readable medium.

  Turning now to FIG. 7, a methodology 700 for implementing business process policy logic within an object is illustrated. At 710, business logic is modeled. Modeling includes analysis of business practices to define its logical and / or physical inputs, processes, and outputs. Inputs and outputs can be held in fields in the object, while processing is implemented in computer-executable directives that are grouped as methods. Because the method 700 considers business process policy logic to be captured within an object, business logic modeling can also include defining interfaces with data and / or methods. The interface allows interaction with objects through object-oriented messaging rather than traditional procedure calls. Thus, business logic modeling provides data elements associated with business process policy logic, provides methods associated with business process policy logic, and accesses data and / or methods through object-oriented messaging. Including providing an interface to the business logic that enables it.

  A business process policy object models and implements knowledge (eg, decisions) that are applied to understand, analyze, and / or respond to business events. A business event can be, for example, a message between a source of information and a target (eg, workflow management device, enterprise monitoring device) that describes an important business activity. Business events can also be modeled in objects and communicated to business process policies via, for example, object-oriented messaging. A business event can be associated with a business logic process and can be included in, for example, status reports, status change notifications, data provisions, and the like.

  Illustratively, a business process policy object shall be able to help automatically perform operations such as responding to inventory changes, forecasting sales activity, modest price cuts, and delivery scheduling. These and similar operations can be triggered by, for example, business events and / or messages. The types of business events that a business process policy object can implement logic may include, but are not limited to, reference events, change events, threshold events, task end events, and task failure events. In addition, business process policy objects can model and implement logic that handles individual events and / or collections of events.

At 720, an instance of the object is instantiated. Thus, memory for data elements, instructions for methods, and resources for interfaces are allocated and addressed. Once an object is instantiated, the business logic it models can be employed in an object-oriented environment. Thus, at 730, the message can be received through the interface. The message will be received by the instance created at 720. The message can be a business event, for example. The example business event schema helps to identify the business event description to be reported and details about it. Events can be associated with, for example, object occurrences, business processes, and / or collected knowledge (eg, facts). An example XML schema for a business event handled by a business process policy object is:
<Company A>
<Event name> ... </ event name>
<Namespace> ... </ namespace>
<Object name>
<Class name> ... </ class name>
<Object ID>
<Name_value>
<Name> ... </ name>
<Type> ... </ Type>
<Value> ... </ value>
</ Name_value>
<Name_value>
<Name> ... </ name>
<Type> ... </ Type>
<Value> ... </ value>
</ Name_value>
</ Object ID>
</ Object name>
<Message text> ... </ message text>
<Attribute>
<Name> ... </ name>
<Type> ... </ Type>
<Old value> ... </ old value>
<New value> ... </ new value>
</ Attribute>
</ Company A>

Business logic can be selectively executed at 740 based at least in part on 730 messages. Business logic processing can include, but is not limited to, invoking one or more methods, accessing one or more data elements, and / or updating one or more data elements. Absent. Therefore, in method 700, various business logic options (eg, 750, 752, 754) are shown. These blocks of business logic indicate that multiple, substantially simultaneous paths can be selected based at least in part on the message received at 730. Business logic paths can access data elements and / or methods individually and / or jointly. The business logic modeled and implemented in the business process policy object can be represented by, for example, IF / THEN rules, rules for capturing tables, and neurocomputers. As an example, simple inventory logic can be modeled and implemented with the following IF / THEN rules:
IF stock item <X THEN
Order more inventory items
END IF
Similarly, simple price reduction logic can be modeled and implemented with the following IF / THEN rules:
IF Order Price> Practical Price Limit THEN
Reduce by 10%
ELSE
Reduce the standard price
END IF

  Simple to model and implement advanced logic to handle situations such as new accounts opened, account balances exceeding thresholds, new purchase orders arrived, etc. IF / THEN rules can also be consolidated.

  While business logic within a business process policy object can correspond to an actual business event, the business process policy object can also be a predictive alert generated by a neuroagent that predicts event occurrence (eg, manufacturing failure), for example. Can also interact. For example, a business process policy object can create data that identifies sales orders and deliveries that can be compromised by the occurrence of a failure, and visualizes the failure so that it can respond to such a failure.

  At 760, a determination is made as to whether there are other received messages for the object. If the determination at 760 is yes, the process returns to 730, otherwise the process can end.

  Turning now to FIG. 8, block 710 is shown in more detail. At 712, data elements are provided to help model business logic. Data elements can include, but are not limited to, variables, arrays, tables, lists, stacks, queues, records, and the like. It should be recognized that various data elements can be employed in business logic modeling. In 714, a method for capturing business logic processing is provided. This method can be implemented in a computer-executable directive. It should be appreciated that a method can employ one or more processes, threads, etc., and that a method can access and / or update one or more data elements. At 716, an interface is provided that facilitates object-oriented messaging to access 712 data elements and 714 methods. Although one interface is described with respect to 716, it should be appreciated that a business process policy object can provide and expose more than one interface. By exposing multiple interfaces, the logic modeling provided by the business process policy object becomes available in a variety of situations.

  Turning now to FIG. 9, an example business process policy object 900 is shown. Object 900 can receive message 910 and / or event 912 through its interface 920. Interface 920 allows coordinated access to method 940 to be obtained for programmers / designers, such as data 930, IF / THEN modeling rules 932, rules 934 encoding tables, and neurocomputers. Provide controlled access to 936s in turn. Data element 930 includes object class identifier, object identifier, message identifier, message schema, message format, event text description, current value at discrete business data points, range of discrete business data points, discrete business The value required at the data point, the entity identifier identifying the entity that sent the received message 910 and / or event 912, and the global resource location indication identifying the entity that sent the received message 910 and / or event 912 Children (URLs) can be included, but are not limited to these.

  In an object-oriented environment, the application does not directly access the data 930 and / or method 940, but rather the interface 920 receives a message 910 and / or an event 912, such as data hiding and abstraction, for example. Contributes to function. However, the object 900 is not so limited. In addition and / or alternatively, the object 900 may expose certain data and / or methods 950 to the object-oriented infrastructure 960. This type of access contributes to internal communication between members of the class hierarchy (for example, parent and child). Data and / or methods 950 accessed by the object oriented infrastructure 960 are typically not exposed to general users of the object 900.

  An example business process policy object 900 captures information such as KPIs and business data related to KPIs. Upon receipt of the KPI data, the business process policy object 900 can take measures such as management by exception, event correlation, prediction, notification creation, and the like. For example, the business process policy object 900 can be messaged regarding a business event, and therefore an operation can be selected based on the state of the business process policy object 900 and the data collected for that business event. . As an example, business process policy object 900 can receive data that XYZ reported exceeding expected revenue, and therefore, based on the assumption that XYZ has more money available, for example, sales to XYZ. Measures such as scheduling around can be taken. Business logic assumptions are modeled and implemented in a business process policy object 900. Similarly, if XYZ announces that it is below expected revenue, different business logic (eg, credit period adjustment) can be invoked. In some cases, the business process policy object 900 will require more data to parse and respond to events and / or messages. Thus, the business process policy object 900 can establish a secondary two-way communication with the source of information in order to be able to obtain additional information about the triggering message and / or event. .

  Turning now to FIG. 10, an example object 1000 is shown that includes business process policy logic 1010 and a business process policy object interface 1020. Objects (eg, 1030, 1032, 1034,... 1036) interact with the object 1000 through published interface methods (eg, 1022, 1024,... 1026). Although three exposed methods are shown in FIG. 10, it should be appreciated that more and / or fewer methods can be exposed by the business process policy object interface 1020. Similarly, although four objects are shown in FIG. 10, it should be recognized that more and / or fewer objects can interact with the business process policy object 1000. The exposed methods are the acquisition of a message in XML format, the acquisition of the class of the received object, the acquisition of a unique identifier for the received event, the retrieval of the text description of the received event, when the event is generated Search for attribute names, search for attribute values when an event is generated, search for a unique identifier that identifies the supplier of the event, search for a unique identifier that identifies the entity to which the event relates, and associated with the event Can include methods that contribute to the search for the URL of the actual entity, but are not limited to these.

  The methods exposed by the business process policy object interface 1020 provide access to the business process policy logic 1010 as required by the designer and / or programmer of the object 1000. Logic 1010 (and therefore one or more methods that implement that logic) evaluates one or more IF / THEN rules, evaluates one or more table encoding rules, and one or more. Operations such as interpreting the output from the above neurocomputer are performed. Thus, objects (e.g., 1030, ... 1036) interact with object 1000 through published methods (e.g., 1022, ... 1026), which can, for example, define IF / THEN rules, tables. Selectively activates the rules to be coded and the behavior of the business process policy logic 1010 as implemented in the neurocomputer.

  FIG. 11 shows an exemplary collection 1100 of business process policy objects (eg, 1102,... 1104) that interact with various applications 1130 and perform various functions 1110. Accordingly, as shown in FIG. 11, a set of business process policy objects 1100 includes a manufacturing process 1132, a financial process 1134, a human resource process 1136, an enterprise management function 1140, an enterprise monitoring function 1142, an enterprise resource planning function 1146, Model and implement business logic related to functions including supply chain management function 1148, electronic commerce 1150, KPI processing 1152, etc. Process 1130 can interact with collection 1100 through, for example, object-oriented messaging and / or event passing. The actions 1110 that the set 1100 can perform for the process 1130 include performing rule-based management 1112, generating new events or notifications 1114, generating data suitable for use in the visualization object 1116, application level definition Include, but are not limited to, generating data suitable for use 1118, performing exception management 1120, promoting event correlation 1122, and promoting event prediction 1124.

  As an example, the manufacturing process 1132 may generate an event that is forwarded to the set 1100. One or more business policy objects (eg, 1102,... 1104) can then perform an action based on the event. For example, the business process policy object may apply rule-based management 1112 to events provided by the manufacturing process 1132 to determine, for example, whether the current manufacturing level is below an expected level. Accordingly, the business process policy object can perform an action to generate a new event 1114 that serves to notify other objects, processes, etc. of shortages in the manufacturing process 1132. Further, to simplify the understanding of faults in the manufacturing process 1132, the business process policy object can create data that allows the faults to be displayed graphically and pass the data to the visualization object 1116. Further, business process policy objects or collections 1100 thereof can correlate manufacturing declines with other events (eg, Midwest blizzards impact suppliers that support delivery in time). Thus, based on the initial problem in manufacturing 1132, it is possible to generate an event correlation 1122 that in turn triggers a predictive action 1124 that predicts which retail outlets will suffer shortage. If the deficiency falls outside a certain exception range, then an exception management 1120 can be activated, which can redistribute the output from the manufacturing process 1132, for example.

  Turning now to FIG. 12, an example business process policy object 1200 is shown interacting with multiple processes and multiple events and generating and receiving technology. One application of the business process policy object 1200 is to allow visualization of events, states, changes, process flows, workflows, correlations, and anticipated situations in the business and / or enterprise. The data transferred to the context visualization interface contributes to, for example, business line visualization 210, application level visualization 1212, and role based visualization 1214. Illustratively, the first business process policy object can provide data and / or messages that interact with the tools (e.g., accounting, return on investment) adopted by the finance director, while the second business process. Policy objects provide events, data, and / or messages that interact with tools that inventory control managers adopt (eg, warehouse storage, production, delivery). In this way, various roles within the organization are supported by business process policy objects.

  A state in which the business process policy object 1200 interacts with the business line visualization process 1210 is shown. Business can be seen from different perspectives at different points of time. Accordingly, the business process policy object 1200 provides data that allows the business to be visualized along a line. For example, the production side of the business at the first point in time can be visualized, while the delivery side and the inventory side at different points in time can also be captured.

  Business process policy object 1200 also provides data that contributes to application level visualization 1212. As an example, a first application (e.g., a payable account) can receive data from the business process policy object 1200, and a second application (e.g., a receivable account) can also receive the business process policy object 1200. You can receive information from. In this way, objects help visualize various applications.

  Business process policy object 1200 also provides data useful for role-based visualization 1214. For example, a CEO can receive data of the first form, quantity, and characteristics from a business process policy object 1200 to perform a CEO function, while a clerk can perform a clerk function. Different types, quantities, and characteristics of data can be received from the business process policy object 1200. Therefore, the display screen can be configured according to the role of the viewer. Although business visualization 1210, application-level visualization 1212, and role-based visualization 1214 are shown in FIG. 12, business process policy object 1200 provides other forms of situation visualization, including enterprise management and workflow management, etc. It should be recognized that data suitable for display on the GUI can also be provided.

  The business process policy object 1200 can also interact with various events that generate and / or receive technology. For example, the business process policy object 1200 can interact with the information management technology 1202 and thus receive messages from the information management technology 1202 and / or send messages to the information management technology 1202. Business process policy object 1200 can also interact with enterprise management technology 1204. Accordingly, business process policy object 1200 can receive messages from and / or send messages to enterprise management technology 1204. An example enterprise management technology 1204 is UnicenterTNG provided by ComputerAssociates International, Inc. Similarly, business process policy object 1200 receives rules from technologies such as rule-based intelligent technology 1206 and predictive technology 1208 and / or sends messages to such technologies, thereby enabling rule-based intelligent technology 1206 and predictive technology. Can interact with technology 1208. Thus, the business process policy object 1200 facilitates interaction between technologies and also assists in various visualizations associated with such technologies.

  As an example, the prediction technique 1208 may create an event that is forwarded to the business process policy object 1200. This event may be related to a determination that a disk crash is imminent. Thus, the business process policy object 1200 can create data for application level visualization 1212 (eg, computer network management) and role based visualization 1214 (eg, system administrator). Business process policy objects can also generate events that inform enterprise management technology 1204 that crash predictions have been visually delivered to application-level visualization 1212 and role-based visualization 1214. It is to reduce.

  The example event described above was a predictive event (e.g., impending disk crash), but the business process policy object 1200 includes other types of events, including reference events, change events, threshold events, task end events, etc. It should be recognized that events can also be handled. A reference event, which can be a non-continuous event, can provide information such as the date that a company submitted a financial disclosure or a notification that a company has submitted a financial disclosure. A change event may be an event associated with previous knowledge that has not yet been associated with another event. For example, a change event may provide information about when a product price page changes or when a company's stock price changes. Threshold events help to associate current knowledge with previous knowledge at a simple level. For example, a threshold event may provide information regarding when a company's stock price has risen or dropped by more than 10% over the previous stock price. Task end events are related to business process knowledge and can therefore provide information about when a running task is complete (e.g., a business process policy object will indicate that the download of financial public data has been completed). Tell). In addition, business process policy object 1200 has created a new event, but the business logic selectively executed by business process policy object 1200 is responsible for generating business events, generating corporate events, generating notifications, and generating log entries. It should be recognized that can be included.

  Turning now to FIG. 13, an example method 1300 for automatically applying business process policy logic implemented within a business process policy object is illustrated. At 1310, a business process policy object is identified. For example, an application, object, process, and / or thread that requires communication with a business process policy object will obtain a unique identifier for the business process policy object that the message is sent to. Additionally and / or alternatively, the type of business process policy object that a thread, process, application, object, etc. may seek to interact with may be specified. As an example, an object that processes a failure event (eg, a failed download) may be identified. The sender may request that an event be sent to one or more instances of the class of object that is tasked with processing the business logic associated with the event, rather than sending it to a particular object.

  At 1320, the message is sent to the 1310 business process policy object. This message may relate to items such as threshold events, reference events, change events, task end events, and task failure events. In response to the 1320 message, the business process policy object that received the message can generate an event that is forwarded to other business process policy objects and / or returned to the source that created the message. The recipient can create, for example, events, messages, and / or corporate events. As such, method 1300 may receive events and / or messages at 1330.

  At 1340, a determination is made as to whether method 1300 sends another message. If the determination at 1340 is yes, the process returns to 1320, otherwise the process can end. The determination at 1340 can be determined, at least in part, by whether the message and / or event received at 1330 indicates that an additional message should be sent. For example, a business process policy object sent a message at 1320 may require that a secondary two-way communication be established in order to be able to obtain additional information related to the processing of the message. As such, the method 1300 can be cycled through the blocks 1320, 1330, 1340 one or more times.

  It should be appreciated that no message may be received at 1330. Thus, as a means of waiting for messages and / or events for a predetermined, configurable time before the method 1300 determines whether to send another message to the business process policy object identified in 1310, a timeout Logic can be incorporated into the method 1300. Although identification of one business process policy object is shown at 1310, the method 1300 can send messages to one or more business process policy objects serially and / or substantially in parallel. Should be recognized more.

  The systems, methods, and objects described herein can be stored, for example, on a computer readable medium. Media includes application specific integrated circuits (ASIC), compact discs (CD), digital versatile discs (DVD), random access memory (RAM), read only memory (ROM), programmable read only scale (PROM), It can include, but is not limited to, disks, propagating waves, memory sticks and the like. Thus, an example computer-readable medium can store computer-executable instructions for automatically executing business process policy logic within an object. The directive initializes the object (e.g., initializes data, initializes a method, exposes an interface), allows a message to be received on the initialized object, and allows one or more methods to Business process policy logic can be selectively executed by calls. Similarly, an example computer-readable medium can store computer-executable instructions for automatically accessing logic maintained in a business process policy object. This directive identifies the business process policy object that the message is sent to, sends a message to that business process policy object, and receives messages from that business process policy object and / or from other business process policy objects can do.

  The above description includes a few examples. Of course, it is impossible to describe every conceivable combination of components or techniques for the purpose of describing the systems, methods, and computer-readable media associated with business process policy objects. However, those skilled in the art will appreciate that further combinations and substitutions are possible. Accordingly, this application is intended to embrace such substitutions, modifications, and variations that fall within the scope of the appended claims. Further, to the extent that the term “comprising” is used in the detailed description of the invention and in the claims, this includes the term “comprising” employed as a transitional word in the claims. In other words, it is intended to include a similar interpretation.

FIG. 6 illustrates an example computing environment in which an example business policy object can reside. Illustrates an example business process policy object that is bridging various heterogeneous computing environments. FIG. 6 illustrates an example business process policy object that is employed to help visualize a situation in an environment that includes event management and business management. FIG. 2 illustrates an example collection of business process policy objects that support event processing distributed across an enterprise across a global computer network. Figure 2 illustrates an example business process policy object that interacts with disparate applications through non-uniform joins and a common environment. Illustrates example data and control flow through a system that employs business process policy objects in conjunction with an event processor to selectively execute business logic in an enterprise that includes computer components that generate business events. . FIG. 4 is a flowchart of an example method for implementing business process policy logic in an object. 2 is a flowchart of a portion of an example method for modeling business process policy logic. An example of an object is shown. 2 shows an example of a business process policy object. FIG. 6 illustrates an example set of business process policy objects that interact with various applications and perform various functions. FIG. 6 illustrates an example business process policy object that receives messages and / or events from various environments and helps visualize various data. 2 is a flowchart of an example method for automatically applying business process policy logic implemented in a business process policy object.

Claims (30)

A method for implementing business process policy logic in an object,
Providing one or more data elements associated with modeling the business process policy logic;
Providing one or more methods related to the modeling of the business logic;
Providing an interface to the business logic that assists in accessing the data elements and / or methods through an object-oriented messaging function;
Instantiating an instance of an object that holds the data element, holds the method, and implements the interface;
Receiving a message in the instance through the interface;
Selectively executing the business logic of the instance based at least in part on the received message;
Wherein the business logic is executed by at least one of one or more invocations of the method and access to one or more of the data elements,
A method characterized by that. The business logic is at least partially modeled by at least one of one or more IF / THEN rules, rules encoding one or more tables, and one or more neurocomputers. The
The method of claim 1. The business logic relates to at least one of enterprise monitoring, enterprise management, enterprise resource planning, supply chain management, electronic commerce, KPI processing, manufacturing, finance, and human resources;
The method of claim 1. The business logic relates to at least one of business line visualization, application level visualization, and role-based visualization;
The method of claim 1. The one or more data elements are an object class identifier, an object identifier, a message identifier, a message summary, a message format, a text description of an event, a current value at a discrete business data point, a range at a discrete business data point Holds information related to at least one of the values required in discrete business data points, entity identifiers, and URLs;
The method of claim 1. The one or more methods perform at least one of management by exception, event correlation, prediction, notification generation, and rule-based management;
The method of claim 1. The message is received from at least one of an information management technology source, an enterprise management source, a rules-based intelligent technology source, and a predictive technology source;
The method of claim 1. The message relates to at least one of a threshold event, a reference event, a change event, a task end event, and a task failure event;
The method of claim 1. Selectively executing the business logic includes generating at least one of a business event, a notification, and a log entry;
The method of claim 1. Establishing a secondary two-way communication with an information source to obtain additional information associated with the message;
The method of claim 1. Updating one or more of the data elements;
The method of claim 1. The one or more methods evaluate one or more IF / THEN rules, evaluate one or more rules that encode the table result, and interpret the output from one or more neurocomputers; Perform at least one of the
The method of claim 1. The instance of the object generates data suitable for display on a GUI that allows at least one of visualization of enterprise management and workflow management.
The method of claim 1. The interface obtains an XML format message, obtains the class of the received object, obtains a unique identifier for the received object, retrieves the text description of the received event, retrieves the attribute name from which the event was created At least one of a search for an attribute value in which the event was created, a search for a unique identifier for the event supplier, a search for a unique identifier for the entity associated with the event, and a search for the URL of the entity associated with the event. Reveal one or more methods to perform,
The method of claim 1. A computer implemented method for automatically applying business process policy logic implemented within a business process policy object, comprising:
Identifying the business process policy object to which the message is sent;
Sending a primary message to the business practice policy object;
A method comprising the steps of: Receiving at least one of a response message and a corporate event from the business process policy object to which the message was sent;
The method of claim 15. The first message relates to at least one of a threshold event, a reference event, a change event, a task end event, and a task failure event;
The method of claim 15. Selectively sending a second message to the business process policy object based at least in part on a response message and / or a corporate event received from the business process policy object to which the first message was sent;
The method of claim 16. A system for automatically executing business process policies,
Business process policy objects that model and implement business logic related to business practices; and
A business management device for performing business management by selective interaction with the business process policy object;
A system comprising: The business process policy object is
One or more data elements that hold values related to the modeling of business practices;
One or more methods that implement decisions related to modeling business practices;
An interface that reveals one or more of the methods;
20. The system of claim 19, comprising: An event management device for providing a message to the business process policy object;
21. The system of claim 20, comprising: The message relates to at least one of a threshold event, a reference event, a change event, a task end event, and a task failure event;
The system according to claim 21. The business process policy object communicates with one or more computer components that perform at least one of information management, enterprise management, rules-based knowledge management, and predictive management;
The system of claim 19. The business process policy object executes at least one of an instruction and control service, an event management service, a workflow management service, and a visualization management service;
The system of claim 19. The business process policy object is in sequence with one or more computer components through at least one of ODBC / XML communication, Java / EJB binding, C / C ++ binding, COM, and C # /. NET protocols through a common environment. Communicate with the
The system of claim 19. Initializing one or more data elements;
Initializing one or more methods;
Exposing an interface to the object;
And initializing an object that models the business logic associated with the business policy,
Receiving a message in the initialized object;
Selectively executing a business process policy by invoking one or more of the methods;
A computer-readable medium containing computer-executable instructions that operate to cause a computer-implemented method to automatically execute business process policy logic within an object. Identifying the business process policy object to which the message is sent;
Sending a message to the object;
Receiving a response message from the object;
A computer-readable storage that stores computer-executable instructions that act to cause a computer-implemented method to automatically access business process policy logic implemented within a business process policy object Medium. Business process policy objects that model business logic related to business practices;
A business management device for executing business by communicating with the business process policy;
A computer-readable medium containing a computer-executable component of a system for automatically executing business process policies. One or more fields that hold one or more values that model business practices;
One or more methods that implement the logic associated with the business practice;
An interface that exposes one or more of the methods to help receive a message;
A computer-readable memory for storing computer-executable objects. A system for handling business process policies as objects,
A means to model business practices;
A means of holding data values related to the modeled business;
Means to execute logic related to business logic;
Means for receiving a message that selectively invokes the implementation of the business logic;
A system comprising:

Images