Patent Application
20130347004
In many instances, business process management systems (BPMS) can send out and receive messages between process instances for intra-/inter-process communications. The BPMS may “catch” the events related to sending and/or receiving the messages. For example, within a process definition, there can be integration points that are depicted by catching message events. One example for the catching message event can be an intermediate message event (IME). In this example, a business process instance can include an initiation, an interaction (e.g., with a human operator), an IME reception, and an endpoint, among others. For the business process instance to continue in its control flow in response to a received message, certain conditions may be required to be met. The conditions can include receiving the message at the endpoint the IME is listening to, and determining a true status for a correlation condition.
In some situations, the correlation condition may be applied to messages fitting a certain context. For example, the correlation conditions can include determining a match for all messages; determining a match between the messages and a constant value; and determining a match between the messages and a dynamic/potential value. The payload (e.g., content) of an incoming message can include not only the data relevant for evaluating the correlation condition, but also business data used for subsequent process execution, causing a high volume requirement depending on business scenarios (e.g., the total data volume can be arbitrarily large). This high volume requirement can cause a long processing time for scanning and comparing the complete message with the process context, impeding the flow of the business process instance that requires a true correlation status.
The present disclosure describes methods, systems, and computer-readable media for correlating messages in a business process management system. Incoming messages need a positive correlation condition with process context for successful process flow. The present disclosure can effectively and efficiently perform message correlation. For example, when a message is sent to a BPMS, attributes from the received message can be extracted to focus on a predefined set of attributes associated with a correlation condition of the BPMS instance, thereby reducing the total amount of information to be processed during the correlation determination. In some implementations, correlation conditions may be pre-defined during modeling of business process. The business process attributes to be extracted may be known for the particular process instances at runtime based on the predefined attributes relevant to the corresponding correlation conditions. The attributes for correlation may include one or more types of a string, a number, or a Boolean, among others. These types may be differentiated in the correlation condition, allowing for differentiation between relevant attributes. Further, the position of correlation attribute may be important when the correlation condition includes multiple attributes. In addition, attribute values can be significant to the correlation condition.
The present disclosure provides implementations of correlation condition matching based on fixed length identifiers called fingerprints. These fingerprints can be easily stored in a relational database (e.g., due to small size) and can be compared directly and efficiently with each other. The fingerprints can be uniquely based on combinations of positions, types, and values of a subset of attributes associated with a message, and can be generated using a hash function, under a low probability of collision. The use of the fingerprints in determining message correlation can allow the system to effectively and efficiently evaluate correlation conditions.
In a general aspect, a method for correlating messages can include identifying a message received at an end point associated with at least one executing business process instance. At least one attribute of the identified message is identified. The message can be associated with a defined set of relevant attributes associated with a correlation condition of at least one business process instance associated with the end point. A message context fingerprint containing the at least one identified attribute of the identified message is generated. A hash algorithm can be applied to the message context fingerprint to create a message context fingerprint hash. The message context fingerprint hash is uniquely associated with the at least one identified attribute of the identified message. The message context fingerprint hash can be compared to a number of business process instance fingerprint hashes. The business process instance fingerprint hashes can be generated from a number of business process instance associated with the end point. The identified message associated with the message context fingerprint hash can be correlated with the business process instance associated with the matching hashed business process instance fingerprint hash.
These and other embodiments can each optionally include one or more of the following features. For example, after correlation, the message can be sent to the corresponding business process instance for consumption. The message can be received at a corresponding business process instance. In response to a determination that the control flow of the corresponding business process instance is ready to consume the message, the message context fingerprint hash is compared to the current business process instance fingerprint hash of the corresponding business process instance to confirm a match. In response to a determination that a match is confirmed, the message is consumed at the corresponding business process instance. When a match is not confirmed, the message is discarded. In some implementations, the end point can include a structure defined by an intermediate message event associated with a process definition. The payload of the received message can be provided in an XML schema or web service description language.
These and other embodiments can each optionally include one or more of the following features. In some implementations, the correlation condition can include equality conditions concatenated with a logical operator based on payload and context of the message. The defined set of relevant attributes can be defined by rules for extracting data from the context of the received message. The business process instance fingerprint hashes can be generated into a predetermined format based on position, type and value. The business process instance fingerprint hashes can be defined upon instantiation of the business process instance. The business process instance fingerprint hashes can be recalculated during execution of the business process instance in response to a change to a process context associated with the business process instance.
While generally described as computer-implemented software embodied on tangible and non-transitory media that processes and transforms the respective data, some or all of the aspects may be computer-implemented methods or further included in respective systems or other devices for performing this described functionality. The details of these and other aspects and embodiments of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.
This specification describes systems, methods, apparatus, and computer-readable media for correlating messages in a business process management system (BPMS). Incoming messages need a positive correlation condition corresponding with a particular business process instance's process context for successful correlation and use of the message. The methods described in the present disclosure can effectively and efficiently perform message correlation. For example, when a message is sent to a BPMS, attributes from the received message can be extracted to focus on a predefined set of attributes associated with a correlation condition of the BPMS instance, thereby reducing the total amount of information to be processed during the correlation determination. In some implementations, correlation conditions may be pre-defined during modeling of business process. The business process attributes to be extracted may be known for the particular process instances at runtime based on the predefined attributes relevant to the corresponding correlation conditions. The attributes for correlation may include one or more types of a string, a number, or a Boolean, among others. These types may be differentiated in the correlation condition, allowing for differentiation between relevant attributes. Further, the position of correlation attribute may be important when the correlation condition includes multiple attributes. In addition, attribute values can be significant to the correlation condition
At a high level, the disclosed methods can enable a business process management system to correlate messages. The method can include modeling a process definition with an intermediate message event (IME) at design time. The IME can define the structure for incoming messages; for example, for different formats of the messages (e.g., XML schema, web service description language, etc.). The IME can also define a correlation condition; for example, defining equality conditions involving logical operations, message payload, and process context. In other words, the IME defines the types of messages that it will receive at a particular time. The IME may be associated with a web services endpoint, in some instances. At process instantiation time, correlation condition values can be calculated based on an initial process context of the business process instance, which can be used to define a process context fingerprint for the business process instance. The attributes relevant to the correlation condition can be evaluated for the process context, and the fingerprint of the business process instance can be initially defined. If the process context changes at runtime, the business process instance's fingerprint can be reassessed to provide an updated value against which the corresponding message fingerprints can be compared. The defined correlation conditions can be used at runtime to extract the relevant portions from messages to compare to the values retrieved from the process context. After deployment time (e.g., of the related application including business process), a web service endpoint provided by server can accept the messages having structures defined by the IME, when the IME is associated with that web service endpoint.
At runtime, one or more process instances are initiated or initialized based on the (business) process definition. Input data associated with the instantiated business process can be provided to help define the initial process context. A process instance may receive incoming messages regardless of its progress through the control flow. For example, a particular process instance may be correlated with a message, even if the message is received prior to a time when the message is ready to be processed. For each process instance, the correlation attributes can be extracted from the process context, and process context-related business process instance fingerprints can be calculated based on particular messages attributes, including the attributes' position, type, value, and other data. The calculation may employ a hash algorithm to realize a fixed length format, and to provide a relatively short and easily compared value. The fingerprints can be persisted for each process instance. In some instances, changes on affected and relevant attributes can trigger and force a recalculation to perform a persistency update. In some implementations, a message is received at a web service end point associated with a BPMS and/or one or more business process instances. Relevant message attributes can be extracted from the received messages for calculations of the corresponding message fingerprints. The calculated message fingerprints are then compared with fingerprints of the process context. If the message fingerprints match the process context fingerprints, then the message is received by the matching process instance associated with the process context fingerprint, otherwise it is discarded if no matches are found. When the control flow of the process instance reaches the IME (e.g., in a case where the process context fingerprints are updated), the fingerprint of the message and the process context are compared again to ensure continued correlation. If the fingerprints still match, then the message is consumed.
At a high level, the business process management system 103 can be connected with one or more clients such as the client 175. For example, the business process management system 103 can receive messages from the client 175. The messages can be correlated with process context using a business process runtime engine 130 in the business process management system 103. Once correlated, the message sent from the client 175 can be consumed at the business process management system 103, such as, for example, values carried in the message applied to the business application 127 of the business process management system 103. In some instances, messages may be received at the business process management system 103 from systems other than clients 175, such as other internal systems assisting in the performance and completion of various business processes.
In the illustrated implementation of
The interface 106 is used by the business process management system 103 to communicate with other systems in a client-server or other distributed environment (including within environment 100) connected to the network 148 (e.g., the client 175, as well as other systems communicably coupled to the network 148). The interface 106 generally includes logic encoded in software and/or hardware in a suitable combination and operable to communicate with the network 148. More specifically, the interface 106 may include software supporting one or more communication protocols associated with communications such that the network 148 or the interface hardware is operable to communicate physical signals within and outside of the illustrated environment 100.
The processor 109 can be any appropriate processing unit or units to enable computation in the business process management system 103. Although illustrated as a single processor 109 in the business process management system 103, two or more processors may be used in the business process management system 103 according to particular needs, desires, or particular embodiments of environment 100. The processor 109 may be a central processing unit (CPU), a blade, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another suitable component. Generally, the processor 109 executes instructions and manipulates data to perform the operations of the business process management system 103 and, specifically, the functionality associated with the corresponding business application 127 and the business process runtime engine 130. In one implementation, the server's processor 109 executes the functionality required to receive inbound communications from and send outbound communications to the client 175, as well as the functionality required to perform the operations of the associated business application 127 and the business process runtime engine 130, among others.
The memory 112 of the illustrated business process management system 103 stores at least a database or other storage for business process definitions 115, fingerprint hashes 117 generated by the business process runtime engine 130, business process contexts 119, messages 120 received from the client 175, and other data and program instructions. The memory 112 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. The memory 112 may store various objects, object models, and data, including classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, process contexts, repositories storing services local to the business process management system 103, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references associated thereto with the purposes of the business process management system 103 and its functionality. In some implementations, including a cloud-based system, some or all of the memory 112 may be stored remote from the business process management system 103, and communicably coupled to the business process management system 103 for usage. Specifically, memory 112 can store business process runtime engine 130. Some or all of the elements illustrated within memory 112 may be stored external to the memory 112. These items are made accessible to the business process runtime engine 130. The memory 112 includes the business process definitions 115 modeled with an intermediate message event (IME). The business process definitions 115 can be associated with the business processes 121 in the business application 127. The memory 112 also includes the fingerprint hashes 117 generated for both the incoming messages 120 and the process context 119. The business process contexts 119 can be associated with one or more business process instances 132 in the business process management system 103, and can be stored in the memory 112. Process contexts 119 can be modified during the execution of the various business process instances 132 in response to changing variables, events, and other actions. The incoming messages 120 from client 175 and other multiple clients can be stored, sometimes temporarily, in the memory 112. The information stored in the memory 112 can support operations of the business application 127 as well as the business process runtime engine 130.
At a high level, the business application 127 can be any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information associated with a particular business process management system 103. In particular, the business application 127 may be associated with one or more business processes that communicate with other users, applications, systems, and components to send, receive, and process events. In some instances, a particular business application 127 may operate in response to and in connection with one or more requests received from an associated client 175 or other remote client. Additionally, a particular business application 127 may operate in response to and/or in connection with one or more requests received from other applications external to the business process management system 103. In some instances, the business application 127 may request additional processing or information from an external system or application. In some instances, one or more of the applications may represent a web-based application accessed and executed by remote clients 175 via the network 148 (e.g., through the Internet, or via one or more cloud-based services associated with the business application 127). Further, while illustrated as internal to the business process management system 103, one or more processes associated with a particular application 127 may be stored, referenced, or executed remotely. For example, a portion of a particular application 127 may be a web service that is remotely called, while another portion of the business application 127 may be an interface object or agent bundled for processing at a remote system (not illustrated), or a particular client 175 (e.g., the client application 184). Moreover, any or all of a particular application 127 may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure. Still further, portions of the particular application 127 may be executed or accessed by a user working directly at the business process management system 103, as well as remotely at a corresponding client 175.
The business process runtime engine 130 can provide message correlation by examining correlation conditions, and can generally perform the runtime operations required to perform one or more business processes 121 associated with the various business process instances 132. The business process runtime engine 130 includes or is associated with one or more businesses process instances 132, a fingerprint generator 133, a fingerprint comparison module 136, and a process context module 142. The business process instance 132 can be associated with the business process 121 of the business application 127. For example, the business process instance 132 can be an instantiation of the business process 121. The fingerprint generator 133 can be an internal algorithm for calculating and generating fingerprints based on attributes of the messages 120 as well as for calculating and generating fingerprints of the process context. In some implementations, the fingerprint algorithm uses a hash algorithm to generate fingerprint hashes of a predefined length after an initial fingerprint is generated. The fingerprint comparison module 136 can examine and compare the fingerprints, or fingerprint hashes, of incoming messages to the fingerprint hashes of the process contexts identified by the process context module 142. The fingerprint comparison module 136 can further include a fingerprint persistence module 139 that is constantly, periodically, or frequently monitoring changes and updating fingerprint hashes of the process context. For example, the fingerprint persistence module 139 can persist an updated fingerprint hash for determining the correlation condition between the message fingerprint hash and the process context fingerprint hash. The message can be consumed at the business application 127 if the message correlation satisfies matching criteria through the sequence flow.
In general, the business process runtime engine 130 can identify relevant attributes of the messages 120 and the process contexts 119 of the business process management system 103. The business process runtime engine 130, or one of its components or modules, can place the identified attributes into an ordered and typed structure. The structure can subsequently be serialized. The fingerprint generator 133 can then calculate the fingerprints based on the serialized format of the attributes, for example, using a hash algorithm. The fingerprints can be used to identify the correlation condition. In some implementations, the serialized format of the attribute may be like the following:
The serialization can be handled by a self-contained implementation, for example, external libraries may not be required for changing the serialized format or the fingerprint calculation. The serialized format can be maintained constant over time. This is for consistency and allowing the updated fingerprint hashes match to pre-calculated fingerprint hashes for the same attributes. More fingerprint generation examples are described in
In general, the business process management system 103 is any server or system that stores, manages, and executes functionality associated with the business application 127 and the business process runtime engine 130. Additionally, the business process management system 103 may execute one or more applications 127. For example, each business process management system 103 may be a Java® 2 Platform, Enterprise Edition (J2EE)-compliant application server that includes Java® technologies such as Enterprise JavaBeans® (EJB), J2EE Connector Architecture (JCA), Java® Messaging Service (JMS), Java® Naming and Directory Interface (JNDI), and Java® Database Connectivity (JDBC). In some instances, each business process management system 103 may store a plurality of various applications; while in other instances, the business process management system 103 may be a dedicated server meant to store and execute the business process runtime engine 130 for a particular platform or application and its related functionality. In some instances, the business process management system 103 may include a web server or be communicably coupled with a web server, where one or more of the applications 127 associated with the business process management system 103 represent web-based (or web-accessible) applications accessed and executed through requests and interactions received by the client 175, executing a client application 184 operable to interact with programmed tasks or one or more applications 127.
The business process management system 103 can include an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the environment 100. The business process management system 103 illustrated in
Referring now to the client 175 illustrated in
The client 175 includes at least an interface 178, a processor 181, the client application 184, and a memory 187. The processor 181 performs analysis and data extraction related to the client application 184. Although illustrated as a single processor 181 in the client 175, two or more processors may be used in the client 175 according to particular needs, desires, or particular embodiments of environment 100. The processor 181 may be a central processing unit (CPU), a blade, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another suitable component. Generally, the processor 181 executes instructions and manipulates data to perform the operations of the client 175 and, specifically, the functionality associated with the client application 184.
The memory 187 of the client 175 stores data and program instructions, rules associated with inbound and/or outbound communication. The memory 187 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. The memory 187 may store various objects, object models, and data, including classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, process contexts, repositories storing services local to the client 175, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the client 175 and its functionality. In some implementations, including a cloud-based system, some or all of the memory 187 may be stored remote from the client 175, and communicably coupled to the client 175 for usage. Some or all of the elements may be stored external to the memory 187, for example, in an internet-based storage location.
The GUI 190 associated with the client 175 includes a graphical user interface operable to, for example, allow the client 175 to interface with at least a portion of the client application 184, and/or the associated operations and functionality. Generally, the GUI 190 provides the particular user with an efficient and user-friendly presentation of business data provided by or communicated within the system. The GUI 190 may include a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by the user. For example, the GUI 190 may provide interactive elements that allow a user to interact with a particular component within and/or external to environment 100. Different portions of the corresponding component's functionality may be presented and accessible to the user through the GUI 190, such as through the client application 184 (e.g., a web browser). Generally, the GUI 190 may also provide general interactive elements that allow a user to access and utilize various services and functions of a particular component. In some instances, the client application 184 may be used to access various portions of the business process management system 103. In some instances, the client application 184 may be an agent or client-side version of the business application 127 or other suitable component of the business process management system 103. The GUI 190 may present the information of the client application 184 for viewing and interaction. In general, the GUI 190 is often configurable, supports a combination of tables and graphs (bar, line, pie, status dials, etc.), and is able to build real-time portals, where tabs are delineated by key characteristics (e.g., site or micro-site). Therefore, the GUI 190 contemplates any suitable graphical user interface, such as a combination of a generic web browser, intelligent engine, and command line interface (CLI) that processes information in the platform and efficiently presents the results to the user visually.
As used in this disclosure, each client 175 is intended to encompass a personal computer, touch screen terminal, workstation, network computer, kiosk, wireless data port, smart phone, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing device. For example, each client 175 may include a computer that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept user information, and an output device that conveys information associated with the operation of one or more client applications 184, and/or the client 175 itself, including digital data, visual information, or the GUI 190. Both the input and output device may include fixed or removable storage media such as a magnetic storage media, CD-ROM, or other suitable media, to both receive input from and provide output to users of client 175 through the display, namely, the GUI 190. The client's processor 181, interface 178, and memory 187 may be similar to or different from those described in connection with the other components illustrated in
The network 148 may be all or a portion of an enterprise or secured network, while in another instance, at least a portion of the network 148 may represent a connection to the Internet. In the illustrated example, at least a portion of the network 148 includes a portion of a cellular or mobile data network or other network capable of relaying SMS messages. In some instances, a portion of the network 148 may be a virtual private network (VPN). Further, all or a portion of the network 148 can include either a wireline or wireless link. Example wireless links may include 802.11/b/g/n, 802.20, WiMax®, and/or any other appropriate wireless link. In other words, the network 148 encompasses any internal or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components inside and outside the illustrated environment 100. The network 148 may communicate with, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. The network 148 may also include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the Internet, and/or any other communication system or systems at one or more locations.
As used in this present disclosure, the term “computer” is intended to encompass any suitable processing device. For example, although
Regardless of the particular implementation, “software” may include computer-readable instructions, firmware, wired or programmed hardware, or any combination thereof on a tangible and non-transitory medium operable when executed to perform at least the processes and operations described herein. Indeed, each software component may be fully or partially written or described in any appropriate computer language including C, C++, Java®, Visual Basic®, assembler, Perl®, any suitable version of 4GL, as well as others. It will be understood that while portions of the software illustrated in
The business process model 200 can have a sequence flow starting at the process start 210 where the business process is initiated, for example, executing a business application. The process start 210 can be followed with human activities/interaction 224, and/or automated activities 222. For example, in a business process, human users (e.g., such as the client 175 in
Based on the correlation condition defined at the intermediate message event, the system can identify the correlation attributes that are relevant for correlation. For example, the attributes of a process instance can include:
The attributes of a web service message can include:
Besides the position, the type and the value, the correlation condition may also include the information on how the individual conditions are logically combined (in this example with a logical “AND”). The requirement for a valid correlation may include a match between the process and web service message in terms of attribute values, type and position, as well as individual conditions to be evaluated to be true for fulfilling the correlation condition for this intermediate message event. In the given example above, cor0 AND cor1 are required to be evaluated to be true.
This logical combination can also be reflected in the fingerprint of the process instance and the web service message. Individual conditions combined with a logical AND can therefore be serialized into one fingerprint. For each process instance started for this process definition the following serialized format can be generated (i.e., in this example, cor<position> is replaced with <position>, abc and 123 are example values of the attributes in the process context):
In this example, calculating a fingerprint hash value over this string of the process context leads to a 32-digit value, as follows:
Hash: 12345678901234567890123456789012
The calculation for the fingerprint hash of the web service message generates a value of the same length (32-digit). If a message is received at the endpoint 230 that the process instance is listening to, the system of the process model 200 can check whether the correlation condition is true by comparing the fingerprints or fingerprint hashes of the process context and the message. The fingerprints and fingerprint hashes are comparable because they are calculated using the same algorithm. For example:
In this example, because the position, type and value of the correlation attributes are equal for both the process context and the web service message context, both fingerprints are equal and the web service message can be correlated with the process instance.
The following describes another example where correlation conditions are not valid due to different fingerprint hash values. The process context and web service message can be the same as the previous example:
The attributes of a process instance can include:
The attributes of a web service message can include:
Logical combination:
cor0 AND cor1
Web Service Message (note the different value)<
In this second example, because the value of attributeA in the web service message is not the same as in the process context, the fingerprint hash is different and no correlation is happening.
A third example that does not correlate because of a different attribute type can be as follows:
In this third example, because the type of attributeA in the web service message is different from the one in the process context, the fingerprint hash is different and no correlation is happening.
Turning now to
IME 1
numeric-equals(messageContext/attributeA, processContext/attributeA)
IME 2
numeric-equals(messageContext/attributeB, processContext/attributeB)
Similar to the previous examples, attributes of the incoming message can be described as:
Process Instance
Web Service Message
In this example the correlation conditions used in this process definition are logically combined with an “OR” which means that a message should be correlated with the intermediate message event when one of these correlation conditions evaluate to true. The generation of the fingerprints can therefore be different from in the examples before. For each correlation conditions disjoined by a logical OR, a fingerprint hash can be generated, for example:
Process Instance
Intermediate Message Event “Corr. attributeA”
Intermediate Message Event “Corr. attributeB”
If a message with attributeB=123 is received, it can be matched with the intermediate message event “Corr. attributeB”, not with the intermediate message event “Con. attributeA”. Because the position is considered for calculating the hash, it can ensure that “Con. attributeA” does not correlate even though it has same value and type. For example:
Web Service Message
In some implementations, if both correlation conditions refer to the same correlation attribute (e.g. cor0) then the position attribute would be identical and the hash would be the same. This basically means that both conditions would be able to consume the message, but only the one that is reached first in the process flow will actually consume it. A further example is described in
At 330, a message context fingerprint is generated. The fingerprint can include at least one identified attribute of the incoming message. The message context fingerprint can be placed into a uniform and predetermined format or structure. In some implementations, the fingerprint can include values and positions of the attributes. At 340, a hash algorithm can be applied to the message context fingerprint to create a message context fingerprint hash. The message fingerprint hash can uniquely associate with at least one identified attribute of the message. In general, any suitable hashing algorithm may be used to calculate the fingerprint hash. The same hashing algorithm is used to calculate the fingerprint hash of the process context using the relevant attributes as defined in the process context of the business process instance.
At 350, the message context fingerprint hash is compared with the process instance fingerprint hash that is calculated using the same hash algorithm. In some instances, the process context fingerprint hashes associated with a particular business process instance may be stored in a relational database, such as the fingerprint hash 117 of
At 550, the generated process context fingerprint hash is provided to a hash store, such as the fingerprint hash 117 of memory 112 in
The preceding figures and accompanying description illustrate example processes and computer implementable techniques. But environment 100 (or its software or other components) contemplates using, implementing, or executing any suitable technique for performing these and other tasks. It will be understood that these processes are for illustration purposes only and that the described or similar techniques may be performed at any appropriate time, including concurrently, individually, or in combination. In addition, many of the steps in these processes may take place simultaneously, concurrently, and/or in different order than as shown. Moreover, environment 100 may use processes with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate.
In other words, although this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.
