Systems and method for message-based control and monitoring of a business process

Abstract

A system for monitoring and controlling a business process involving a plurality of workstations or/and computerized services, the system comprising apparatus for receiving messages exchanged between the plurality of workstations or computerized services and having content, and for deriving from the content of the messages, monitoring information regarding the single business process.

Claims

1. A system comprising at least one processor; and at least one memory storing instructions which when executed by the at least one processor causes the at least one processor to: receive, from a first server, a first message of a first message type, wherein the first message type includes a first subset of meta-tag fields of a meta-tag spec, and the first message includes values arranged in the first subset of meta-tag fields; correlate the first message and a first instance of an enterprise process based on one or more rules and the values in the first subset of meta-tag fields, wherein the one or more rules correlate by analyzing the first message against characteristics of an incoming message, an entity receiving the incoming message, and an outgoing message associated with the first instance of the enterprise process; in response to a match from the correlation between the first message and the first instance of the enterprise process: merge the values arranged in the first subset of meta-tag fields to the first instance of the enterprise process; and link the first message to the first instance of the enterprise process by adding new information to an information associated with the enterprise process, wherein the new information includes: an identified receiving entity, and an outgoing message generated by the identified receiving entity; receive, from a second server, a second message of a second message type different than the first message type, wherein the second message includes a second subset of meta-tag fields of the meta-tag spec, and the second message includes values arranged in the second subset of meta-tag fields; correlate the second message and a second instance of the enterprise process based on the one or more rules and the values in the second subset of meta-tag fields, wherein the one or more rules correlate by analyzing the second message against the information associated with the enterprise process; and in response to a match from the correlation between the second message and the second instance of the enterprise process, merge the values arranged in the second subset of meta-tag fields to the second instance of the enterprise process and link the second message to the second instance of the enterprise process.

2. The system of claim 1, wherein the instructions further cause the at least one processor to: correlate the first message with a first instance identifier of the enterprise process based on one or more rules, wherein the one or more rules correlate by identifying the first message as matching a previously received incoming message.

3. The system of claim 1, wherein the outgoing message associated with the first instance of the enterprise process and the second message of the second message type are the same.

4. The system of claim 1, wherein the instructions further cause the at least one processor to: receive, from a third server, a third message of a third message type different than the first message type or the second message type, wherein the third message type includes a third subset of meta-tag fields of the meta-tag spec, and the third message includes values arranged in the third subset of meta-tag fields; and correlate, via the one or more rules, the third message with the first instance of the enterprise process or the second instance of the enterprise process, based on the values arranged in the third subset of meta-tag fields in the third message.

5. The system of claim 4, wherein the instructions cause the at least one processor to correlate the third message with the first instance of the enterprise processes, based on: identifying one or more characteristics of the third message as shared with a corresponding one or more characteristics of the first message.

6. The system of claim 5, wherein the shared characteristics of the third message and the first message are characteristics of an incoming message type associated with the first instance of the enterprise process.

7. The system of claim 5, wherein the shared characteristics of the third message and the first message are characteristics of an outgoing message type associated with the first instance of the enterprise process.

8. The system of claim 5, wherein the instructions further cause the at least one processor to: merge the values arranged in the third subset of meta-tag fields to the first instance of the enterprise process, wherein the merging is based on the shared characteristics of the third message and the first message.

9. The system of claim 1, wherein in response to no match from the correlation between the first message and the first instance of the enterprise process, the instructions further cause the at least one processor to: generate a new instance of the enterprise process, wherein the new instance is different from the first instance or the second instance of the enterprise process, and merge the values arranged in the first subset of meta-tag fields to the new instance of the enterprise process.

10. A method comprising: receiving, from a first server, a first message of a first message type, wherein the first message type includes a first subset of meta-tag fields of a meta-tag spec, and the first message includes values arranged in the first subset of meta-tag fields; correlating the first message and a first instance of an enterprise process based on one or more rules and the values in the first subset of meta-tag fields, wherein the one or more rules correlate by analyzing the first message against characteristics of an incoming message, an entity receiving the incoming message, and an outgoing message associated with the first instance of the enterprise process; in response to a match from the correlating between the first message and the first instance of the enterprise process: merging the values arranged in the first subset of meta-tag fields to the first instance of the enterprise process; and linking the first message to the first instance of the enterprise process by adding new information to an information associated with the enterprise process, wherein the new information includes: an identified receiving entity, and an outgoing message generated by the identified receiving entity; receiving, from a second server, a second message of a second message type different than the first message type, wherein the second message includes a second subset of meta-tag fields of the meta-tag spec, and the second message includes values arranged in the second subset of meta-tag fields; correlating the second message and a second instance of the enterprise process based on the one or more rules and the values in the second subset of meta-tag fields, wherein the one or more rules correlate by analyzing the second message against the information associated with the enterprise process; and in response to a match from the correlation between the second message and the second instance of the enterprise process, merging the values arranged in the second subset of meta-tag fields to the second instance of the enterprise process and link the second message to the second instance of the enterprise process.

11. The method of claim 10, further comprising: correlating the first message with a first instance identifier of the enterprise process based on one or more rules, wherein the one or more rules correlate by identifying the first message as matching a previously received incoming message.

12. The method of claim 10, wherein the outgoing message associated with the first instance of the enterprise process and the second message of the second message type are the same.

13. The method of claim 10, further comprising: receiving, from a third server, a third message of a third message type different than the first message type or the second message type, wherein the third message type includes a third subset of meta-tag fields of the meta-tag spec, and the third message includes values arranged in the third subset of meta-tag fields; and correlating, via the one or more rules, the third message with the first instance of the enterprise process or the second instance of the enterprise process, based on the values arranged in the third subset of meta-tag fields in the third message.

14. The method of claim 13, further comprising correlating the third message with the first instance of the enterprise processes based on identifying one or more characteristics of the third message as shared with a corresponding one or more characteristics of the first message.

15. The method of claim 14, wherein the shared characteristics of the third message and the first message are characteristics of an incoming message type associated with the first instance of the enterprise process.

16. The method of claim 14, wherein the shared characteristics of the third message and the first message are characteristics of an outgoing message type associated with the first instance of the enterprise process.

17. The method of claim 14, further comprising merging the values arranged in the third subset of meta-tag fields to the first instance of the enterprise process, wherein the merging is based on the shared characteristics of the third message and the first message.

18. The method of claim 10, further comprising, in response to no match from the correlation between the first message and the first instance of the enterprise process; generating a new instance of the enterprise process, wherein the new instance is different from the first instance or the second instance of the enterprise process, and merging the values arranged in the first subset of meta-tag fields to the new instance of the enterprise process.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Certain embodiments of the present invention are illustrated in the following drawings:

(2) FIG. 1A is a simplified diagram of prior art workflow-centric monitored business processes;

(3) FIG. 1B is a simplified diagram of data-centric monitored business processes including a plurality of triads representing business routes, each triad typically comprising an incoming message, an entity which receives it, and an outgoing message generated by the entity responsive to receipt of at least the incoming message;

(4) FIG. 2 is a diagram of a message including information which may be stored as a node e.g. in any of the nodes in the computerized representation of a buying process to be monitored shown in FIG. 5;

(5) FIGS. 3A-3B are simplified illustrations of triads and connections therebetween, in accordance with certain embodiments of the present invention;

(6) FIG. 4 is a simplified functional block diagram illustration of a data-centric system for monitoring business processes, constructed and operative in accordance with a first embodiment of the present invention;

(7) FIG. 5 is a simplified diagram of an example of a computerized representation, generated by any of the systems shown and described herein, of a buying process to be monitored by any of the systems shown and described herein, the representation typically being generated by interconnecting triads, all in accordance with certain embodiments of the present invention;

(8) FIG. 6 is a simplified functional block diagram illustration of a data-centric system for monitoring business processes, constructed and operative in accordance with a second embodiment of the present invention;

(9) FIG. 7 is a simplified flowchart illustration of a method of operation for any of the systems of FIG. 6 constructed and operative in accordance with certain embodiments of the present invention;

(10) FIG. 8 is a method of operation of the Triad designer of FIG. 6, also termed herein “method 6” constructed and operative in accordance with certain embodiments of the present invention;

(11) FIG. 9A is a simplified functional block diagram of an database adaptor constructed and operative in accordance with certain embodiments of the present invention;

(12) FIG. 9B is a simplified flowchart illustration of a preferred method of operation of the adaptor of FIG. 9A, in accordance with certain embodiments of the present invention;

(13) FIG. 10 is a diagram of a plurality of interconnected nodes representing a business process, for an AccPac application all in accordance with certain embodiments of the present invention;

(14) FIG. 11 is a simplified diagram of a prior art publish/subscribe mechanism;

(15) FIG. 12 is a simplified flowchart illustration of a process instance correlation method, also termed herein “method 1 “, which is useful in implementing the message-to-process correlation step 840 of FIG. 7 and which is particularly useful for structured data arriving at the message queue, which is constructed and operative in accordance with certain embodiments of the present invention;

(16) FIGS. 13A-13B are diagrams illustrating operation of a transaction identification steps in a correlation method such as the correlation methods of FIG. 12 and FIG. 14, in which, respectively, a match is and is not found, all in accordance with certain embodiments of the present invention;

(17) FIG. 14 is a simplified flowchart illustration of a process instance correlation method, also termed herein “method 2”, useful for structured data, but also useful for non- or semi-structured data (such as but not limited to Gmail or Outlook email messages, and messages having EMC Documentum format) arriving at the message queue, the method being useful in implementing the control step 850 of FIG. 7, the method being constructed and operative in accordance with certain embodiments of the present invention;

(18) FIG. 15 is a simplified flowchart illustration of a method, also termed herein “method 3” for inserting a new junction into a network of nodes, in which the “fix message content” and “build new triad” steps may be performed by a human user of the system, the method being useful in implementing the method of FIG. 14 and being constructed and operative in accordance with certain embodiments of the present invention;

(19) FIG. 16 is a simplified flowchart illustration of a method, also termed herein “method 5”, for merging a message-instance into a process-instance, useful in implementing the methods of FIGS. 12 and 14, which is constructed and operative in accordance with certain embodiments of the present invention;

(20) FIGS. 17A-17B are diagrams illustrating a state before operation of steps “Assign process instance to message” in a correlation method such as the correlation methods of FIGS. 12 and 14, in which a new message is merged into an existing transaction, all in accordance with certain embodiments of the present invention;

(21) FIG. 18 is a diagram illustrating operation of a steps “Assign process instance to message” in a correlation method such as the correlation methods of FIGS. 12 and 14, in which a new message is merged into an existing transaction, all in accordance with certain embodiments of the present invention;

(22) FIG. 19 is a simplified flowchart illustration of a method, also termed herein “method 4”, for process correctness validation, which is constructed and operative in accordance with certain embodiments of the present invention;

(23) FIG. 20 is a simplified flowchart illustration of a rule execution method applied to a current message for detection of error in keying in data, the method being constructed and operative in accordance with certain embodiments of the present invention;

(24) FIG. 21 is a table of relationships between specific alerts and ARM (Alert Resolution Manager) actions, and between specific rules, all in accordance with certain embodiments of the present invention;

(25) FIG. 22 is a simplified diagram of an example of a suitable data structure for the Audit database 103 of FIG. 6;

(26) FIGS. 23A-23D, taken together, form a table illustration of properties of each of the business process nodes of FIG. 5; this information may be stored in the process definition database of FIG. 6, in accordance with certain embodiments of the present invention;

(27) FIG. 24A is a simplified diagram of an example of a suitable data structure for the process definition database 635 of FIG. 6;

(28) FIG. 24B is a simplified diagram of an example of a suitable data structure for the message queue database 620 of FIG. 6; and

(29) FIG. 24C is a simplified diagram of an example of a suitable data structure for the process instance database 614 of FIG. 6.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

(30) As an alternative to a conventional work-centric process monitoring system e.g. as shown in FIG. 1A, that can offer a solution to the abovementioned drawbacks, a data-centric process monitoring system, in accordance with an embodiment of the present invention, is shown in FIG. 1B. The “data” in the data-centric process model may include a document in a predefined state, a scanned document, a middleware message, an SMS message, DB record, textual file, e-mail, fax, HTTP page and so on. An entity in the data-centric process model may include a business application, IT (Information Technology) service, department, employee's role and so on, that transforms the incoming message into an outgoing message.

(31) The techniques used may be entirely different from those used in a work-centric business process design and analysis. Triads may be connected to each other in the network through their Incoming and Outgoing message content in XML form or alike. The linkage between messages typically ensures feasible conditions for processing instance identification using part of a message content called a meta-tag. Before launching the method for a meta-tag definition for each type of overall monitoring processes (customer-centric, supplier-centric or alike) a Meta-tag Spec is typically defined which may comprise a file or database table that may comprise all possible data field names enabling an identity for a specific object like customer or supplier at different steps of process execution. Examples of data fields which may be included in a Meta-tag Spec for a buying overall business process (supplier-centric system) are: Supplier name, Supplier URL, PO date, PO number, Invoice number, Invoice date, Product name, and Shipping order number.

(32) An embodiment of the present invention employs a simple non-directed or directed graph, built by using the triads described above. Nodes of the graph are message-classes produced during as-is overall business process execution. The content of every message (structured or unstructured) may be marked as illustrated in FIG. 2 in which: a, b, c, f, . . . s, r—data fields; B—message meta-tag; D—all relevant data fields; M—data fields existing in Meta-tag Spec (in addition to B). Every triad has a certain meta-tag B, which is applied to each of its messages: both boundary (incoming/outgoing) and those that divide the triad into two or more triads relating to the same entity. The method works to automatically define the meta-tag for each message and connects the triads in the content-based process network (graph). To define B, an XML scheme of the two triad's messages may be obtained and data fields that are available both in each of the messages and in the Meta-tag Spec are found. The data fields (names) found synonymously may form the meta-tag B for each message related to the given triad.

(33) The triads may be extracted from operational message brokers or content-based network routers, as described below. A message brokering mechanism typically requires the following model definition: <input message (content)—subscriber/publisher—output message (content)>. In addition, the input/output message transformation model may be defined. The information about these models remains in a special configuration file and may be extracted from the file automatically. As the name of the configuration file is known to the user, he merely scans the enterprise domains and to identify various operational middleware product configuration files. After data has been extracted from the configuration files, it may be transformed to triads as follows:

(34) <input message—app/ . . . —?????>

(35) <????—app/ . . . —output message>

(36) The result after extraction of a fragment as described herein may be completed by an IT (Information Technology) expert (preferably not by a business analyst), or by receiving new information extracted from other operational message brokers. This method may add the output message to the first triad and the input message to the second triad.

(37) The following example demonstrates how the triad generation method described above may operate in an example enterprise: Assume that an enterprise has a ‘Handle Payment’ computerized application that is responsible for handling and preparing payments to subcontractors and suppliers. It also has an operational middleware infrastructure that connects that application to a web-based application using two message brokers (routers). The ‘Handle Payment’ application receives an ‘Invoice’ incoming message from a router, and, after finishing its role, it forwards an ‘Approved Payment Voucher’ (outgoing message) by another router towards the next application (Web Service2). For simplification, assume that all messages are XML data. After extracting data from the operational routers, the following triads are obtained:

(38) <Invoice—‘Handle Payment’—Approved Payment Voucher>

(39) <????—‘Web ServiceV’—Invoice>

(40) <Approved Payment Voucher—‘Web Service2’—?????>

(41) Additional scanning of enterprise domains by an IT (Information Technology) expert may complete the above triads by introducing the following messages: Purchase Order and Payment.

(42) As a result, the following triads are obtained:

(43) Triad 1: <Invoice—‘Handle Payment’—Approved Payment Voucher>

(44) Triad 2: <Purchase Order—‘Web Service1’—Invoice>

(45) Triad 3: <Approved Payment Voucher—‘Web Service2’—Payment>

(46) Meta-tags may be defined for the above 3 triads respectively, comprising the following data fields respectively:

(47) 1.sup.st triad: supplier name, ordered items, total sum, invoice date or number

(48) 2.sup.nd triad: supplier name, PO date or PO number

(49) 3.sup.rd triad: supplier name, total sum.

(50) Two triads (FIG. 3A) j (formed by D.sub.j.sup.in, D.sub.j.sup.out pair) and i (formed by D.sub.i.sup.in, D.sub.i.sup.out pair) are typically connected if the meta-tag in an incoming message of route i (D.sub.i.sup.in) partially comprises or entirely comprises content B and M of outgoing message of route j (D.sub.j.sup.out) as shown in FIG. 3A.

(51) If the name of an outgoing message of route j is the same as an incoming message name of route i, the above connection is typically represented as in FIG. 3B. Typically, the message broker or/and router configuration files are not the only way to extract triads. For this purpose any XML message definitions stored in an operational system could be used. For example, if an operational system is built in Service Oriented Architecture, triads might be extracted from BPEL (Business Process Execution Language), WSDL (Web service Description Language) and the like.

(52) Thus, a set of triads may be generated which is connected to a content-based process flow network as described above. Following this, a new message (additional model node) is received. To insert this message into the triad structure generated, the following method A may be used which may include the steps shown below, suitably ordered e.g. as shown below:

(53) Method A

(54) Step1. Find a triad, whose meta-tag is involved in the content of new message.

(55) Step2. Check whether the new message has data fields that are not available in an incoming message but are available in an outgoing message of the found triad. If true, then assign this message to the triad as a mid message (node). If false, go back to step1. After finding all the triads as above, go to Step3.

(56) Step3. Look for an entity that produces this message and build the new triad or fix this message content and go to Step1.

(57) The two first steps of the described method may be automatically performed and may be used for extending the predefined process network “on-the-fly”. This is particularly relevant for an unstructured (collaborative or human-driven) process. For instance, a portion of an insurance claim handling process may be represented by the following triad:

(58) <list of received claimant's documents, claim department, letter reporting pay/don't pay decision>

(59) For example, an insurance clerk reviews the received claimant's documents in the document management system and decides (before making a decision to pay or not to pay) to request an additional document of the claimant. The probability of such a request may be 1:1000 but it may occur and therefore this fact has to be reflected as evidence for an individual claimant audit trial.

(60) Thus, a new message “Additional request” that does not exist in the predefined process model, is received. The request is sent to the claimant by email that is archived in the Content Management System. This example is discussed further below, in a description of the process monitoring method.

(61) A method for overall business process monitoring according to an embodiment of the invention is described below. A system that may apply this method is shown in FIG. 4. The system may comprise a Triad designer, Runtime analytical engine, a Monitor that presents different reports, a Separate XML Message queue repository and a resulting Database that stores all executed messages for each individual process in accordance with an embodiment of the present invention. The system typically overlays the above operational content-based operational networking (routers, message brokers and ESB (Enterprise Service Bus)) and ECM platform.

(62) As part of the messages defined using a designer, as described above, further messages may be received from structured data sources such as an ESB (Enterprise Service Bus)/message broker via publisher/subscriber mechanism. The rest of the messages defined in the system which are related to unstructured data sources such as email, fax, or a scanned document, and stored into an ECM platform may be received by a query that may comprise a meta-tag data field value created during system functioning. All relevant messages ESB (Enterprise Service Bus), for example and ECM products are delivered to the removed message queue repository to which the Runtime analytical engine (Engine) is connected.

(63) An engine that applies a method provided in accordance with an embodiment of the present invention may receive a message from the Message Queue Repository and may examine it to identify a node to which the message relates. It finds among the received messages in the Database the message related to an adjacent node with the same meta-tag data value, attaches the Process ID (PID) already available in this message to the current message, and puts it into the Database.

(64) There are two or more variations of the method as described in detail herein, each variation including the steps described below, suitably ordered e.g. as follows:

(65) Method B

(66) Step1. Get a current message from the Queue and identify a node. Go to Step2

(67) Step2. Look for the same meta-tag data value in the previous nodes available in the DATABASE.

(68) If the node and message are found, perform step 2.1.

(69) If the node is found but the message is not found, perform step 2.2.

(70) If the node is not found (e.g. the node of current message is the first in the node structure generated by the system), perform step 2.3.

(71) 2.1 Attach the Process ID existing in the found message within Database to the current one. In other words, link the current message to the found in DATABASE process-instance record. Go to Step3

(72) 2.2 Send alert “Bypass the process or error” and wait for a response from the person responsible. If “Bypass the process” is approved, then make up the new process-instance record in the DATABASE—new Process ID may be established—with the current message as the first node the process-instance is started from. Otherwise, keep the Alert remained valid. Go to Step3

(73) 2.3 If the same Purchase Order number (PO number) value (both refer to supplier-centric embodiments) is found in the DATABASE, then alarm “Error in PO number”. Otherwise make up the new process-instance record in the DATABASE (generate new Process ID and glue it to the current message). Go to Step3

(74) Step3 Get next message from the Queue and go to Step1.

(75) Method C

(76) Step1 The same as in the Method A. Go to Step2

(77) Step2 The same as in the Method A. Go to Step3

(78) Step3 Generate a meta-tag based Query to search all messages in the Queue related to the next adjacent nodes.

(79) Two possible results are as follows: At least one message is found, in which case step 3.1 is performed, or No message is found, in which case step 3.2 is performed.

(80) 3.1 Perform Step1 and Step2 for each of the found messages. At the end of each cycle extend (or change) Query for Step3. Do Step3 with new Query. At the end, go to Step1.

(81) 3.2 Go to Step1.

(82) Method C is active and Query driven, whereas Method A is passive in that it serves messages from the queue one by one.

(83) A method for inserting a new node “on-the-fly” as was described above in the example of insurance claim, extends Step2 in both methods by the new situation: The node is not found while a process-instance is identified through the content of the current message e.g. at least one message, whose meta-tag comprised the data value of the current message, is found in the Database. The method may find all triads involving each found message and may then perform Steps 1 and 2 of Method A described above, for each triad.

(84) In some cases the Message queue in FIG. 4 may be replaced by the message repository (registry) that an ESB (Enterprise Service Bus) or/and ECM product builds while transporting messages or by performing a document storage process.

(85) A process control method may be based on the above-described process monitoring method but may be extended by introducing business rules to detect an exception such as but not limited to an error in data typed into a business application, or fraud. A list of application-specific rules may be pre-defined in a design stage. Each rule may be applied for certain data involved in message content. A rule sets up the relevant message content, e.g. the list of relevant data fields in addition to those that are used in meta-tags for process-instance identification. An example of a generic rule that uses an ability to monitor overall business process-instance is as follows: “Sensitive data such as supplier name, payable sum, supplier address, ordered goods and amount, should have the same value in any message produced during process fulfillment”. Another rule example is as follows: “For each PO there should be only one Invoice for the same total sum”.

(86) Evidently, the body of a rule comprises data fields and message (node) names. Therefore, each rule may be applied to the message, so that a list of predefined rules may be attached to each node. The same rule, however, may be attached to more than one node. These rules may be applied in Step2 of the described process monitoring methods while the current message-instance is put into the Database by comparing the relevant data fields with those that are already available in the Database for the same process-instance (the same Process Instance ID).

(87) The ability to control and monitor the individual process through disconnected IT (Information Technology) systems and human-driven activities, as described above, may be used as the underlying platform for creation different solutions (applications) in different fields of business (known also as Content Enabled Vertical Applications—CEVA), such as an overall selling process, an overall buying process and an overall insurance claim handling process. Because every solution may be dissimilar in the data-centric processing model that it uses, described below is a solution based on a data-centric process model for an overall buying process.

(88) A computerized representation of a buying process in accordance with an embodiment of the present invention, useful in monitoring the buying process, is shown in FIG. 5. The representation of FIG. 5 enables a user to control and monitor processes related to a specific supplier (supplier-centric monitoring) through Purchase Order (PO) initiation (Requisition), approval, payment, registration of the ordered goods into relevant enterprise systems and a return process if ordered goods do not fully satisfy a customer. Generation of the computerized representation of FIG. 5 is useful in identifying the following insiders' risks: errors in data typing (check, voucher, depreciation, etc.); double payment; bypassing the process; altered payee; purchasing for personal gain; return purchased item and keep the cash as described in detail below.

(89) 1) Errors in data typing: the system controls that a certain data field, available in more than one message, has the same value. For example, the total sum that is recorded into the Depreciation system (New Fix asset record message), in the Payment system (Payment Voucher, Approved Payment Voucher and Signed Check messages) and in the sent check (Check sent message), is the same.

(90) 2) Double payment: the system controls that since an invoice has already been received and correlated to an initial PO, the current message that it gets is one more invoice (two or more Invoice Receipts or/and Invoice Record messages are correlated by the system into one Sent PO message).

(91) 3) Bypass the process: the system controls that an invoice from a supplier (Invoice Receipt message) cannot be issued before the approved PO has been sent (Sent PO message).

(92) 4) Altered payee: this refers to errors in data typing by controlling a name of a supplier.

(93) 5) Purchasing for personal gain: this refers to errors in data typing by controlling the amount of the ordered items (the system controls every message that includes this data field until the message “Return Report” is received).

(94) 6) Return purchased item and keep the cash: the system controls this by receiving a message “Return Report” before messages “New Fixed Asset record”, “New General Lager record” and “Account Payable record” is updated in accordance with “Return Report” and new message “Account Receivable record” is produced in financial applications.

(95) Referring again to the system of FIG. 4, the system may comprise the 3 functional boxes and 2 data storage units shown:

(96) Connectivity with operational IT (Information Technology) infrastructure: Content-based networks (router, message broker, service bus) e.g. SolaOs, and Enterprise Content Management (ECM) platforms should be provided. Triad Designer—applies an absolutely different process modeling method that results in Process Definition XML file in accordance with new data-centric process model structure. In addition, this box allows a user to map model data junctions' and data fields' logical names into native data fields' names of operational systems.

(97) Analytical Engine—monitors and controls a single overall business process based on message-to-process correlation method and alerting.

(98) Monitor—visualizes results of control and monitoring providing organizations with reports and dashboards.

(99) Message Instance Queue—incoming to Analytical Engine.

(100) Process-Instance Database—outgoing from Analytical Engine.

(101) A possible data flow between the system components of FIG. 4 is as follows:

(102) 1—XML “Process Definition” file from Triad Designer to Analytical Engine and all available native names of junctions and fields are fed into an Adaptor from Analytical Engine to triad Designer.

(103) 2—Mapping results made in triad Designer from Analytical Engine to connectivity and all available operational IT (Information Technology) systems, native names of junctions and fields from connectivity to Analytical Engine.

(104) 3—Message-instance arrives at the Message Queue from Content management platform and Content routing (brokering) network.

(105) 4—Message-instance arrives at Analytical Engine from Message Queue.

(106) 5—Message-instance correlated with a single business process by Analytical Engine is inserted into its Process instance database. An example of the message is shown in the FIG. 5.

(107) 6—Data to be used for reporting by Monitor arrives from Process instance database created by Analytical Engine.

(108) FIG. 6 is a simplified functional block diagram illustration of a data-centric system for monitoring business processes, constructed and operative in accordance with a second embodiment of the present invention.

(109) The system of FIG. 6 typically includes one, some or all of the following blocks: Monitor—typically allows for examination of any audit trail data. Example: Corporate manager view, Line manager view and Auditor view. The access to the data is typically ‘read only’ but data is available in real time and support of historical queries is provided.

(110) Audit Database—typically contains audit-trail data regarding all of messages, alerts and alert resolutions that have been processed by the Engines and ARM (Alert Resolution Manager).

(111) ARM—Alert Resolution Manager—typically operative to receive all of messages and alerts from the engines. If a message contains an alert, the ARM (Alert Resolution Manager) typically notifies a human operator and/or tries to resolve the alert. An ARM (Alert Resolution Manager) typically retains a full trail and all documentation relevant to resolution. Such information may be relayed to the Audit Database for further analysis by the Monitor.

(112) ARM (Alert Resolution Manager) Manager—responsible for registration of new ARM (Alert Resolution Manager) and relaying of the messages to the appropriate ARM (Alert Resolution Manager) that registered with each process ID (the process type monitored by the monitoring system).

(113) Process Definition Database 635—This database may store all of the process information: junctions (message-classes), fields, routes, rules, alert types, scopes, ID fields, field weights.

(114) Process Rule Engine—responsible for running all of the rules defined in a process to validate process correctness during execution. If a rule applies, an alert may be generated and stored in the Process Instance Database.

(115) Process Instance Database 614—This database may store all messages, process instances and process instance IDs.

(116) Correlation Engine—responsible for correlation of a new message to the process instance. If the message cannot be connected to the process instance, a new process instance may be created.

(117) Process Loader—This component may process incoming configuration files and convert them for storage in the Process Definition Database; then it may create/update process definition.

(118) Process Config File—typically an XML Document with predefined (built-in) full process definition.

(119) Triad Designer 600—software which typically allows creation of a triad structure from scratch, or updating existing information in the process configuration files' predefined triad structure in accordance with conditions of particular customer. Typically, the Triad designer generates, in memory, a message-based representation of the business process (network) to be monitored as a plurality of interconnected business routes.

(120) Adaptor Manager—may communicate with all adaptors during runtime to make sure they are up and connected. It may also provide information to the node Designer regarding configuration and data from one or many adaptors. The Adaptor Manager may reference the Process Definition Database for any process or junction related information.

(121) Message Depositor—may get all messages from adaptors, in native format (message names and field names may be native), convert native names of specific organizations into logical names familiar to the system of FIG. 6, and deposit the message into the Message Queue Database, marked with a particular process ID (process type)

(122) Message Queue Database—may store all of the message queues that are to be processed by the Correlation engine. These messages typically do not have a process instance tag attached to them at this point.

(123) Adaptor—facilitates communication between plurality of adaptors, the Adaptor Manager and the Message Depositor.

(124) Non-Structured Data Adaptor—adapts to Non-Structured data sources using ECM platforms, such as EMC Documentum or email services such as Gmail and Outlook

(125) Database Adaptor—means an adaptor to any database, and typically uses a previously created trigger in a given database that may signal the presence of new data. Once the trigger has given this signal, the adaptor may retrieve it to build and send a message in standard format, such as XML. The Database Adaptor is also typically able of discovering of all possible data sets available in a given data source, this information representing the native message and field information used by the Designer for purposes of mapping.

(126) SOA Adaptor—This component represents an adaptor to any service bus or Message broker and assumes that access is provided via WSDL, and uses subscriptions to filter which messages to collect and send to the Message Queue Database. The SOA Adaptor is also typically operative to list all available messages with native message and field information.

(127) A possible data flow between the system components of FIG. 6 is as follows:

(128) A1—Adaptor may register with the Adaptor Manager providing appropriate credentials and optional encryption parameters.

(129) Adaptor may provide, if asked by the Adaptor Manager, a list of all native messages and fields that are available.

(130) Adaptor may send configuration of the native filter/subscriber.

(131) Adaptor Manager may send the request for all native messages and fields.

(132) Adaptor Manager may send configuration for the Adaptor's filter to specify only a subset of the native messages and fields that are relevant.

(133) A2—Adaptor may deposit messages in the Message Depositor via SOAP (XML). The format of the message may be given by CFMessage schema. Each message may contain the process ID, message name (junction name) and set of all fields relevant for message correlation (process instance the message belongs to identification) and process correctness validation.

(134) A4—The Message Depositor may put all the messages that come from the Adaptor into the Message Queue Database by converting every message field given in a native name to its logical name.

(135) C1—After all of the Rules have been applied and all of the Alerts have been found, a copy of the message and any alert associated with this message may be sent to the ARM Manager.

(136) C2—After Process Instance Correlator has completed correlation, a message is sent to the Process Rule Engine, so that Rules can be applied.

(137) C3—When a Process Rule Engine works on a message, it uses other messages from the same process instance for comparison and rule-based validation. Any found alerts may be stored in the Process Instance Database.

(138) C4—When the Process Instance Correlator works on a message, it may use the Process Instance Database for correlation to the process instance. Any correlated messages are stored in a Process Instance Database.

(139) C5—When the Process Instance Correlator works on a message, it uses the Process Definition Database to look up junction, field and weight information about a message.

(140) C6—When the Process Rule Engine works on a message, it uses the Process Definition Database to look up rules defined for the particular process.

(141) C7—The Adaptor Manager may receive a process definition to configure the adaptors.

(142) D1—Process Config File is typically an XML configuration document that has a full Process definition. It may be loaded into a Process Loader to add new process definition, or may be used for back-up purposes.

(143) D2—The triad Designer may create a new process definition, an XML configuration document, into Process Loader.

(144) D3—The triad Designer may query the Adaptor Manager to provide information on one or many available adaptors for a particular process ID. The Adaptor Manager may send requested information to the triad Designer, including all native message and field names.

(145) D4—The triad Designer gets the Process configuration document for updating and data mapping.

(146) E1—Process Instance Database may provide the ARM Manager with all data that is to be sent to the ARM typically including: process instances, messages and alerts.

(147) E2—ARM may register with ARM Manager and provide authentication information, process ID it is interested in listening to, and a location where the messages may be sent to.

(148) ARM Manager may relay all of the appropriate messages after the Core engines have processed them. Multiple ARMs could register to listen on a single process ID.

(149) E3—Message Queue Database may provide all of the queue messages for all of the processes to the Process Instance correlation and validation.

(150) E4—Message Depositor may place a newly received message into appropriate message queue by process ID in the Message Queue Database.

(151) E5—TRIAD Designer 600 may interact with the Process Definition Database to create, edit, remove or update process definitions of any process.

(152) E6—Process Loader may process XML configuration file and convert it to the database format. Then it may store/update it in the Process Definition Database.

(153) E7—Adaptor Manager may prepare DQL or a similar query for the Non-Structured Adaptor, as well as providing the Process Instance ID and the Junction name.

(154) E8—ARM Manager gets Process Definition from the Process Definition Database at the end of the ARM Registration.

(155) M1—Monitor may retrieve the audit data from the Audit Database.

(156) R1—ARM may deposit process definition after successful registration into Audit Database

(157) ARM may deposit incoming messages, alerts and all associated information to the Audit Database

(158) ARM may update and read Audit Database during processing of alert resolutions

(159) Business applications may include J2EE, .NET, ERP (like AccPac and SAP), and CRM type applications, inter alia.

(160) In the embodiment described herein, the duplicate information stored in Audit trail and Process-instance databases is typically implemented so as to take into account the Engine's performance and security issues.

(161) In contrast to work-centric methods, a message or content based BPM (business process management) does not necessitate a connection to business applications or IT (Information Technology) services, as well as process understanding. Only messaging systems that carry messages or content are typically employed. Today three different types of such systems are known: content-routed networks; message brokering systems (message broker and service bus); and content management platforms. The present invention, however, illustrates a custom adaptor to capture the relevant message from operational business application such as AccPac. Thus, some or all of the following types of adaptors may be embedded in the monitoring system:

(162) 1) Adaptor to message broker such as WLI* from BEA* or WebSphere* from IBM*

(163) 2) Adaptor to Enterprise Service Bus (ESB*) such as Aqualogic* from BEA or WebSphere* from IBM or Sonic* from Progress

(164) 3) Adaptor to content router such as SolaOs* from Solace* Systems

(165) 4) Adaptor to a ECM* platform such as EMC Corporation's Documentum system or IBM Corporation's FileNet system

(166) 5) Custom developed adaptor to ERP system for small or medium sized organizations, such as AccPac* from Sage Group.

(167) In a set-up stage in which, typically, a human user of such a system interviews a human IT employee of the organization, whose business processes are to be monitored, typically includes performing various monitoring checks requested by the organization, which involve comparing certain data fields or computational transformations thereof, to certain other data fields or computational transformations thereof. The interview allows the software engineer to learn, and to input to the system of the present invention: (a) entities which are involved in receiving messages and/or generating messages relevant to the business process/es to be monitored, (b) software used by each such entity, to generate each type of outgoing message it generates; (c) software is used by each such entity to read each incoming message it receives (i.e. to determine the format of each type of incoming message); and (d) the organization's internal names for each of the various data fields used in the definitions of the monitoring checks requested by the organization. Process Definition Database 635 typically stores:

(168) a. the entities

(169) b. each entity's incoming and outgoing messages=junction In and junction OUT,

(170) c. the data fields and where they are located in the incoming or outgoing messages, and

(171) d. the formulae for monitoring checks e.g. as shown in the Rule table described herein.

(172) Process ID indicates the type of process that is being controlled and monitored, such as: Buying process (supplier-centric), insurance claim overall process (customer-centric), Selling process (customer-centric). Each Process ID typically comprises a number of transactions (instances). Process IDs are typically stored in Process Definition DB 635 of FIG. 6.

(173) An embodiment of the Message Broker/Service Bus Adaptor 721 of FIG. 6 is now described. This adaptor connection to data source is based on SOA architecture (example ESB—Enterprise Service Bus). An adaptor using these technologies is able to obtain and filter messages from the data source and then forward them the Message Queue Database in the engine. It may use the filter capabilities of ESB (Enterprise Service Bus) itself.

(174) ESB (Enterprise Service Bus) provides simple API for connecting and reaching the messages that run through the different applications and publisher/subscriber message brokering mechanism. An example of communication is based on the IBM Message Broker. “WebSphere Message Broker provides an advanced enterprise service bus, delivering universal connectivity and data transformation.”

(175) An adaptor uses the Message Broker publish/subscribe mechanism which facilitates receipt of messages that run through the brokers. Generally, as described in “WebSphere Message Broker Publish/Subscribe”, Version 6, Release 0, posted by IBM, and as shown in prior art FIG. 11 which appears in the above post: “Publish/subscribe is a style of messaging application in which the providers of information (publishers) are decoupled from the consumer of that information (subscribers) using a broker”. In a publish/subscribe system, a publisher does not need to know who uses the information (publication) that it provides, and a subscriber does not need to know who provides the information that it receives as the result of a subscription.”

(176) The following is a description of how an adaptor may get a message named “SENTPO” that is published by an organization application called “ACCPAC”.

(177) In order to have the adaptor subscribed (in the relation to the same example: AccPac as publisher and process definition as presented in the FIG. 23A-D) a developer may do the following:

(178) 1. Make connectivity to Message broker:

(179) a. Broker domain configured

(180) b. Publication—“ACCPAC” application has to publish its SENTPO message.

(181) c. Topic(Optional)—ACCPAC has to publish its messages with known topics (as “ACCPAC_PO “for example)

(182) d. Filter (optional)—“SENTPO” has field name title with value “SENTPO” (for filtering, there can be other fields as well)

(183) e. Adaptor queue—Adaptor Manager needs to have a queue where the messages may be sent to <QName>.

(184) f. Security—Adaptor Manager has to authorize Adaptor to access the broker.

(185) FIG. 11 is a simplified diagram of a prior art publish/subscribe mechanism.

(186) 2. Send Subscription request:

(187) Sends a subscription register message for adaptor. Considering that the adaptor knows the topic that ACCPAC is using and/or knows to filter, it is preferred to use these parameters in order to avoid retrieval of undesired messages. Subscription request will be provided by the following command:

(188) <psc><Command>RegSub</Command><Topic>ACCPAC_PO

(189) </Topic><RegOpt>PubOnReqOnly</RegOpt><Filter>Body.Title like ‘SentPO’</Filter><QName>AdaptorQue</QName></psc>

(190) 3. Forward Message to Engine:

(191) Once Adaptor Manager gets the message in its queue, it can translate it to the CFMessage schema and forward it to the Message Queue Database as described herein with reference to the Database Adaptor 711.

(192) An embodiment of the Non-Structured Data Adaptor 701 of FIG. 6 is now described. Such An Adaptor takes its data from unstructured data sources as emails, faxes, and from their servers using ECM (Enterprise Content Management) tools. ECM products know how to capture, manage and store unstructured content.

(193) Adaptor by Connecting to ECM products (such as but not limited to EMC—Documentum, Open Text, and IBM—FileNet) may retrieve messages, translate them to the CFMessage format and then forward them to the Adaptor Manager.

(194) To develop an adaptor that obtains a message from the process where a desired document is captured and managed by the EMC family of products, for example, basic knowledge about EMC technology is employed. Two EMC products include Documentum and Captiva.

Example

(195) Referring to the same example of overall buying process described above with reference to FIG. 5 and FIG. 23A-D, and assuming that message-class “Receiving Report” is received by an accounting department as an attachment to an email in pdf format. EMC Captiva captures this pdf document that describes ordered items, total sum and supplier's properties.

(196) Fetch Content from Repository:

(197) 1. Connect to Documentum repository using the Documentum API (DFC,ECI) and standard JDBC libs. Visual connection can be done also through the Repository Integration Utility.

(198) 2. Run DQL(Documentum Query Language) query to find the document that are needed. In this example, for a ‘Receiving Report’ document is sought, in a ‘email’ folder of Documentum Repository, supplier name ‘ABC”, item name ‘television’ by running the query:

(199) SELECT*FROM dm_document SEARCH DOCUMENT Contains ‘ABC <AND>television’ WHERE FOLDER (ID(‘0b9af3ce800001ff’)) AND (object_name like ‘% Receiving Report %’)

(200) ‘Folder ID’ is a DUMMY ID, just for the sake of example.

(201) FIG. 7 is a simplified flowchart illustration of a method of operation for any of the systems of FIG. 6 constructed and operative in accordance with certain embodiments of the present invention.

(202) Step 810 may be integrated with dataflow junctures D2, D3, D4 and E6 or E5 or D4, D1 and E6 of FIG. 6. Step 820 may be integrated with dataflow junctures A2, E4 and A7, A1, C7 of FIG. 6. Step 830 may be integrated with dataflow junctures A4, E4 of FIG. 6. Step 840 may be integrated with dataflow junctures E3, C5, C4 and C2 of FIG. 6 and may be performed by the analytical engine 210 of FIG. 4. Step 850 may be integrated with dataflow junctures C3, C6 and C1 of FIG. 6 and may be performed by the analytical engine 210 of FIG. 4. Step 860 may be integrated with dataflow junctures E2, E1, E8, and R1 of FIG. 6. Step 870 may be integrated with dataflow junctures M1 of FIG. 6.

(203) Various steps in FIG. 7 may be performed in parallel such as steps 830,840 and 850 and/or steps 840-860, and/or steps 840-860, and/or steps 860 and 870. Still with reference to FIG. 7, an embodiment of step 810 is described below with reference to FIG. 8. One embodiment of step 820 is described below with reference to FIGS. 9A-9B. Embodiments of step 840 are described below with reference to FIGS. 12, 14, 15 and 16; and also FIGS. 13A-B, 17A-B and 18. An embodiment of step 850 is described below with reference to FIGS. 19-20.

(204) A method for performing step 820 of FIG. 7 (Connectivity to organization's information sources to get message and transfer it to the message queue) may be provided also with custom developed database adaptor. It is a mediator between an organization's data source and Engine that performs steps 840 and 850 of FIG. 7.

(205) An adaptor sends to the correlation engine the messages content according to the messages requests which were predefined in the Process Definition XML file.

(206) All the messages are typically sent in the XML format e.g. as defined below in order that the engine may recognize them (CFMessage schema).

(207) TABLE-US-00001 <?xml version=“1.0” encoding=“UTF-8”?> <schema xmlns=“http://www.w3.org/2001/XMLSchema” targetNamespace=“http://www.example.org/NewXMLSchema” elementFormDefault=“qualified” xmlns:Q1=“xs” xmlns:cf=“http://www.example.org/NewXMLSchema”> <element name=“Message”> <complexType> <sequence> <element name=“Properties” minOccurs=“1” maxOccurs=“1”> <complexType> <sequence> <element name=“Author” type=“string” minOccurs=“1” maxOccurs=“1” /> <element name=“Time” type=“time” minOccurs=“1” maxOccurs=“1”></element> <element name=“Name” type=“string” minOccurs=“1” maxOccurs=“1”></element> <element name=“Process” type=“string” minOccurs=“1” maxOccurs=“1”></element> <element name=“UserData” type=“string” minOccurs=“1” maxOccurs=“1”></element> </sequence> </complexType> </element> <element name=“Fields” minOccurs=“1” maxOccurs=“1” > <complexType> <sequence> <group ref=“cf:CFFieldsGroup” maxOccurs=“unbounded”></group> </sequence> </complexType> </element> </sequence> </complexType> </element>  <group name=“CFFieldsGroup”> <choice> <element name=“Number” type=“cf:CFNumber” nillable=“true”></element> <element name=“String” type=“cf:CFString”></element> <element name=“Date” type=“cf:CFDate”></element> <element name=“Time” type=“cf:CFTime”></element> <element name=“Double” type=“cf:CFDouble”></element> <element name=“Boolean” type=“cf:CFBoolean”></element> <element name=“Table” type=“cf:CFTable”></element> <element name=“Vector” type=“cf:CFVector”></element> <element name=“Amount” type=“cf:CFAmount”></element> </choice> </group> <attributeGroup name=“CFieldAtrributes”> <attribute name=“name” type=“string”></attribute> </attributeGroup>  <complexType name=“CFNumber” > <simpleContent > <extension base=“integer” > <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> <complexType name=“CFString”> <simpleContent> <extension base=“string”> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> <complexType name=“CFDouble”> <simpleContent> <extension base=“double”> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> <complexType name=“CFBoolean”> <simpleContent> <extension base=“boolean”> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> <complexType name=“CFDate”> <simpleContent> <extension base=“date”> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> <complexType name=“CFTime”> <simpleContent> <extension base=“time”> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> <complexType name=“CFField”><attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup></complexType> <complexType name=“TableHeader”> <sequence> <element name=“Col” type=“cf:CFColumn” maxOccurs=“unbounded” minOccurs=“1”></element> </sequence> </complexType> <complexType name=“TableRows”> <sequence> <element name=“Row” type=“cf:CFVector” maxOccurs=“unbounded” minOccurs=“0”></element> </sequence> </complexType> <complexType name=“CFTable”> <sequence> <element name=“Columns” type=“cf:TableHeader” maxOccurs=“1” minOccurs=“1”> </element> <element name=“Rows” type=“cf:TableRows” maxOccurs=“1” minOccurs=“1”> </element> </sequence> <attribute name=“rowsNumber” type=“int”></attribute> <attribute name=“colsNumber” type=“int”></attribute> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </complexType> <complexType name=“CFColumn”> <simpleContent> <extension base=“string”> <attribute name=“type” type=“string”></attribute> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> <complexType name=“CFVector”> <sequence> <group ref=“cf:CFFieidsGroup” maxOccurs=“unbounded”></group> </sequence> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </complexType> <complexType name=“CFAmount”> <sequence> element name=“Count” type=“double” maxOccurs=“1” minOccurs=“1”> </element> <element name=“Type”> <complexType> <simpleContent> <extension base=“string”> <attributeGroup ref=“cf:CFieldAtrributes”></attributeGroup> </extension> </simpleContent> </complexType> </element> </sequence> </complexType> </schema>

(208) Each message adaptor: Reads/gets message content from the organization information source Translates this message content into xml format Deposits message in the Engine by calling the engine web service (see below). Receives confirmation message from Engine.

(209) Both Engine and Adaptor publish web services for communication between them.

(210) Engine web service allows: Deposit message and Register adaptor Adaptor web service allows bringing of Database Tables with native field names for mapping. The adaptor, when it initializes, registers itself at the Engine, and then initiates a two-sided start to communicate.

(211) FIG. 9A is a simplified functional block diagram of a database adaptor, e.g. for SQL databases, constructed and operative in accordance with certain embodiments of the present invention. FIG. 9B is a simplified flowchart illustration of a preferred method of operation of the adaptor of FIG. 9A, in accordance with certain embodiments of the present invention.

(212) A preferred method of operation for the apparatus of FIG. 9A is shown in FIG. 9B. As shown, the method may include the following steps suitably ordered e.g. as shown:

(213) Step 1191. Trigger gets key data of updated SQL database (DB) tables and puts them in CF DB. Key data is a value of the new or updated record ID in the given DB table.

(214) Step 1192. Listener listens and fetches constantly the key data and forwards it to the Message Factory

(215) Step 1193. Message Factory creates new Message Instance according to the key data

(216) Step 1194. Message Object through connector asks SQL DB re the updated data

(217) Step 1195. Message Object gets the data from DB

(218) Step 1196. Message Object translates data to XML format (according to CFMessage schema) and sends it to Message Queue Database through Depositor which is a web service client of Message Queue database.

(219) An example of database adaptor creation for AccPac is described below.

(220) Sage Accpac is an award-winning accounting system that integrates with a complete set of end-to-end business solutions, including CRM, HRMS, warehouse management and more.

(221) ACCPAC database is a type of SQL server DB.

(222) The “Process Definition” file which describes the messages and their fields is typically employed.

(223) Steps for adaptor creation include development of the J2EE server, and the Accpac database server (SQL side).

(224) SQL Side:

(225) The CF DB and Trigger and the ACCPAC are typically installed on the same SQL server. Create new CF DB in the SQL server, which may include only one table “CFMessages”. This table retains information on all the updates that have been done in the ACCPAC database. Each update may issue a new row in this table, containing information which refers to a change in the original tables.

(226) A CFMessages table contains the following columns:

(227) 1. messageName—Logical name given for this message. Using this name, an adaptor may know how to find the original table in the ACCPAC DB.

(228) 2. messageKey—A key value of the original table message. An adaptor has to know the key field name and by using this value, so that it can track the updated row in the table.

(229) 3. messageTime—time of message, created automatically.

(230) 4. messageFlag—status of the message(0—at this stage it has not been read yet by the adaptor, 1—read successfully, 2—read with exceptions), come default with value 0.

(231) 5. messageId—internal auto increase number for message-instance.

(232) Trigger: For each table that the system of the present invention is to track, a trigger is typically constructed. Trigger may insert into the CFMessages table a new row each time one of the viewed tables is updated. For example trigger sql for inserting new row in requisition may be:

(233) TABLE-US-00002 CREATE TRIGGER [dbo].[newRequisition] ON [dbo].[PORQNHi] AFTER INSERT AS BEGIN SET NOCOUNT ON; DECLARE @requisitionSeq varchar(8000); SET @requisitionSeq = (SELECT RQNHSEQ from inserted); INSERT [CF].[dbo].cfMessages(messageName,messageKey) VALUES(‘REQUISITION’,@requisitionSeq); END

(234) J2EE Server side—develop the following functional components as J2EE web application server.

(235) a. Message Object—Each junction (message-class) that was defined in the “Process Definition” XML file typically has an equivalent component that reads its content from the DB tables.

(236) For example: The junction “Requisition” in FIG. 5 and FIG. 10 as well, may have equivalent “Requisition” message class that may know to query the ACCPAC DB on all appropriate fields.

(237) Query can be done through sql syntax as:

(238) jdbc.executeQuery(“select AUDTUSER,RQNHSEQ,RQNNUMBER,VDCODE,VDNAME,REQUESTBY,DATE,LINES from PORQNHI1 where RQNHSEQ=”+key);

(239) where “key” is the key value of the updated row.

(240) Messageclasses may have a function that transform their content to predefined XML format (CFMessage). For example Result of the transformation may be as follows:

(241) TABLE-US-00003 <?xml version=“1.0” encoding=“UTF-8”?> <cf:Message xmlns:cf=“http://www.example.org/NewXMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://www.example.org/NewXMLSchema NewXMLSchema.xsd ”> <cf:Properties> <cf:Author>Ronen Bigon</cf:Author> <cf:Time>23:59:59</cf:Time> <cf:Name>PORQNH1</cf:Name> <cf:Process>ACCPAC_PO</cf:Process> <cf:UserData></cf:UserData> </cf:Properties> <cf:Fields> <cf:String name=“VDCODE”>24444</cf:String> <cf:String name=“AUDTUSER”>Ronen</cf:String> <cf:Double name=“DOCTOTAL”>599.99</cf:Double> <cf:Date name=“DATE”>2007/04/12</cf:Date> <cf:Table name=“LINES” > <cf:Rows> <cf:Row> <cf:Column name=‘ITEMNO’>IPOd Nano</cf:Column> <cf:Column name=‘RQRECEIVED’>2</cf:Column> <cf:Column name=‘UNITCOST’>2245</cf:Column> </cf:Row> <cf:Row> <cf:Column name=‘ITEMNO’>AppleTV</cf:Column> <cf:Column name=‘RQRECEIVED’>11</cf:Column> <cf:Column name=‘UNITCOST’>31456.34</cf:Column> </cf:Row> </cf:Rows> </cf:Table> </cf:Fields> </cf:Message>

(242) b. Messages factory—Creates a Message Instance according to a table and the logical name. The list of logical names and their matching tables may be known to the developer from the “process definition” file.

(243) c. Listener—Tracks the CF DB constantly and returns a message to all messages rows that their status is 0 i.e. has not been read). For each message, a listener fetches the message logical name and the key value. Using these values, it can call the message factory to create a message instance.

(244) d. Connector—JDBC connection to the Database

(245) e. Depositor—Every message instance creates xml. This xml is forwarded to the Engine (Message Queue database) through WSDL that the Engine provides.

(246) Once the Engine receives the message it return confirmation response with value 1(ok) or 2 (in case of error in message content). The listener returns the server confirmation value.

(247) FIG. 10 is a diagram of a plurality of interconnected nodes representing a business process, for an AccPac application, all in accordance with certain embodiments of the present invention.

(248) FIG. 12 is a simplified flowchart illustration of a process instance correlation method, also termed herein “method 1”, which is useful in implementing the message-to-process correlation step 840 of FIG. 7 and which is particularly useful for structured data arriving at the message queue, which is constructed and operative in accordance with certain embodiments of the present invention.

(249) FIGS. 13A-13B are diagrams illustrating operation of a transaction identification steps in a correlation method such as the correlation methods of FIGS. 12 and 14, in which, respectively, a match is and is not found, all in accordance with certain embodiments of the present invention. The small shapes in FIGS. 13A-13B, 17A—17B and 18 denote various meta-tag data fields (such as those in the table of FIGS. 23A-23D). Since meta-tag generation for each junction in the process definition network is completed, the meta-tag data fields included in each Process Id are known. As a message arrives, its meta-tag data field's value is written to a transaction. Therefore, it is not necessary to search and analyze the field value of prior incoming messages that belong to the same transaction. In FIG. 13A, meta-tag data fields: VI, V and III, whose values match the same data fields' value of the newly incoming message, are already written to transaction 1800. The newly incoming message relates to the junction that comprises the meta-tag data field weights. The current message is assigned (correlated) to transaction 1800 because the sum of the fields VI, V, III which match the already signed (merged) previously incoming messages I, II, III whose field values have been collected to the transaction, is more than 1 (or 100%).

(250) In FIG. 13B, a message cannot be assigned to transaction 1920 because the sum of the meta-tag data fields weights that match those that have been written to the transaction, is less than 1 (or 100%).

(251) FIG. 14 is a simplified flowchart illustration of a process instance correlation method, also termed herein “method 2”, useful for structured data, but also useful for non- or semi-structured data (such as but not limited to Gmail or Outlook email messages, and messages having EMC format, i.e. format provided with EMC Documentum product family) arriving at the message queue, the method being useful in implementing the step 840 of FIG. 7, the method being constructed and operative in accordance with certain embodiments of the present invention FIG. 15 is a simplified flowchart illustration of a method, also termed herein “method 3”, for inserting a new junction (or node) into a process network, in which the “fix message content” and “build new triad” steps may be performed by a human user of the system, the method being useful in implementing the method of FIG. 14 and being constructed and operative in accordance with certain embodiments of the present invention.

(252) FIG. 16 is a simplified flowchart illustration of a method, also termed herein “method 5”, for merging a message-instance into a process-instance, useful in implementing the methods of FIGS. 12 and 14, which is constructed and operative in accordance with certain embodiments of the present invention.

(253) FIGS. 17A-17B are diagrams illustrating a newly coming message and a transaction (process instance) to which the message is to be correlated before a correlation method such as the correlation methods of FIGS. 12 and 14 is applied, all in accordance with certain embodiments of the present invention.

(254) FIG. 18 is a diagram illustrating operation of the steps included in block 3210 in the message to process instance assignment method of FIG. 16, which is applied as a final step in a correlation method such as the methods of FIGS. 12 and 14, in which a new message is merged into an existing transaction, all in accordance with certain embodiments of the present invention. Correlation (or transaction identification) and merging a message to transaction, e.g. as shown in FIGS. 13A-13B, 17A-17B and 18, typically comprises assigning a process instance ID to a message and/or finding a process instance that a current message-instance belongs to. FIGS. 13A and 13B exemplify and clarify how a transaction that a message instance belongs to, may be found.

(255) FIGS. 17A-18 illustrate a process of merging in accordance with method 5 of FIG. 16. The transaction 1800 is that which was found to be correlated to the newly incoming message. Previously there were 3 messages already correlated by their meta-tag data fields VI, V, III and VII. The new incoming message may comprise a new data field IX whose name is to be used in the meta-tag of the upcoming messages. The value of this field may be added to the transaction (transaction 1800) for use in further correlation method processing.

(256) FIG. 19 is a simplified flowchart illustration of a method, also termed herein “method 4”, for process correctness validation, which is constructed and operative in accordance with certain embodiments of the present invention. This may be performed by block 631 of FIG. 6.

(257) FIG. 20 is a simplified flowchart example of a preferred method of applying one of the rules in block 3540 of FIG. 19, the method being constructed and operative in accordance with certain embodiments of the present invention. This rule typically allows the Process Rule Engine to detect in real time the errors in keying in data into a business application and fraud, as well.

(258) FIG. 21 is a table of relationships between specific alerts and ARM (Alert Resolution Manager) actions, and between specific rules, all in accordance with certain embodiments of the present invention. Embedded Rules may be applied with each message-instance. First, the customer may be asked to define which data fields he would like to check during the process execution. For this purpose we may provide the customer with a predefined list of such fields, for example:

(259) 1. SupplierName

(260) 2. SupplierNumber

(261) 3. Total (sum or ordered items)

(262) 4. ItemNumber

(263) 5. ItemDescription

(264) 6. ItemQuantity

(265) Examples of rules are listed below and relate to the process represented in the FIG. 10 or FIG. 5. It is appreciated that the 11 rules specifically described can be provided, or not provided, or only some may be provided; and other rules may be added.

(266) Rule1:

(267) TABLE-US-00004 IF message “Returns” is not available AND for the current message: OR SupplierName SupplierNumber OR Total OR ItemNumber OR ItemDescription OR ItemQuantity” Not equal the same data for the previous messages, THEN alert message: “Error in data <DataName>”

(268) In the diagram of FIG. 20, “A” refers to a predefined data field that is typically checked during process execution. So, CM.A means field A of the current message and M.A—the same field of any other message.

(269) Rule2

(270) TABLE-US-00005 IF we get message more than first time AND the junction is yellow OR red AND SupplierName OR SupplierNumber OR Total OR ItemNumber OR ItemDescription OR ItemQuantity” data Equal the same data for the previous messages, THEN alert message: “Correct junction color”
Rule3

(271) TABLE-US-00006 IF we get message more than first time AND the junction is yellow OR normal AND SupplierName OR SupplierName OR Total OR ItemName OR ItemDescription OR ItemQuantity” data Not equal the same data for the previous messages, THEN alert message: “Inappropriately altering information <DataName>”
Rule4

(272) TABLE-US-00007 IF the message name is Invoice , AND we get it more than one time AND color of message junction is normal, AND SupplierNumber AND Total equal the same data for the previous Invoice message THEN alert message: “Double Payment for <SupplierNumber> occurs”
Rule5

(273) TABLE-US-00008 IF the message name is Invoice OR Receipt AND message PO is not available in the transaction path, THEN alert message: “Fraud: Ghost Invoice” AND paint the message junction in Red
Rule6 (Rule 1 applied especially for several messages)

(274) TABLE-US-00009 IF the current message name is Inventory Receipt AND Total OR ItemNumber OR Item Description OR ItemQuantity not equal to the same data into PO message. THEN alert message: “Fraud or Error occurs. Check <DataName/s>”
Rule7

(275) TABLE-US-00010 IF the current message name is Returns AND message Inventory Receipt is not available THEN alert message: “Fraud or Error occurs. Check the item return process”
Rule8

(276) TABLE-US-00011 IF the current message name is Returns AND message Inventory Receipt is available AND ItemQuantity is not equal to the same field in the Inventory Receipt message THEN alert message: “Fraud or Error occurs. Check the item return process”
Rule9

(277) TABLE-US-00012 IF the current message name is “Credit note Entry” AND message “Returns” is available AND New “Inventory Receipt” message is not available THEN alert message: “Fraud or Error occurs. Check the item return process”
Rule10

(278) TABLE-US-00013 IF the current message name is New “Inventory Receipt” AND message “Returns” is available AND message “Credit note Entry” is available AND ItemNumber of Inventory Receipt equal the same field of Returns equal the same field of previously received message Inventory Receipt (old Inventory Receipt) AND ItemQuantity of new Inventory Receipt not equal ItemQuantity of old Inventory Receipt minus QuantityReturned of Returns THEN alert message: “Fraud or Error occurs. Check the item return process”
Rule11

(279) TABLE-US-00014 TF the current message is “Debit note Entry” AND message “Returns” is available THEN alert message: “Fraud or Error occurs. Check the item return process”

(280) Typical actions and alerts provided by ARM (block 601 of FIG. 6) in relation to each of the rules described herein by way of example are presented in FIG. 21.

(281) FIG. 8 is a simplified flowchart illustration of a method for generating triads, the method being constructed and operative in accordance with certain embodiments of the present invention. FIG. 8 is a simplified flowchart illustration of a method, constructed and operative in accordance with certain embodiments of the present invention, for performing the business route discovery steps 920 in the method of FIG. 8.

(282) The methods include some or all of the steps shown in FIGS. 8, suitably ordered e.g. as shown: Step 900. Define the list of entities (inside and outside of our organization) that are involved in the certain overall business process type (buying process, for example) and list of IT (Information Technology) systems that serve within the organization for that purpose.

(283) Then, (steps 920) for each discovered entity, define the Incoming documents and those deliver from Outgoing documents Link each triad to an IT (Information Technology) system that gets Incoming documents and delivers Outgoing documents (messages). A triad so constructed is also termed herein a “business route”.

(284) Step 980. Generate message meta-tag for each business route

(285) A content of each message (structured or non-structured) may be considered as shown in FIG. 2, where some of the data fields (found synonymously and marked by symbol B) form the meta-tag. Get two triad messages (in and out) as defined in the IT (Information Technology) system linked to the given triad, and find the data fields that are available both in each of the messages and in the Meta-tag Spec. The meta-tag is generated. It may be applied on each triad's messages including those that divide the triad into two or more triads. Meta-tag Spec is the file that comprises all possible data field names enabling an identity for a specific customer, supplier, or employee at different steps of process execution. Examples of such data fields included in Meta-tag Spec for buying overall business process (supplier-centric embodiment) are: Supplier name, Supplier URL, PO date, PO number, Invoice number, Invoice date, Product name, Shipping order number, etc. Some of the fields may have a high priority in the single process identification, such as PO number, Invoice number, person's passport ID, and so on.

(286) Steps 985. Generate weight for each of the meta-tag fields e.g. by applying the following rules: If a field has a high priority (a field that can uniquely identify a process instance such as PO ID or Invoice ID) its weight is by default 1. The weight of other fields in the meta-tag may be computed using the formula: 1.2: (number of fields−1).

(287) If a meta-tag lacks fields with high priority, “a man in the loop” may define how many fields among those existing in the meta-tag may identify a single process in the given point. After computation of the formula above, a human user may correct the weights if desired (step 1030).

(288) Step 1040. Connect the triads in the content-based process flow (network). To connect N triads in the process flow is the same as connect 2 triads. The connection of 2 triads is shown in FIG. 3. The message that relates for two different business routes may receive the meta-tag of the route where it is Incoming.

(289) An example of connecting triads is as follows: Consider the following triads:

(290) a. sent purchase order.fwdarw.supplier.fwdarw.invoice

(291) c. sent purchase order.fwdarw.supplier.fwdarw.shipping receipt

(292) The two can be combined to a single structure:

(293) TABLE-US-00015 sent purchase order -------> invoice | -------> shipping receipt

(294) As shown, there is now only one entity—“supplier”—which is responsible for execution of 2 business routes: sipping and invoicing.

(295) Step 1050. Apply Business Rules Editor: define the data fields for controlling during process execution and those junctions where the value of each of the fields shall have the same value.

(296) Step 1070. Mapping the messages and their fields that are defined in the triad structure by logical names into a message that is provided with adaptor from the IT (Information Technology) system like message brokering or from the database built business application like AccPac that uses it in native names, thereby to define which data the adaptor may fetch from the organization data source.

(297) At the end of the process shown in FIG. 8 the Process Definition file may be sent to adaptor.

(298) Example of this file for the buying process is as follows:

(299) TABLE-US-00016 <cf:Process ...> ... <cf:Fields> <cf:String name=“supplierNumber” nativeName=“VDCODE” /> <cf:String name=“supplierName” nativeName=“VDNAME” /> <cf:String name=“author” nativeName=“AUDTUSER”/> <cf:Double name=“total” nativeName=“DOCTOTAL”/> <cf:String name=“requisitionNumber” nativeName=“RQNNUMBER”/> <cf:Date name=“requisitionDate” nativeName=“DATE”/> <cf:String name=“responsibleName” nativeName=“REQUESTBY”/> <cf:Table name=“requisitionItems” nativeName=“LINES” alias=“items” idColumn=“ITEMNO”> <cf:Columns> <cf:String name=“itemNumber” nativeName=“ITEMNO” /> <cf:Double name=“itemQuantity” nativeName=“OQORDERED” /> <cf:String name=“itemName” nativeName=“ITEMDESC” /> </cf:Columns> </cf:Table> <cf:String name=“poNumber” nativeName=“PONUMBER”/> <cf:Date name=“poDate” nativeName=“DATE”/> <cf:Table name=“poItems” nativeName=“LINES” alias=“items” idColumn=“ITEMNO”> <cf:Columns> <cf:String name=“itemNumber” nativeName=“ITEMNO” /> <cf:String name=“itemName” nativeName=“ITEMDESC” /> <cf:Double name=“itemQuantity” nativeName=“OQORDERED” /> <cf:Double name=“itemTotal” nativeName=“EXTENDED” /> </cf:Columns> </cf:Table> </cf:Fields> <cf:Junctions> <cf:Junction name=“REQUISITION” nativeName=“PORQNH1” type=“”> <cf:Service name=“@ACCPAC_SERVICE ”/> <cf:Fields> <cf:Field name=“author” weight=“0.4”/> <cf:Field name=“supplierNumber” weight=“0.4”/> <cf:Field name=“supplierName” /> <cf:Field name=“requisitionDate” weight=“0.4”/> <cf:Field name=“responsibleName” weight=“0.4”/> <cf:Field name=“requisitionItems” /> <cf:Field name=“requisitionNumber” weight=“1”/> </cf:Fields> </cf:Junction> <cf:Junction name=“PO” nativeName=“POPORH1” type=“”> <cf:Service name=“@ACCPAC_SERVICE”/> <cf:Fields> <cf:Field name=“author” /> <cf:Field name=“poDate” weight=“0.4”/> <cf:Field name=“supplierNumber” weight=“0.4”/> <cf:Field name=“supplierName” /> <cf:Field name=“total”/> <cf:Field name=“poItems” /> <cf:Field name=“requisitionNumber” weight=“1”/> <cf:Field name=“poNumber” weight=“1”/> </cf:Fields> </cf:Junction> </cf:Junctions> ... </cf:Process>

(300) The file has lists of messages (junctions) that are to be retrieved from the data source. Junction Definition contains the list of the fields it has to read from the data source content.

(301) All fields and junctions have a logical name and a native name, where native name describes the name of the field/message in the data source.

(302) FIGS. 23A-23D, taken together, illustrate a table of properties of each of the business process nodes of FIG. 5 in logical names; this information may be stored in the process definition database 635 of FIG. 6, in accordance with certain embodiments of the present invention. According to an embodiment of the invention, there is provided a method of monitoring an overall business process through a content-routed network, message brokering tools, and a content management system comprising (a) content-based building of process model as a network of processing messages, (b) creating a meta-tag at each message-class involved in the network, (c) getting message-instances from a message repository created by each of at least one underlying message routers or brokers during message transportation, or database adaptor, (d) connecting a received message-instance to a process-instance in accordance with the message-class meta-tag and network; and (e) handling the received message-instances related to the same process-instance in accordance with the network. A table of message classes each having a meta-tag is shown, for example, in FIGS. 23A-D. The above steps a-e may be implemented in FIG. 6 particularly in the path from the adaptor to the correlation engine, and from the correlation engine to the monitor; this path typically handles message instances in accordance with a network provided with the Process Definition file.

(303) The above Meta-tag Specification is typically predefined and may be used in the “Generate message meta-tag” step 980 in FIG. 8. Meta-tag examples are presented in FIGS. 23A-23D. These data fields are typically used by Methods 1, 2 and/or 5 (FIGS. 12, 14 and 16 respectively).

(304) Process definition database 635 typically stores the meta-tag spec.

(305) The meta-tag fields typically include those selected by the organization for use by the correlation methods shown and described herein, and also may include fields which the organization wishes to control, e.g. using rules as shown and described here.

(306) Example: The supplier related content-centric overall business process model, which is shown graphically in FIG. 5, may be transformed in the form of Table as follows.

(307) Content-centric process model Related to Supplier is shown in the Table of FIG. 23A-D.

(308) Consider that there aren't content routers in an organization, just ESB (Enterprise Service Bus)/message broker of IBM, ERP system (such as AccPac) and Document management system (such as EMC Corporation's Documentum system). For this reason, the following types of adaptors are used: type 5—AccPac SQL Database adaptor, type 4—EMC Documentum adapor and type 1 or 2—WebSphere Message Broker adaptor. The use of each of these adaptors is described above.

(309) FIG. 24A is a simplified diagram of an example of a suitable data structure for the process instance database 614 of FIG. 6. The term “transaction” is generally synonymous with the term “process instance”. “Transaction Field” is generally synonymous with the term “process instance meta-tag”. “Message property” is generally synonymous with the term “message meta-tag”. “Message alert” is generally synonymous with the term “alert”. “Message field” is usually synonymous with the standalone term “field”.

(310) FIG. 24B is a simplified diagram of an example of a suitable data structure for the message queue database 620 of FIG. 6. This database comprises CFMessages only, and hence is not complex. FIG. 24C is a simplified diagram of an example of a suitable data structure for the process definition database 635 of FIG. 6. “Process” stores Process IDs, “processfield” stores process ID meta-tags, and “Junctionfield” stores process ID meta-tags with weights.

(311) The following program is useful in implementing the system of FIG. 6:

(312) CREATE DATABASE IF NOT EXISTS pw_archives;

(313) USE pw_archives;

(314) Definition of table ‘actions’—Defines the various ways ‘alert’ is handled.

(315) examples: Accept alert, Dismiss alert, forward email notification.

(316) DROP TABLE IF ‘actions’ EXISTS;

(317) CREATE TABLE ‘actions’ (

(318) ‘type’ varchar(15) NOT NULL,

(319) ‘id’ varchar(45) NOT NULL,

(320) ‘actionDescription’ text NOT NULL,

(321) PRIMARY KEY USING BTREE (‘id’)

(322) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(323) Definition of table ‘alertsdefinitions’—Defines the types of alerts which PW handles.

(324) example for alert could be: ‘Error in data’—‘Incompatibilty of data fields between documents’

(325) DROP TABLE IF ‘alertsdefinitions’EXISTS;

(326) CREATE TABLE ‘alertsdefinitions’ (

(327) ‘id’ int(10) unsigned NOT NULL,

(328) ‘title’ varchar(45) NOT NULL,

(329) ‘pdid’ int(10) unsigned NOT NULL default ‘1’ COMMENT ‘process definition id’,

(330) ‘description’ varchar(100) NOT NULL,

(331) ‘responsible’ int(10) unsigned NOT NULL,

(332) PRIMARY KEY USING BTREE (‘id’),

(333) KEY ‘FK_alertsdefinitions_1’ (‘responsible’),

(334) CONSTRAINT ‘FK_alertsdefinitions_1’ FOREIGN KEY (‘responsible’) REFERENCES ‘responsibles’ (‘responsibleId’)

(335) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(336) Definition of table ‘alertsevents’—Table contains alerts instances that occured in the system.

(337) DROP TABLE IF EXISTS ‘alertsevents’;

(338) CREATE TABLE ‘alertsevents’ (

(339) ‘alertid’ int(10) unsigned NOT NULL,

(340) ‘date’ datetime NOT NULL,

(341) ‘alertType’ int(10) unsigned NOT NULL,

(342) ‘alertProperties’ text NOT NULL,

(343) ‘status’ varchar(45) NOT NULL,

(344) ‘transactionId’ varchar(15) NOT NULL,

(345) ‘responsible’ int(10) unsigned default NULL,

(346) ‘messageId’ int(10) unsigned NOT NULL,

(347) PRIMARY KEY (‘alertId’),

(348) KEY ‘FK_alertsevents_1’ USING BTREE (‘alertType’),

(349) KEY ‘FK_alertsevents_3’ (‘transactionId’),

(350) KEY ‘FK_alertsevents_2’ (‘responsible’),

(351) CONSTRAINT ‘FK_alertsevents_1’ FOREIGN KEY (‘alertType’) REFERENCES alertsdefinitions' (‘id’),

(352) CONSTRAINT ‘FK_alertsevents_2’ FOREIGN KEY (‘responsible’) REFERENCES ‘responsibles’ (‘responsibleId’),

(353) CONSTRAINT ‘FK_alertsevents_3’ FOREIGN KEY (‘transactionId’) REFERENCES ‘transactions’ (‘id’)

(354) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(355) Definition of table ‘emailtrack’—incase of sending email using PW, table saves all information on the email content and the recipients

(356) DROP TABLE IF EXISTS ‘emailtrack’;

(357) CREATE TABLE ‘emailtrack’ (

(358) ‘alert’ int(10) unsigned NOT NULL default ‘1’,

(359) ‘emailContent’ text NOT NULL,

(360) ‘responsibleTrack’ text NOT NULL COMMENT ‘list of all incharges’,

(361) PRIMARY KEY USING BTREE (‘alert’),

(362) CONSTRAINT ‘FK_emailTrack_1’ FOREIGN KEY (‘alert’) REFERENCES ‘alertsevents’ (‘alertId’)

(363) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(364) Definition of table ‘junctions’—definition of all messages that PW may track.

(365) DROP TABLE IF EXISTS ‘junctions’;

(366) CREATE TABLE ‘junctions’ (

(367) ‘id’ int(10) unsigned NOT NULL auto_increment,

(368) ‘name’ varchar(45) NOT NULL,

(369) ‘nativeName’ varchar(45) NOT NULL,

(370) ‘processId’ varchar(45) NOT NULL,

(371) PRIMARY KEY (‘id’),

(372) KEY ‘FK_junctions_1’ (‘processId’),

(373) CONSTRAINT ‘FK,junctions_1’ FOREIGN KEY (‘processId’) REFERENCES ‘processdefinition’ (‘id’)

(374) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(375) Definition of table ‘logs’—any action that has been done on alert (which may change its status) may be recorded here

(376) DROP TABLE IF EXISTS ‘logs’;

(377) CREATE TABLE ‘logs’ (

(378) ‘logId’ int(10) unsigned NOT NULL auto_increment,

(379) ‘alertId’ int(10) unsigned default NULL,

(380) ‘action’ varchar(50) default NULL,

(381) ‘date’ datetime default NULL,

(382) ‘responsible’ int(10) unsigned default NULL,

(383) comments' text,

(384) PRIMARY KEY USING BTREE (‘logId’),

(385) KEY ‘FK_logs_1’ (‘alertId’),

(386) KEY ‘FK_logs_2’ (‘responsible’),

(387) CONSTRAINT ‘FK_logs_1’ FOREIGN KEY (‘alertId’) REFERENCES ‘alertsevents’ (‘alertId’),

(388) CONSTRAINT ‘FK_logs_2’ FOREIGN KEY (‘responsible’) REFERENCES ‘responsibles’ (‘responsibleId’)

(389) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(390) Definition of table ‘messages’—messages instances that PW has tracked.

(391) DROP TABLE IF EXISTS ‘messages’;

(392) CREATE TABLE ‘messages’ (

(393) ‘messageId’ int(10) unsigned NOT NULL auto_increment,

(394) ‘transactionId’ varchar(45) NOT NULL,

(395) ‘junctionId’ int(10) unsigned NOT NULL,

(396) ‘fields’ text NOT NULL,

(397) ‘date’ datetime NOT NULL,

(398) PRIMARY KEY USING BTREE (‘messageId’),

(399) KEY ‘FK_messages_1’ (‘transactionId’),

(400) KEY ‘FK_messages_2’ (‘junctionId’),

(401) CONSTRAINT ‘FK_messages_1’ FOREIGN KEY (‘transactionId’) REFERENCES ‘transactions’ (‘id’),

(402) CONSTRAINT ‘FK_messages_2’ FOREIGN KEY (‘junctionId’) REFERENCES ‘junctions’ (‘id’)

(403) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(404) Definition of table ‘processdefinition’—saves the processdefinition.xml

(405) DROP TABLE IF ‘processdefinition’ EXISTS;

(406) CREATE TABLE ‘processdefinition’ (

(407) ‘id’ varchar(15) NOT NULL,

(408) ‘content’ text NOT NULL,

(409) PRIMARY KEY (‘id’)

(410) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(411) Definition of table ‘responsibles’—list of people and general data that are related to the PW system.

(412) DROP TABLE IF ‘responsibles’EXISTS;

(413) CREATE TABLE ‘responsibles’ (

(414) ‘responsibleId’ int(10) unsigned NOT NULL auto_increment,

(415) ‘name’. varchar(45) NOT NULL,

(416) ‘jobtitle’ varchar(45) NOT NULL,

(417) ‘email’ varchar(45) NOT NULL,

(418) PRIMARY KEY USING BTREE (‘responsibleId’)

(419) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(420) Definition of table ‘transactions’—instances of transactions that PW has tracked.

(421) DROP TABLE IF EXISTS ‘transactions’;

(422) CREATE TABLE ‘transactions’ (

(423) ‘id’ varchar(45) NOT NULL,

(424) ‘startDate’ datetime default NULL,

(425) ‘process’ varchar(15) NOT NULL,

(426) ‘vendor’ varchar(45) default NULL,

(427) ‘requestNumber’ varchar(45) default NULL,

(428) ‘responsible’ varchar(45) NOT NULL,

(429) PRIMARY KEY (‘id’)

(430) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(431) Applications: The ability to control and monitor a single process through disconnected IT (Information Technology) systems and human-driven activities, as described above, can be used as the underlying platform for creation of different solutions (applications) in different fields of business, such as overall selling process, overall buying process and overall insurance claim handling process. These and other possible solutions are dissimilar, mainly in a message-based embodiment, e.g. content of a message and content based process representation network. Typically, no functions, methods or system are changed as a result of applying the business solution or content enabled vertical application.

(432) It should be noted that each of the message based embodiments produces a predefined list of fraud that does not depend on an industry or on a company of industry. It depends solely on the model (junctions it comprises). It is thus a process-related type of fraud, which may be detected only by applying instance level monitoring and instance level process correctness validation methods, such as embodiments of the present invention.

(433) For example, the list of fraud that is provided in accordance with an embodiment of the present invention for overall buying business process (supplier-related embodiment) remains the same in any industry. This means that the suggested system is easy to implement because it comes with built-in message-based capabilities and may be initiated, based on the data junctions that are already available in the operational IT (Information Technology) infrastructure for other purposes and therefore may be used by this system as well. Such junctions comprise “popular data” that runs between enterprise applications, between applications and decision makers, between organizations or between people.

(434) It is appreciated that software components of the present invention including programs and data may, if desired, be implemented in ROM (read only memory) form including CD-ROMs, EPROMs and EEPROMs, or may be stored in any other suitable computer-readable medium such as but not limited to disks of various kinds, cards of various kinds and RAMs. Components described herein as software may, alternatively, be implemented wholly or partly in hardware, if desired, using conventional techniques.

(435) Features of the present invention which are described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, features of the invention which are described for brevity in the context of a single embodiment may be provided separately or in any suitable subcombination.

Systems and method for message-based control and monitoring of a business process

Assignee

Inventors

Cpc classification

Classification Explorer

G06Q40/00

PHYSICS

Classification Explorer

G06Q10/06

PHYSICS

Classification Explorer

G06Q10/00

PHYSICS

Classification Explorer

G06F17/00

PHYSICS

Classification Explorer

G06Q10/063

PHYSICS

Classification Explorer

G06Q30/04

PHYSICS

International classification

Classification Explorer

G06Q10/00

PHYSICS

Classification Explorer

G06Q10/06

PHYSICS

Classification Explorer

G06Q10/063

PHYSICS

Classification Explorer

G06Q30/04

PHYSICS

Classification Explorer

G06Q40/00

PHYSICS

Abstract

Claims

Description