U.S. patent application number 12/377341 was filed with the patent office on 2010-06-24 for systems and methods for message-based control and monitoring of a business process.
This patent application is currently assigned to CONTROLS FORCE LTD.. Invention is credited to Vladimir Forfutdinov, Boris Shapira.
Application Number | 20100161362 12/377341 |
Document ID | / |
Family ID | 39082443 |
Filed Date | 2010-06-24 |
United States Patent
Application |
20100161362 |
Kind Code |
A1 |
Shapira; Boris ; et
al. |
June 24, 2010 |
SYSTEMS AND METHODS 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.
Inventors: |
Shapira; Boris; (Timrat,
IL) ; Forfutdinov; Vladimir; (LaSalle, CA) |
Correspondence
Address: |
OLIFF & BERRIDGE, PLC
P.O. BOX 320850
ALEXANDRIA
VA
22320-4850
US
|
Assignee: |
CONTROLS FORCE LTD.
Herzlia Pituach
IL
|
Family ID: |
39082443 |
Appl. No.: |
12/377341 |
Filed: |
August 13, 2007 |
PCT Filed: |
August 13, 2007 |
PCT NO: |
PCT/IL2007/001011 |
371 Date: |
February 12, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60822238 |
Aug 13, 2006 |
|
|
|
Current U.S.
Class: |
705/7.11 ;
705/34; 709/206; 726/26 |
Current CPC
Class: |
G06Q 10/00 20130101;
G06Q 10/06 20130101; G06Q 10/063 20130101; G06Q 30/04 20130101 |
Class at
Publication: |
705/7 ; 705/34;
726/26; 709/206 |
International
Class: |
G06Q 10/00 20060101
G06Q010/00; G06Q 40/00 20060101 G06Q040/00; G06Q 30/00 20060101
G06Q030/00; G06F 21/00 20060101 G06F021/00 |
Claims
1. A system for monitoring 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 said content of said messages,
monitoring information regarding the business process.
2. A system according to claim 1 wherein said apparatus for
receiving and deriving comprises apparatus for recognizing at least
one of the following types of messages: a purchase order; an
invoice; a shipping receipt.
3. A system according to claim 1 wherein at least one of said
messages comprises a message having an EMC format.
4. A system according to claim 1 wherein said monitoring
information comprises fraud control information.
5. A system according to claim 1 wherein said apparatus for
receiving and deriving comprises a queue of messages.
6. A system according to claim 1 wherein said apparatus for
receiving and deriving operates without resort to a definition of
the workflow of the business process.
7. A system according to claim 1 wherein said apparatus for
receiving and deriving comprises an apparatus for differentiating
between organization-customer portions of the business process
which generate income for the organization and
supplier-organization portions of the business process which
require expenditure from the organization.
8. A business process monitoring system for monitoring a business
process being carried out by an organization including at least one
organization entities each of which receive incoming messages and
generate outgoing messages, the system comprising: apparatus for
storing information characterizing the business process, the
information including a plurality of triads, each triad comprising
at least one characteristic of an incoming message, at least one
characteristic of an outgoing message and at least an indication of
an entity which receives the incoming message and generates,
responsively, the outgoing message; and apparatus for monitoring
the business processing by processing said plurality of triads.
9. A system according to claim 8 wherein said incoming message
includes at least one of the following: a document in a predefined
state, a scanned document, a middleware message, an SMS message, DB
record, textual file, e-mail, fax, HTTP page.
10. A system according to claim 8 wherein at least one entity
comprises at least one of the following: a computerized business
application, an IT (Information Technology) service, a department,
an employee.
11. A system according to claim 8 wherein said apparatus for
monitoring is operative to detect suspected occurrences of at least
one of the following events: errors in keying in data, double
payment, bypassing at least one process defined as mandatory by an
organization; alteration of payee; purchasing for personal gain;
return of purchased item while retaining the purchase price
thereof.
12. A system according to claim 11 wherein said data comprises at
least one of a check, a payment voucher, a purchase order, an
invoice, and a depreciation.
13. A method for monitoring a business process involving a
plurality of workstations or/and computerized services, the method
comprising: receiving messages exchanged between the plurality of
workstations or computerized services and having content, and for
deriving from said content of said messages, monitoring information
regarding the business process.
14. A method according to claim 13 wherein receiving and deriving
comprises recognizing at least one of the following types of
messages: a purchase order; an invoice; a shipping receipt.
15. A method according to claim 13 wherein at least one of said
messages comprises a message having an EMC format.
16. A method according to claim 13 wherein said monitoring
information comprises fraud control information.
17. A method according to claim 13 wherein said receiving and
deriving comprises a queue of messages.
18. A method according to claim 13 wherein said receiving and
deriving operates without resort to a definition of the workflow of
the business process.
19. A method according to claim 13 wherein said receiving and
deriving comprises differentiating between organization-customer
portions of the business process which generate income for the
organization and supplier-organization portions of the business
process which require expenditure from the organization.
20. A business process monitoring method for monitoring a business
process being carried out by an organization including at least one
organization entities each of which receive incoming messages and
generate outgoing messages, the method comprising: storing
information characterizing the business process, the information
including a plurality of triads, each triad comprising at least one
characteristic of an incoming message, at least one characteristic
of an outgoing message and at least an indication of an entity
which receives the incoming message and generates, responsively,
the outgoing message; and monitoring the business processing by
processing said plurality of triads.
21. A method according to claim 20 wherein said incoming message
includes at least one of the following: a document in a predefined
state, a scanned document, a middleware message, an SMS message, DB
record, textual file, e-mail, fax, HTTP page.
22. A method according to claim 20 wherein at least one entity
comprises at least one of the following: a computerized business
application, an IT (Information Technology) service, a department,
an employee.
23. A method according to claim 20 wherein said monitoring
comprises process correctness validation for detecting suspected
occurrences of at least one of the following events: errors in
keying in data, double payment, bypassing at least one process
defined as mandatory by an organization; alteration of payee;
purchasing for personal gain; return of purchased item while
retaining the purchase price thereof.
24. A method according to claim 23 wherein said data comprises at
least one of a check, payment voucher, a purchase order, an
invoice, and a depreciation.
25. A method according to claim 23 for detecting fraud comprising:
building a data centric process flow network; and monitoring at
least one business process having an inception point marking its
beginning and a closing point marking its end, from said inception
point to said closing point, said business process including
messages, said monitoring including analyzing at least one current
message, belonging to the business process and having content
including at least one data field, relative to at least one
previous message belonging to the business process and having
content including at least one data field common with the current
message, including comparing values of said at least one common
data field between said current and previous messages.
26. A method according to claim 25 and also comprising detecting
human error in keying in data entries, based on said data centric
process flow network and comparing step.
27. A method according to claim 25 and also comprising detecting
two or more message instances of the same message class belonging
to the same process instance, based on said data centric process
flow network and comparing step at least for one message class.
28. A method according to claim 25 wherein said at least one
business process includes a plurality of processes at least one of
which is human driven rather than being structured.
29. A method according to claim 25 wherein said monitoring includes
process-instance level control and process-instance level
monitoring.
30. A method according to claim 25 wherein said monitoring
comprises message-to-process correlation.
31. A method according to claim 25 and also comprising controlling
said business process.
32. A method according to claim 26 wherein said human error
detection includes analysis of a data-centric process flow
network.
33. A method according to claim 27 and also comprising detecting
instances of double payment.
34. A method according to claim 27 wherein said detecting is
executed in real time.
35. A method according to claim 27 wherein said detecting is
executed in near real time.
36. A method according to claim 31 wherein said controlling
comprises process correctness validation during process monitoring
based on said analyzing at least one current message.
37. A system for monitoring a business process comprising a
multiplicity of business processes, the system comprising: tracking
and control apparatus operative to track and to control each
transaction that impacts upon the multiplicity of business
processes carried out by at least one computerized system operative
to generate message instances which respectively belong to at least
one of a first plurality of message classes, the system including
at least one business application interacting with operations
performed by humans, wherein said tracking and control apparatus
receives a second plurality of message instances from said at least
one computerized system, each of said message instances comprising
message content, said tracking and control apparatus being
operative based solely on said message content, said tracking and
control apparatus including a meta-tag generator operative to
derive, from content of each individual message class from among
said first plurality of message classes, a message meta-tag
comprising at least one data field operative to identify a process
instance, the process instance comprising a single transaction
impacting upon the multiplicity of business processes.
38. A system according to claim 37 wherein each message instance
belongs to a transaction of a business process.
39. A system according to claim 37 wherein said business process
monitoring apparatus is operative without recourse to a workflow
representation of said multiplicity of business processes.
40. A system according to claim 37 wherein said first plurality of
message classes comprises a sequence of message classes ordered in
accordance with a data-centric process flow network
description.
41. A business process monitoring method for monitoring a business
process being carried out by an organization including at least one
organization entities each of which receive incoming messages and
generate outgoing messages, the method comprising: storing
information characterizing the business process, the information
including a plurality of triads, each triad comprising at least one
characteristic of an incoming message, at least one characteristic
of an outgoing message and at least an indication of an entity
which receives the incoming message and generates, responsively,
the outgoing message; and monitoring the business process by
processing said plurality of triads, wherein said monitoring
comprises process correctness validation for detecting suspected
occurrences of at least one of the following events: errors in
keying in data, double payment, bypassing at least one transaction
of a process defined as mandatory by an organization; alteration of
payee; purchasing for personal gain; return of purchased item while
retaining the purchase price thereof, the method also comprising:
building a data centric process flow network; and monitoring at
least one business process having an inception point marking its
beginning and a closing point marking its end, from said inception
point to said closing point, said business process including
messages, said monitoring including analyzing at least one current
message, belonging to the business process and having content
including at least one data field, relative to at least one
previous message belonging to the business process and having
content including at least one data field common with the current
message, including comparing values of said at least one common
data field between said current and previous messages, wherein said
at least one business process includes a plurality of processes at
least one of which is human driven rather than being structured and
wherein said monitoring includes process-instance level control and
process-instance level monitoring.
42. A business process monitoring method for monitoring a business
process being carried out by an organization including at least one
organization entities each of which receive incoming messages and
generate outgoing messages, the method comprising: storing
information characterizing the business process, the information
including a plurality of triads, each triad comprising at least one
characteristic of an incoming message, at least one characteristic
of an outgoing message and at least an indication of an entity
which receives the incoming message and generates, responsively,
the outgoing message; and monitoring the business process by
processing said plurality of triads, wherein said monitoring
comprises process correctness validation for detecting suspected
occurrences of at least one of the following events: errors in
keying in data, double payment, bypassing at least one transaction
of a process defined as mandatory by an organization; alteration of
payee; purchasing for personal gain; return of purchased item while
retaining the purchase price thereof, the method also comprising:
building a data centric process flow network; and monitoring at
least one business process having an inception point marking its
beginning and a closing point marking its end, from said inception
point to said closing point, said business process including
messages, said monitoring including analyzing at least one current
message, belonging to the business process and having content
including at least one data field, relative to at least one
previous message belonging to the business process and having
content including at least one data field common with the current
message, including comparing values of said at least one common
data field between said current and previous messages, wherein said
monitoring comprises message-to-process correlation, and wherein
the method also comprises controlling said business process
including process correctness validation during process monitoring
based on said analyzing at least one current message.
Description
REFERENCE TO CO-PENDING APPLICATIONS
[0001] Priority is claimed from U.S. provisional application
60/822,238, entitled "Overall business process control and
monitoring method and system", filed 13 Aug. 2006.
FIELD OF THE INVENTION
[0002] The present invention relates generally to systems for
control and monitoring of business processes.
BACKGROUND OF THE INVENTION
[0003] An example of a state of the art BPM system is US
20060085243, "Business process management method and system".
[0004] ADIS is an open environment for BPM which includes
programmable message oriented middleware.
[0005] Wikipedia states that "A Business Process is a collection of
interrelated tasks, which solve a particular issue. There are three
types of business processes:
1. Management processes--the processes that govern the operation of
a system. Typical management processes include "Corporate
Governance" and "Strategic Management". 2. Operational
processes--these processes create the primary value stream, and
they are part of the core business. Typical operational processes
are Purchasing, Manufacturing, Marketing, and Sales. 3. Supporting
processes--these support the core processes. Examples include
Accounting, Recruitment, IT-support.
[0006] "A business process can be decomposed into several
sub-processes, which have their own attributes, but also contribute
to achieving the goal of the super-process. The analysis of
business processes typically includes the mapping of processes and
sub-processes down to activity level.
[0007] "Activities are parts of the business process that do not
include any decision making and thus are not worth decomposing
(although decomposition would be possible), such as "Answer the
phone", "produce an invoice".
[0008] "Business Process Modeling Notation can be used for drawing
business processes in a workflow."
[0009] Again according to Wikipedia, "Business process management
(BPM) is a field of knowledge at the intersection between
management and information technology, encompassing methods,
techniques and tools to design, enact, control, and analyze
operational business processes involving humans, organizations,
applications, documents and other sources of information. .sup.[1]
The term `operational business processes` refers to repetitive
business processes performed by organizations in the context of
their day-to-day operations, as opposed to strategic
decision-making processes which are performed by the top-level
management of an organization. BPM differs from business process
reengineering, a management approach popular in the 1990s, in that
it does not aim at one-off revolutionary changes to business
processes, but at their continuous evolution. In addition, BPM
usually combines management methods with information
technology.
[0010] "BPM covers activities performed by organizations to manage
and, if necessary, to improve their business processes. While such
a goal is hardly new, software tools called business process
management systems (BPM systems) have made such activities faster
and cheaper. BPM systems monitor the execution of the business
processes that are under its management (coordination or
orchestration), so that managers can analyze and change processes
in response to KPI (Key Performance Indicators).
[0011] "The activities which constitute business process management
can be grouped into three categories: design, execution and
monitoring . . . .
[0012] "Business rules have been used by systems to provide
definitions for governing behavior, and a business rule engine can
be used to drive process execution and resolution.
[0013] "Process monitoring . . . encompasses the tracking of
individual processes so that information on their state can be
easily seen and statistics may be provided on the performance of
one or more processes. An example of such tracking is being able to
determine the state of a customer order (e.g. order arrived,
awaiting delivery, invoice paid) so that problems in its operation
can be identified and corrected. In addition, this information can
be used to work with customers and suppliers to improve their
connected processes. Examples of such statistics are the generation
of measures applied in KPI on how quickly a customer order is
processed, how many orders were processed in the last month etc.
These measures tend to fit into three categories: cycle time,
defect rate and productivity. In any case, business processes in a
BPMS are a software driven process and shall be explicitly
described prior to execution. No BPM system enables long-running
overall business process monitoring at the single process level
(instance level).
[0014] The degree of monitoring depends on what information a
business would like to evaluate and analyze, and how a business
wishes to be monitored, in real-time or on an ad-hoc basis. In the
latter, business activity monitoring (BAM) extends and expands the
monitoring tools in BPMS, but its operations are aimed to provide
KPI, rather than monitor the single process in run-time.
[0015] The disclosures of all publications and patent documents
mentioned in the specification, and of the publications and patent
documents cited therein directly or indirectly, are hereby
incorporated by reference.
SUMMARY OF THE INVENTION
[0016] An embodiment of the present invention seeks to provide a
monitoring method and system for overall as-is business process
control and tracking.
[0017] An embodiment of the invention relates to controlling and
monitoring of an individual complex enterprise process that crosses
different IT (Information Technology) systems (business
applications and services), connected and disconnected, inside and
outside of an enterprise, including collaborative activities, human
driven or unstructured processes, throughout Internet and
non-structured data sources, based on a method of process-instance
identification from extracted message-instance content. Some of
monitored processes may comprise a Business Process Management
(BPM) System. Thus our invention provides a system that is
functioning up of operational BPMS.
[0018] An embodiment of the present invention comprises a method of
monitoring an overall business process through a content-routed
network, message brokers, and a content management system
comprising content-based building of a network of processing
messages, creating a meta-tag at each message-class involved in the
network, getting message-instances from a message repository
created by each of at least one underlying message routers during
message transportation, connecting a received message-instance to a
process-instance in accordance with the message-class meta-tag and
data centric process flow network; and handling the received
message-instances related to the same process-instance in
accordance with the said network.
[0019] A vast number of publications are available which describe
BPM (business process management) methods and tools. Conventional
BPM (business process management) methods all require, as an
underlying component in the work-centric (workflow) process model,
a modeling tool and a workflow-based process execution engine for
process coordination and orchestration, and only then for process
control and monitoring.
[0020] The work-centric process model, also known as an
event-based, or business rules driven model is by definition a
logical model with regular connections between activities. It is
the only approach that is applied in any business process
automation, analysis, and management field. All BPM (business
process management) tools operate either by being connected
directly to business applications, or by being part of business
applications, and it is generally required that all business
processes involved in the overall process should be electronically
integrated.
[0021] The work-centric process model may have different forms such
as Workflow (www.wfmc.org) DSM (Design Structure Matrix), IDEF
(Ross, D. T. "Structured Analysis (SA): A Language for
Communicating Ideas," IEEE Transactions on Software Engineering,
vol. SE-3, No. 1, pp. 16-34, 1977) and OPM (Object Process Model).
However, intrinsic drawbacks of the work-centric process model
include the following: [0022] It is difficult to understand, make
changes and customize--a fact that is recognized through
implementation of any solution with an underlying work-centric
process model. [0023] The assumption that any business process can
be represented by an explicitly described network with regular
connections between activities is incorrect. Most real processes
are far more scaleable, disconnected, not well structured, and
cannot be wrapped in an aligned logical form and therefore do not
yet have a good IT (Information Technology) solution. [0024] The
work-centric process model is focused on activity and does not
provide details relating to processing data. Input/output data
serves here as reference information for an activity or events to
control, but not as data content. This does not allow existing
integration technologies to be fully leveraged, such as in
messaging, data connectivity, and data transformation. [0025]
Business process integration (BPI) becomes a real challenge, where
the entire process cannot be described explicitly and without
disconnected activities. That is why BPI is successfully
implemented only in fields such as STP and Web Portal management,
where an entire process is fully automated or well committed.
[0026] Integration of an automated (software-driven or structured)
process with a collaborative (human-driven or unstructured) process
is not possible using the workflow model, as well as process
monitoring at an instance level, while BPM (business process
management) tools monitor a process at a macro level (KPI--Key
Performance Indicators--via Dashboards).
[0027] As an alternative to a conventional work-centric process
monitoring system 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 provided. A set of
triads such as <Incoming message, Entity, Outgoing message>
typically constitute building blocks of this embodiment of the
invention. This embodiment enjoys the following advantages, in
comparison with conventional work-centric process models: focus on
data (an activity serves only as reference information for a data
transformation), flexibility with regard to changes because it does
not involve business logic, high reliability because data content
is far more reliable than activity or process logic, and no
challenge for BPI since two triads may be integrated within one
process. In contrast to work-centric methods, a message based BPM
(business process management) such as that shown and described
herein does not necessitate a connection to business applications
or IT (Information Technology) services, nor does it require
process understanding. In certain embodiments of the invention,
only messaging systems that carry messages or content are
necessary. Today, three different types of such systems are known:
content-routed networks, message brokers and content management
platforms.
[0028] Content-routed networks are described in A. Carzaniga, M. J.
Rutherford, A. L. Wolf, in "A routing scheme for content-based
networking", Department of Computer Science, University of
Colorado, June 2003. A content router may be a digital
communications networking device which forwards content based on
inspection of the content of a message or document, rather than on
an explicit destination address in the networking header of a
packet or frame. An example of a content router is the 3200
Multiservice Message Router from Solace Systems, Inc. Content
routers have connections between themselves so that they can both
communicate with each other and also exchange information needed to
control the network, as well as carry the content received from
publishers from one content router to the next, to deliver it to
the subscribers in a network interested in the content.
[0029] Message brokers may be software applications that implement
Publish and Subscribe mechanisms as an effective way of
disseminating information to multiple users. Business applications
and services connected to a particular message broker are typically
written so that a "community" of clients with a common purpose
enables them to send and receive messages among themselves. A
message broker may be an intermediary acting between publishers and
subscribers and is known as a coupling and a loose coupling. The
latter is also known by the name Enterprise Service Bus (ESB). A
message broker may save (in a separate repository and files) all
the message-class definitions and registers each transported
message-instance in detail, including its publisher and
subscriber.
[0030] Content management systems typically address to store
(archival), index, and retrieve different unstructured documents in
structural XML form for querying and searching. To put or review a
document in the archive, these systems may use workflow-based BPM
(business process management), but for query and search purposes
they may create and use repositories with document type definitions
and content attached to each received document.
[0031] An embodiment of the present invention may use the existing
messaging systems mentioned above in a form and for a purpose that
BPM (business process management) tools have hitherto not been
used, due to lack of synergy between workflow-based BPM (business
process management) and messaging systems.
[0032] The term "overall business process" is intended to include a
true business process which starts with the first event that
initiates a course of action, which is not complete until the last
aspect of the final outcome is satisfied from the point of view of
the stakeholder of the first event that triggered the course of
action. Instead of a transactional (crosses single IT (Information
Technology) system or business application) and an end-to-end
(crosses several business applications across an enterprise)
business process, the overall business process may cut across
organizational structures, geographies, and technologies. The
overall business process may comprise software and human driven
activities (unstructured business processes), usually disconnected
from each other. A method of monitoring of an individual overall
business process provided in accordance with an embodiment of the
invention may use a content-routed network, message brokers
(coupled and loose coupled), and content management platforms to
get messages and may provide a message tagging mechanism to
correlate an executed message-instance with an initial
process-instance.
[0033] Embodiments of the present invention may provide a method
for control and monitoring an individual overall business process
using the messaging systems that collect message-instances in the
format like XML by using a subscriber mechanism or query method, or
any database adaptor.
[0034] An embodiment of the invention may include a method for
message-based monitoring including message meta-tag definition; a
method for assigning message-instance to process-instance; or, in
other words, process-instance identification through
message-instance content.
[0035] An embodiment of the present invention seeks to provide an
improved system and method for monitoring business processes,
typically including monitoring of a process across multiple
message-handling systems. Methods can typically be applied to any
long running process. Optionally, the system may have a data
centric view on the process--examining only data and not the
meaning of the each activity in a process instance. Based on data
centric process representation the system may provide message to
process instance correlation based on message data only, using ID
fields and individual field weights.
[0036] An embodiment of the present invention also seeks to provide
a system for control and/or monitoring of business processes which
cross different IT systems, services and business applications,
connected or disconnected, and/or collaboration between human users
(human-driven or unstructured processes). All such processes are
included in the term "overall business process" employed
herein.
[0037] According to an embodiment of the present invention, a
plurality of business processes or data-generating systems, which
are not electronically integrated, are used for input. Minimal
integration is typically required in the data centric solution vs.
very hard and long integration in the workflow based solution.
Non-intrusive view capabilities are preferably provided. Monitoring
of the processes is typically performed only in key places. A
messaging platform (e.g. middleware) is typically used for
controlling and monitoring a business process that crosses
different information systems (connected and disconnected), human
driven activities (collaborative processes) and organizations.
[0038] The system typically can accommodate any organization of any
size and industry which produces and sells or/and purchases
products or/and services and uses for these purposes an information
system (such as ERP, CRM and SCM) or/and a middleware
infrastructure (such as WebSphere, WebLogic Integration or
Aqualogic), or/and a content management platform (such as EMC
Corporation's Documentum system), or/and a content-aware routing
system (such as SolaOs), or, at least, an email service (such as
Outlook or Gmail), e.g. any small organization or industry which
produces and sells or/and purchases products or/and services using
the small ERP system AccPac of Sage Group.
[0039] Optionally, Process model definition is implemented, the new
process model type being termed herein content or Data Centric
Process model (DPM), an embodiment of which is characterized by
being based on analysis of messages being exchanged by entities
within an organization in which a business process to be monitored
is occurring. Usually in the field of Business Process Management a
work-centric process model named Workflow, is used. A comparison of
certain aspects of embodiments of the invention and the prior art
is shown in FIGS. 1A-1B. The workflow model focuses on activities
that are business-related or technical tasks to run such
activities. In the system of the present invention, typically, the
focus is on Data that is transferred between IT (Information
Technology) systems or/and between people, or/and between the IT
(Information Technology) system and a person for decision
making.
[0040] The system of the present invention may be characterized by
some or all of the following:
1. Data centric process model--enables examining only messages
(content) that are produced during true long-running business
process execution by IT (Information Technology) systems and people
to track and monitor each single business process from its
inception to closure, such as an overall business process related
to dealing with a supplier. 2. A method for creation of a data
centric process model without the need to build and understand the
entire process workflow. 3. A message-to-process instance
correlation mechanism, which provides precise information on the
state of a single process that a message-instance belongs to
(current processing and completed business activities, stage of a
current process, etc.). 4. Message-to-process instance correlation
method enabling based on data content and data-centric process
model only, using meta-tag data fields and its weights. 5. Process
correctness validation method enabling control each individual
business process to be executed accurately using messages only
provided with adaptors to structured data sources (message
brokering tools, JMS or Database) and non-structured or
semi-structured (content management platforms, email services) data
sources. 6. Overall business process control and monitoring method
and system using only Message Brokers or ESB (Enterprise Service
Bus) and data-centric process model without process coordination
and orchestration. 7. Data centric view on the process--examining
only data and not the meaning of each activity in a process
instance. 8. Message to process instance correlation based on
message data only, using ID fields and individual field
weights.
[0041] A particular advantage of an embodiment of the present
invention is that the system may be set up easily as a function of
information easily supplied by low-level IT employees of an
organization (information about the flow of messages within the
organization's subsystems) whereas as conventional business process
monitoring systems require input from senior level employees of the
organization and understanding of business process logics.
[0042] There is thus provided, in accordance with an embodiment of
the present invention, a system for monitoring a business process
involving a plurality of workstations or/and processes, the system
comprising an apparatus for receiving messages exchanged between
the plurality of workstations or/and processes and having content,
and for deriving from the content of the messages, monitoring
information regarding the business process.
[0043] Further in accordance with an embodiment of the present
invention, the apparatus for receiving and deriving comprises
apparatus for recognizing at least one of the following types of
messages: a purchase order, an invoice, and a shipping receipt.
[0044] Still further in accordance with an embodiment of the
present invention, at least one of the messages comprises a message
having an EMC Documentum format, JMS format, SOAP format or SQL
format.
[0045] Further in accordance with an embodiment of the present
invention, the monitoring information comprises fraud control
information.
[0046] Still further in accordance with an embodiment of the
present invention, the apparatus for receiving and deriving
comprises a queue of messages in the predefined format like
XML.
[0047] Additionally in accordance with an embodiment of the present
invention, the apparatus for receiving and deriving operates
without resort to a definition of the workflow of the business
process.
[0048] Further in accordance with an embodiment of the present
invention, the apparatus for receiving and deriving comprises an
apparatus for differentiating between organization-customer
portions of the business process which generate income for the
organization and supplier-organization portions of the business
process, which require expenditure from the organization. Also
provided, in accordance with an embodiment of the present
invention, is a business process monitoring system for monitoring a
business process being carried out by an organization including at
least one organization entity, each of which receives incoming
messages and generates outgoing messages, the system comprising
apparatus for storing information, characterizing the business
process, the information including a plurality of triads, each
triad comprising at least one characteristic of an incoming
message, at least one characteristic of an outgoing message and at
least an indication of an entity which receives the incoming
message and generates, responsively, the outgoing message; and
apparatus for monitoring the business processing by processing the
plurality of triads.
[0049] Further in accordance with an embodiment of the present
invention, the incoming message includes at least one of the
following: a document in a predefined state, a scanned document, a
middleware message, an SMS message, DB record, textual file,
e-mail, fax, HTTP page. Still further in accordance with an
embodiment of the present invention, at least one entity comprises
at least one of the following: a computerized business application,
an IT (Information Technology) service, a department, an
employee.
[0050] Additionally in accordance with an embodiment of the present
invention, the apparatus for monitoring is operative to detect
suspected occurrences of at least one of the following events:
errors in keying in data, double payment, bypassing at least one
process defined as mandatory by an organization; alteration of
payee; purchasing for personal gain; return of purchased item while
retaining the purchase price thereof.
[0051] Further in accordance with an embodiment of the present
invention, the data comprises at least one of a check, a voucher,
and a depreciation record.
[0052] Also provided, in accordance with an embodiment of the
present invention, is a method for monitoring a business process
involving a plurality of workstations or/and computerized services,
the method comprising receiving messages exchanged between the
plurality of workstations or/and computerized services and having
content, and for deriving from the content of the messages,
monitoring information regarding the business process.
[0053] Further in accordance with an embodiment of the present
invention, receiving and deriving comprises recognizing at least
one of the following types of messages: a purchase order; an
invoice; a shipping receipt. Also provided, in accordance with an
embodiment of the present invention, is a method for detecting
fraud comprising building a data centric process flow network and
monitoring at least one business process having an inception point
marking its beginning and a closing point marking its end, from the
inception point to the closing point, the business process
including messages, the monitoring including analyzing at least one
current message, belonging to the business process and having
content including at least one data field, relative to at least one
previous message belonging to the business process and having
content including at least one data field common with the current
message, including comparing values of the at least one common data
field between the current and previous messages.
[0054] The terms "Transaction" and "Process instance" are generally
synonymous. The terms "Junction", "network node", "message class"
and "node" are generally synonymous. The terms "Message" and
"message-instance" are generally synonymous. The term "business
route" and "route", and "triad" are generally synonymous. The terms
"meta-tag field", message data field and "logical name" are
generally synonymous. The terms "computerized representation of a
process" and "process definition", and "data centric process
model", and "process flow network" are generally synonymous. The
terms "Analytical engine" and "Correlation engine" and "Process
rule engine" and "Engine" are generally synonymous. The terms "IT
system, service and business application" and "computerized
services" are generally synonymous.
[0055] Any suitable processor, display and input means may be used
to process, display, store and accept information, including
computer programs, in accordance with some or all of the teachings
of the present invention, such as but not limited to a conventional
personal computer processor, workstation or other programmable
device or computer or electronic computing device, either
general-purpose or specifically constructed, for processing; a
display screen and/or printer and/or speaker for displaying;
machine-readable memory such as optical disks, CDROMs,
magnetic-optical discs or other discs; RAMs, ROMs, EPROMs, EEPROMs,
magnetic or optical or other cards, for storing, and keyboard or
mouse for accepting. The term "process" as used above is intended
to include any type of computation or manipulation or
transformation of data represented as physical, e.g. electronic,
phenomena which may occur or reside e.g. within registers and/or
memories of a computer.
[0056] The above devices may communicate via any conventional wired
or wireless digital communication means, e.g. via a wired or
cellular telephone network or a computer network such as the
Internet.
[0057] The apparatus of the present invention may include,
according to certain embodiments of the invention, machine readable
memory containing or otherwise storing a program of instructions
which, when executed by the machine, implements some or all of the
apparatus, methods, features and functionalities of the invention
shown and described herein. Alternatively or in addition, the
apparatus of the present invention may include, according to
certain embodiments of the invention, a program as above which may
be written in any conventional programming language, and optionally
a machine for executing the program such as but not limited to a
general purpose computer which may optionally be configured or
activated in accordance with the teachings of the present
invention.
[0058] Any trademark occurring in the text or drawings, such as but
not limited to terms marked with an asterisk, is the property of
its owner and occurs herein merely to explain or illustrate one
example of how an embodiment of the invention may be
implemented.
BRIEF DESCRIPTION OF THE DRAWINGS
[0059] Certain embodiments of the present invention are illustrated
in the following drawings:
[0060] FIG. 1A is a simplified diagram of prior art
workflow-centric monitored business processes;
[0061] 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;
[0062] 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;
[0063] FIGS. 3A-3B are simplified illustrations of triads and
connections therebetween, in accordance with certain embodiments of
the present invention;
[0064] 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;
[0065] 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;
[0066] 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;
[0067] 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;
[0068] 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;
[0069] FIG. 9A is a simplified functional block diagram of an
database adaptor constructed and operative in accordance with
certain embodiments of the present invention;
[0070] 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;
[0071] 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;
[0072] FIG. 11 is a simplified diagram of a prior art
publish/subscribe mechanism;
[0073] 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;
[0074] 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;
[0075] 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;
[0076] 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;
[0077] 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;
[0078] 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;
[0079] 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;
[0080] 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;
[0081] 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;
[0082] 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;
[0083] FIG. 22 is a simplified diagram of an example of a suitable
data structure for the Audit database 103 of FIG. 6;
[0084] 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;
[0085] FIG. 24A is a simplified diagram of an example of a suitable
data structure for the process definition database 635 of FIG.
6;
[0086] FIG. 24B is a simplified diagram of an example of a suitable
data structure for the message queue database 620 of FIG. 6;
and
[0087] 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
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] After data has been extracted from the configuration files,
it may be transformed to triads as follows:
TABLE-US-00001 <input message - app/.....- ?????> <???? -
app/..... -output message >
[0093] 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.
[0094] 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:
TABLE-US-00002 <Invoice - `Handle Payment` - Approved Payment
Voucher > <???? - `Web Service1` - Invoice > < Approved
Payment Voucher - `Web Service2` - ?????>
[0095] 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. As
a result, the following triads are obtained:
Triad 1: <Invoice--`Handle Payment`--Approved Payment
Voucher>
Triad 2: <Purchase Order--`Web Service`--Invoice>
Triad 3: <Approved Payment Voucher--`Web
Service2`--Payment>
[0096] Meta-tags may be defined for the above 3 triads
respectively, comprising the following data fields
respectively:
1.sup.st triad: supplier name, ordered items, total sum, invoice
date or number 2.sup.nd triad: supplier name, PO date or PO number
3.sup.rd triad: supplier name, total sum.
[0097] 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.
[0098] 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.
[0099] 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:
Method A
[0100] Step 1. Find a triad, whose meta-tag is involved in the
content of new message.
[0101] Step 2. 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
step 1. After finding all the triads as above, go to Step 3.
[0102] Step 3. Look for an entity that produces this message and
build the new triad or fix this message content and go to Step
1.
[0103] 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:
<List of Received Claimant's Documents, Claim Department, Letter
Reporting Pay/Don't Pay Decision>
[0104] 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.
[0105] 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.
[0106] 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.
[0107] 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.
[0108] 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.
[0109] 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:
Method B
[0110] Step 1. Get a current message from the Queue and identify a
node. Go to Step 2
[0111] Step 2. Look for the same meta-tag data value in the
previous nodes available in the DATABASE.
[0112] If the node and message are found, perform step 2.1.
[0113] If the node is found but the message is not found, perform
step 2.2.
[0114] 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.
[0115] 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 Step 3
[0116] 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 Step 3
[0117] 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 Step 3
[0118] Step 3 Get next message from the Queue and go to Step 1.
Method C
[0119] Step 1 The same as in the Method A. Go to Step 2
[0120] Step 2 The same as in the Method A. Go to Step 3
[0121] Step 3 Generate a meta-tag based Query to search all
messages in the Queue related to the next adjacent nodes.
[0122] Two possible results are as follows: [0123] At least one
message is found, in which case step 3.1 is performed, or [0124] No
message is found, in which case step 3.2 is performed.
[0125] 3.1 Perform Step 1 and Step 2 for each of the found
messages. At the end of each cycle extend (or change) Query for
Step 3. Do Step 3 with new Query. At the end, go to Step 1.
[0126] 3.2 Go to Step 1.
[0127] Method C is active and Query driven, whereas Method A is
passive in that it serves messages from the queue one by one.
[0128] A method for inserting a new node "on-the-fly" as was
described above in the example of insurance claim, extends Step 2
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.
[0129] 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.
[0130] 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 Baud. 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".
[0131] 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 Step 2 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).
[0132] 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.
[0133] 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.
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.
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). 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). 4) Altered payee: this refers to errors in data typing by
controlling a name of a supplier. 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). 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.
[0134] Referring again to the system of FIG. 4, the system may
comprise the 3 functional boxes and 2 data storage units shown:
[0135] 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.
[0136] Analytical Engine--monitors and controls a single overall
business process based on message-to-process correlation method and
alerting.
[0137] Monitor--visualizes results of control and monitoring
providing organizations with reports and dashboards.
[0138] Message Instance Queue--incoming to Analytical Engine.
[0139] Process-Instance Database--outgoing from Analytical
Engine.
[0140] A possible data flow between the system components of FIG. 4
is as follows:
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.
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. 3--Message-instance arrives at
the Message Queue from Content management platform and Content
routing (brokering) network. 4--Message-instance arrives at
Analytical Engine from Message Queue. 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. 6--Data to be used for reporting by
Monitor arrives from Process instance database created by
Analytical Engine.
[0141] 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.
[0142] 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.
[0143] 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).
[0144] 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.
[0145] 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).
[0146] 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.
[0147] 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.
[0148] Process Instance Database 614--This database may store all
messages, process instances and process instance IDs.
[0149] 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.
[0150] 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.
[0151] Process Config File--typically an XML Document with
predefined (built-in) full process definition.
[0152] 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.
[0153] 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.
[0154] 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)
[0155] 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.
[0156] Adaptor--facilitates communication between plurality of
adaptors, the Adaptor Manager and the Message Depositor.
[0157] 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
[0158] 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.
[0159] 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.
[0160] A possible data flow between the system components of FIG. 6
is as follows:
A1--Adaptor may register with the Adaptor Manager providing
appropriate credentials and optional encryption parameters. [0161]
Adaptor may provide, if asked by the Adaptor Manager, a list of all
native messages and fields that are available. [0162] Adaptor may
send configuration of the native filter/subscriber. [0163] Adaptor
Manager may send the request for all native messages and fields.
[0164] Adaptor Manager may send configuration for the Adaptor's
filter to specify only a subset of the native messages and fields
that are relevant. 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.
[0165] 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.
[0166] 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.
[0167] C2--After Process Instance Correlator has completed
correlation, a message is sent to the Process Rule Engine, so that
Rules can be applied.
[0168] 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.
[0169] 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.
[0170] 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.
[0171] 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.
[0172] C7--The Adaptor Manager may receive a process definition to
configure the adaptors.
[0173] 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.
[0174] D2--The triad Designer may create a new process definition,
an XML configuration document, into Process Loader.
[0175] 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.
[0176] D4--The triad Designer gets the Process configuration
document for updating and data mapping.
[0177] 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.
[0178] 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.
[0179] 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.
[0180] E3--Message Queue Database may provide all of the queue
messages for all of the processes to the Process Instance
correlation and validation.
[0181] E4--Message Depositor may place a newly received message
into appropriate message queue by process ID in the Message Queue
Database.
[0182] E5--TRIAD Designer 600 may interact with the Process
Definition Database to create, edit, remove or update process
definitions of any process.
[0183] 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.
[0184] 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.
[0185] E8--ARM Manager gets Process Definition from the Process
Definition Database at the end of the ARM Registration.
[0186] M1--Monitor may retrieve the audit data from the Audit
Database.
[0187] R1--ARM may deposit process definition after successful
registration into Audit Database
[0188] ARM may deposit incoming messages, alerts and all associated
information to the Audit Database
[0189] ARM may update and read Audit Database during processing of
alert resolutions
[0190] Business applications may include J2EE, .NET, ERP (like
AccPac and SAP), and CRM type applications, inter alia.
[0191] 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.
[0192] 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:
1) Adaptor to message broker such as WLI* from BEA* or WebSphere*
from IBM* 2) Adaptor to Enterprise Service Bus (ESB*) such as
Aqualogic* from BEA or WebSphere* from IBM or Sonic* from Progress
3) Adaptor to content router such as SolaOs* from Solace* Systems
4) Adaptor to a ECM* platform such as EMC Corporation's Documentum
system or IBM Corporation's FileNet system 5) Custom developed
adaptor to ERP system for small or medium sized organizations, such
as AccPac* from Sage Group.
[0193] 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:
a. the entities b. each entity's incoming and outgoing
messages=junction In and junction OUT, c. the data fields and where
they are located in the incoming or outgoing messages, and d. the
formulae for monitoring checks e.g. as shown in the Rule table
described herein.
[0194] 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.
[0195] 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.
[0196] 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."
[0197] 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."
[0198] The following is a description of how an adaptor may get a
message named "SENTPO" that is published by an organization
application called "ACCPAC".
[0199] 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:
1. Make connectivity to Message broker: a. Broker domain configured
b. Publication--"ACCPAC" application has to publish its SENTPO
message. c. Topic (Optional)--ACCPAC has to publish its messages
with known topics (as "ACCPAC_PO" for example) d. Filter
(optional)--"SENTPO" has field name title with value "SENTPO" (for
filtering, there can be other fields as well) e. Adaptor
queue--Adaptor Manager needs to have a queue where the messages may
be sent to <QName>. f. Security--Adaptor Manager has to
authorize Adaptor to access the broker.
[0200] FIG. 11 is a simplified diagram of a prior art
publish/subscribe mechanism.
2. Send Subscription request:
[0201] 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:
TABLE-US-00003
<psc><Command>RegSub</Command><Topic>ACCPAC_PO
</Topic><RegOpt>PubOnReqOnly</RegOpt><Filter>Body.-
Title like `SentPO` </Filter>
<QName>AdaptorQue</QName></psc>
3. Forward Message to Engine:
[0202] 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.
[0203] 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.
[0204] 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.
[0205] 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
[0206] 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.
Fetch Content from Repository: 1. Connect to Documentum repository
using the Documentum API (DFC, ECI) and standard JDBC fibs. Visual
connection can be done also through the Repository Integration
Utility. 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:
SELECT * FROM dm_document SEARCH DOCUMENT Contains `ABC <AND>
television` WHERE FOLDER (ID('0b9af3ce800001ff)) AND (object_name
like `% Receiving Report %`)
[0207] `Folder ID` is a DUMMY ID, just for the sake of example.
[0208] 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. 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.
[0209] 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.
[0210] 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.
[0211] An adaptor sends to the correlation engine the messages
content according to the messages requests which were predefined in
the Process Definition XML file.
[0212] 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).
TABLE-US-00004 <?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> <!-- GROUPS -->
<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> <!-- CFTypes --> <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:CFFieldsGroup" 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>
Each Message Adaptor:
[0213] Reads/gets message content from the organization information
source [0214] Translates this message content into xml format
[0215] Deposits message in the Engine by calling the engine web
service (see below). [0216] Receives confirmation message from
Engine.
[0217] Both Engine and Adaptor publish web services for
communication between them. Engine web service allows: Deposit
message and Register adaptor
[0218] Adaptor web service allows bringing of Database Tables with
native field names for mapping.
[0219] The adaptor, when it initializes, registers itself at the
Engine, and then initiates a two-sided start to communicate.
[0220] 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.
[0221] 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:
Step 1191. Trigger gets key data of updated SQL database (DB)
tables and puts them in CF Key data is a value of the new or
updated record ID in the given DB table. Step 1192. Listener
listens and fetches constantly the key data and forwards it to the
Message Factory Step 1193. Message Factory creates new Message
instance according to the key data Step 1194. Message Object
through connector asks SQL DB re the updated data Step 1195.
Message Object gets the data from DB 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.
[0222] An example of database adaptor creation for AccPac is
described below.
[0223] 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.
[0224] ACCPAC database is a type of SQL server DB.
[0225] The "Process Definition" file which describes the messages
and their fields is typically employed. Steps for adaptor creation
include development of the J2EE server, and the Accpac database
server (SQL side).
SQL Side:
[0226] 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.
[0227] A CFMessages table contains the following columns:
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. 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. 3.
messageTime--time of message, created automatically. 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. 5. messageId--internal auto
increase number for message-instance.
[0228] 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:
TABLE-US-00005 CREATE TRIGGER [dbo].[newRequisition] ON
[dbo].[PORQNH1] 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
[0229] J2EE Server side--develop the following functional
components as J2EE web application server.
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.
[0230] 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. Query
can be done through sql syntax as:
TABLE-US-00006 jdbc.executeQuery("select
AUDTUSER,RQNHSEQ,RQNNUMBER,VDCODE,VDNAME,REQUESTBY,DATE,LINES from
PORQNH1 where RQNHSEQ="+key);
[0231] where "key" is the key value of the updated row.
[0232] Messageclasses may have a function that transform their
content to predefined XML format (CFMessage). For example Result of
the transformation may be as follows:
TABLE-US-00007 <?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>
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. 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. d.
Connector--JDBC connection to the Database e. Depositor--Every
message instance creates xml. This xml is forwarded to the Engine
(Message Queue database) through WSDL that the Engine provides.
[0233] 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.
[0234] 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.
[0235] 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.
[0236] 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%).
[0237] 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%).
[0238] 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
[0239] 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.
[0240] 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.
[0241] 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.
[0242] 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.
[0243] 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.
[0244] 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.
[0245] 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.
[0246] 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:
1. SupplierName
2. SupplierNumber
[0247] 3. Total (sum or ordered items)
4. ItemNumber
5. ItemDescription
6. ItemQuantity
[0248] 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.
Rule 1:
TABLE-US-00008 [0249] IF message "Returns" is not AND available for
the current message: SupplierName OR 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>" 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.
Rule 2
TABLE-US-00009 [0250] 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"
Rule 3
TABLE-US-00010 [0251] 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> "
Rule 4
TABLE-US-00011 [0252] 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"
Rule 5
TABLE-US-00012 [0253] 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
Rule 6 (Rule 1 applied especially for several messages)
TABLE-US-00013 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>"
Rule 7
TABLE-US-00014 [0254] 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"
Rule 8
TABLE-US-00015 [0255] 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"
Rule 9
TABLE-US-00016 [0256] 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"
Rule 10
TABLE-US-00017 [0257] 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"
Rule 11
TABLE-US-00018 [0258] IF the current message is "Debit note Entry"
AND message "Returns" is available THEN alert message: "Fraud or
Error occurs. Check the item return process"
[0259] 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.
[0260] 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.
[0261] The methods include some or all of the steps shown in FIG.
8, suitably ordered e.g. as shown:
[0262] 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.
[0263] 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
[0264] Incoming documents and delivers Outgoing documents
(messages). A triad so constructed is also termed herein a
"business route".
[0265] Step 980. Generate message meta-tag for each business
route
[0266] 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.
[0267] Steps 985. Generate weight for each of the meta-tag fields
e.g. by applying the following rules:
[0268] 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).
[0269] 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).
[0270] 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.
[0271] An example of connecting triads is as follows: Consider the
following triads:
TABLE-US-00019 a. sent purchase order ---> supplier --->
invoice c. sent purchase order ---> supplier---> shipping
receipt The two can be combined to a single structure: sent
purchase order -------> invoice | -------> shipping receipt
As shown, there is now only one entity -- "supplier" - which is
responsible for execution of 2 business routes: sipping and
invoicing.
[0272] 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.
[0273] 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.
[0274] At the end of the process shown in FIG. 8 the Process
Definition file may be sent to adaptor. Example of this file for
the buying process is as follows:
TABLE-US-00020 <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="item Quantity"
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>
[0275] 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.
[0276] 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.
[0277] 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.
[0278] 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).
[0279] Process definition database 635 typically stores the
meta-tag spec.
[0280] 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.
[0281] 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.
[0282] Content-centric process model Related to Supplier is shown
in the Table of FIG. 23A-D. 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 adaptor
and type 1 or 2--WebSphere Message Broker adaptor. The use of each
of these adaptors is described above.
[0283] 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".
[0284] 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.
[0285] The following program is useful in implementing the system
of FIG. 6:
TABLE-US-00021 CREATE DATABASE IF NOT EXISTS pw_archives; USE
pw_archives; -- -- Definition of table `actions` - Defines the
various ways 'alert' is handled. -- examples: Accept alert ,
Dismiss alert , forward email notification. -- DROP TABLE IF
'actions' EXISTS; CREATE TABLE `actions` ( `type` varchar(15) NOT
NULL, `id` varchar(45) NOT NULL, `actionDescription` text NOT NULL,
PRIMARY KEY USING BTREE (`id`) ) ENGINE=InnoDB DEFAULT
CHARSET=latin1; -- -- Definition of table `alertsdefintions` -
Defines the types of alerts which PW handles. -- example for alert
could be: 'Error in data'-'Incompatibilty of data fields between
documents' -- DROP TABLE IF `alertsdefintions`EXISTS; CREATE TABLE
`alertsdefintions` ( `id` int(10) unsigned NOT NULL, `title`
varchar(45) NOT NULL, `pdid` int(10) unsigned NOT NULL default '1'
COMMENT 'process defintion id', `description` varchar(100) NOT
NULL, `responsible` int(10) unsigned NOT NULL, PRIMARY KEY USING
BTREE (`id`), KEY `FK_alertsdefintions_1` (`responsible`),
CONSTRAINT `FK_alertsdefintions_1` FOREIGN KEY (`responsible`)
REFERENCES `responsibles` (`responsibleId`) ) ENGINE=InnoDB DEFAULT
CHARSET=latin1; -- -- Definition of table `alertsevents` - Table
contains alerts instances that occured in the system. -- DROP TABLE
IF EXISTS `alertsevents`; CREATE TABLE `alertsevents` ( `alertId`
int(10) unsigned NOT NULL, `date` datetime NOT NULL, `alertType`
int(10) unsigned NOT NULL, `alertProperties` text NOT NULL,
`status` varchar(45) NOT NULL, `transactionId` varchar(15) NOT
NULL, `responsible` int(10) unsigned default NULL, `messageId`
int(10) unsigned NOT NULL, PRIMARY KEY (`alertId`), KEY
`FK_alertsevents_1` USING BTREE (`alertType`), KEY
`FK_alertsevents_3` (`transactionId`), KEY `FK_alertsevents_2`
(`responsible`), CONSTRAINT `FK_alertsevents_1` FOREIGN KEY
(`alertType`) REFERENCES `alertsdefintions` (`id`), CONSTRAINT
`FK_alertsevents_2` FOREIGN KEY (`responsible`) REFERENCES
`responsibles` (`responsibleId`), CONSTRAINT `FK_alertsevents_3`
FOREIGN KEY (`transactionId`) REFERENCES `transactions` (`id`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -- Definition of table
`emailtrack` - incase of sending email using PW, table saves all
information on the email content and the recipients -- DROP TABLE
IF EXISTS `emailtrack`; CREATE TABLE `emailtrack` ( `alert` int(10)
unsigned NOT NULL default '1', `emailContent` text NOT NULL,
`responsibleTrack` text NOT NULL COMMENT 'list of all incharges',
PRIMARY KEY USING BTREE (`alert`), CONSTRAINT `FK_emailTrack_1`
FOREIGN KEY (`alert`) REFERENCES `alertsevents` (`alertId`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -- Definition of table
`junctions` - defintion of all messages that PW may track. -- DROP
TABLE IF EXISTS `junctions`; CREATE TABLE `junctions` ( `id`
int(10) unsigned NOT NULL auto_increment, `name` varchar(45) NOT
NULL, `nativeName` varchar(45) NOT NULL, `processId` varchar(45)
NOT NULL, PRIMARY KEY (`id`), KEY `FK_junctions_1` (`processId`),
CONSTRAINT `FK_junctions_1` FOREIGN KEY (`processId`) REFERENCES
`processdefintion` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- -- Definition of table `logs` - any action that has been done on
alert (which may change its status) may be recorded here -- DROP
TABLE IF EXISTS `logs`; CREATE TABLE `logs` ( `logId` int(10)
unsigned NOT NULL auto_increment, `alertId` int(10) unsigned
default NULL, `action` varchar(50) default NULL, `date` datetime
default NULL, `responsible` int(10) unsigned default NULL,
`comments` text, PRIMARY KEY USING BTREE (`logId`), KEY `FK_logs_1`
(`alertId`), KEY `FK_logs_2` (`responsible`), CONSTRAINT
`FK_logs_1` FOREIGN KEY (`alertId`) REFERENCES `alertsevents`
(`alertId`), CONSTRAINT `FK_logs_2` FOREIGN KEY (`responsible`)
REFERENCES `responsibles` (`responsibleId`) ) ENGINE=InnoDB DEFAULT
CHARSET=latin1; -- -- Definition of table `messages` - messages
instances that PW has tracked. -- DROP TABLE IF EXISTS `messages`;
CREATE TABLE `messages` ( `messageId` int(10) unsigned NOT NULL
auto_increment, `transactionId` varchar(45) NOT NULL, `junctionId`
int(10) unsigned NOT NULL, `fields` text NOT NULL, `date` datetime
NOT NULL, PRIMARY KEY USING BTREE (`messageId`), KEY
`FK_messages_1` (`transactionId`), KEY `FK_messages_2`
(`junctionId`), CONSTRAINT `FK_messages_1` FOREIGN KEY
(`transactionId`) REFERENCES `transactions` (`id`), CONSTRAINT
`FK_messages_2` FOREIGN KEY (`junctionId`) REFERENCES `junctions`
(`id`) ) ENGINE=InnoDB DEFAULT CHARSET= latin1; -- -- Definition of
table `processdefinition` - saves the processdefinition.xml -- DROP
TABLE IF `processdefinition`EXISTS; CREATE TABLE
`processdefinition` ( `id` varchar(15) NOT NULL, `content` text NOT
NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; --
-- Definition of table `responsibles` - list of people and general
data that are related to the PW system. -- DROP TABLE IF
`responsibles`EXISTS; CREATE TABLE `responsibles` ( `responsibleId`
int(10) unsigned NOT NULL auto_increment, `name` varchar(45) NOT
NULL, `jobtitle` varchar(45) NOT NULL, `email` varchar(45) NOT
NULL, PRIMARY KEY USING BTREE (`responsibieId`) ) ENGINE=InnoDB
DEFAULT CHARSET=latin1; -- -- Definition of table `transactions` -
instances of transactions that PW has tracked. -- DROP TABLE IF
EXISTS `transactions`; CREATE TABLE `transactions` ( `id`
varchar(45) NOT NULL, `startDate` datetime default NULL, `process`
varchar(15) NOT NULL, `vendor` varchar(45) default NULL,
`requestNumber` varchar(45) default NULL, `responsible` varchar(45)
NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT
CHARSET=latin1;
[0286] 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.
[0287] 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.
[0288] 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.
[0289] 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.
[0290] 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.
* * * * *
References