US-12619930-B2 - System and method for persisting data generated in executing a process workflow

Abstract

A system and method are provided for persisting data generated in executing a process workflow. The method is executed by a device having a communications module and includes receiving via the communications module messages exchanged in executing the process workflow by a message broker. The method also includes using a writer service to disassemble each received message into multiple properties according to a database schema and persist the received message in a database according to the database schema via the communications module. The method also includes using a reader service to access the database and assemble the multiple properties of a first persisted message, in response to a read request received via the communications module, wherein the reader service is separate from the writer service.

Inventors

• Joseph Vincent Scarfutti
• Christian Caberoy DE LA PEÑA
• Aneesha Suresh Bulchandani

Assignees

• THE TORONTO-DOMINION BANK

Dates

Publication Date

20260505

Application Date

20230810

Claims (20)

1. 1 . A system for persisting data generated in executing a process workflow, the system comprising: a processor; a database coupled to the processor; and a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the processor to: provide a message broker coupled to a routing service and to an integration service, wherein the routing service is used to perform dynamic routing on documents in the process workflow, and wherein the integration service is used to integrate external microservices used in executing the process workflow; receive at a state service coupled to the message broker a message exchanged in executing the process workflow; use the state service to disassemble the received message into a plurality of properties according to a database schema; persist the received message in the database according to the database schema; and in response to a read request, use the state service to access the database and assemble the plurality of properties of the persisted message, wherein the database schema uses the following set of logical entities to describe and capture information in the message: an object; a unique name identifying a category of objects; at least one property corresponding to a characteristic of the object; and a state of the object in observation, created when the object acquires information.
2. 2 . The system of claim 1 , wherein the received message is disassembled by a writer service that is different from a reader service used to reply to the read request.
3. 3 . The system of claim 1 , wherein the message broker is stateless.
4. 4 . The system of claim 1 , wherein the computer executable instructions further cause the processor to: receive a temporal query for the persisted message comprising an as-of time; and assemble the persisted message according to the plurality of properties of that message at the as-of time.
5. 5 . The system of claim 4 , wherein the as-of time corresponds to a given point in a graph defining the process workflow.
6. 6 . The system of claim 1 , wherein the received message is provided by the routing service.
7. 7 . The system of claim 1 , wherein the received message is provided by the integration service.
8. 8 . The system of claim 1 , wherein the database schema adheres to a data dictionary defining the schema for a record in the database.
9. 9 . The system of claim 1 , wherein the computer executable instructions further cause the processor to: enable different instances of a same category of objects to have different runtime properties.
10. 10 . The system of claim 2 , wherein the separate reader and writer services enable targeted scaling to permit differing read and write workloads.
11. 11 . The system of claim 1 , wherein the computer executable instructions further cause the processor to: serialize write requests through the message broker without losing data.
12. 12 . The system of claim 1 , wherein the database stores historized views of the logical entities to provide counterparts of each logical entity as of different points in time.
13. 13 . A method of persisting data generated in executing a process workflow, the method comprising: providing a message broker coupled to a routing service and to an integration service, wherein the routing service is used to perform dynamic routing on documents in the process workflow, and wherein the integration service is used to integrate external microservices used in executing the process workflow; receiving at a state service coupled to the message broker a message exchanged in executing the process workflow; using the state service to disassemble the received message into a plurality of properties according to a database schema; persisting the received message in a database according to the database schema; and in response to a read request, using the state service to access the database and assemble the plurality of properties of the persisted message, wherein the database schema uses the following set of logical entities to describe and capture information in the message: an object; a unique name identifying a category of objects; at least one property corresponding to a characteristic of the object; and a state of the object in observation, created when the object acquires information.
14. 14 . The method of claim 13 , wherein the received message is disassembled by a writer service that is different from a reader service used to reply to the read request.
15. 15 . The method of claim 13 , wherein the message broker is stateless.
16. 16 . The method of claim 13 , further comprising: receiving a temporal query for the persisted message comprising an as-of time; and assembling the persisted message according to the plurality of properties of that message at the as-of time.
17. 17 . The method of claim 13 , wherein the database stores historized views of the logical entities to provide counterparts of each logical entity as of different points in time.
18. 18 . A non-transitory computer readable medium for persisting data generated in executing a process workflow, the computer readable medium comprising computer executable instructions for: providing a message broker coupled to a routing service and to an integration service, wherein the routing service is used to perform dynamic routing on documents in the process workflow, and wherein the integration service is used to integrate external microservices used in executing the process workflow; receiving at a state service coupled to the message broker a message exchanged in executing the process workflow; using the state service to disassemble the received message into a plurality of properties according to a database schema; persisting the received message in a database according to the database schema; and in response to a read request, using the state service to access the database and assemble the plurality of properties of the persisted message, wherein the database schema uses the following set of logical entities to describe and capture information in the message: an object; a unique name identifying a category of objects; at least one property corresponding to a characteristic of the object; and a state of the object in observation, created when the object acquires information.
19. 19 . The system of claim 1 , wherein the set of logical entities further comprises a state vector recording values assigned to a property for the state of the object.
20. 20 . The method of claim 13 , wherein the set of logical entities further comprises a state vector recording values assigned to a property for the state of the object.

Description

CROSS-REFERENCE TO RELATED APPLICATION(S) This application is a continuation of U.S. patent application Ser. No. 17/302,093 filed on Apr. 23, 2021, which is a continuation-in-part of U.S. patent application Ser. No. 17/248,060 filed on Jan. 7, 2021 (now U.S. Pat. No. 11,449,312), the entire contents of which are incorporated herein by reference. TECHNICAL FIELD The following relates generally to persisting data generated in executing process workflows. BACKGROUND As digital systems and user or process requirements for these systems become more complicated and demanding, business process management becomes more challenging and complicated to implement. It is typically found that few (if any) existing tools are capable of adapting to generic and intrinsic items normally required in these business processes. For example, a business process may require sequential checks, gates, and approvals as well as data enrichment, aggregation, and appending. These tasks can require customized programming and can increase complexities in the end product or service. Other challenges can be introduced because of document parsing, document matching, data distribution and transmission, time series analyses, and web publishing. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments will now be described with reference to the appended drawings wherein: FIG. 1 is a schematic diagram of an example computing environment. FIG. 2 is a block diagram of an example configuration of an application development environment. FIG. 3 is a block diagram of an example configuration of an enterprise system. FIG. 4 is a block diagram of an example configuration of a workflow orchestration solution for a business process platform. FIG. 5 is a block diagram of an example configuration of a business process platform deployed in a computing environment. FIG. 6 is a block diagram of an example of a technology stack for implementing the business process platform. FIG. 7 is a flow diagram illustrating the translation of a workflow graph to tasks for a routing service. FIGS. 8-20 are flow diagrams illustrating task types. FIGS. 21a and 21b are flow diagrams illustrating message flows according to subscriptions made by processes. FIG. 22 is a block diagram of an example architecture configuration for implementing a routing service. FIG. 23 is a flow diagram of a routing example using the architecture of FIG. 22. FIG. 24 is a block diagram of an example architecture configuration for implementing an integration service. FIG. 25 is a flow diagram illustrating an example of a process workflow across multiple sub-processes. FIG. 26 is an example of a user interface for selecting an external microservice to be integrated into a process workflow by an integration service. FIG. 27 illustrates a conceptual model for a database schema used to persist data by the business process platform. FIG. 28 illustrates a database schema for the conceptual model of FIG. 27. FIG. 29 illustrates the historization of the database schema of FIG. 28. FIGS. 30a-30d are examples of business process workflows. FIG. 31 is an example of a user interface for designing a business process workflow. FIG. 32 is an example of a design dashboard user interface for designing a business process workflow. FIG. 33 is an example of a document communication dashboard user interface for defining communication configurations for communications integrated into a business process workflow. FIG. 34 is a flow diagram of an example of computer executable instructions for executing a process workflow. FIG. 35 is a flow diagram of an example of computer executable instructions for designing a business process workflow. FIG. 36 is a flow diagram of an example of computer executable instructions for executing a dynamic routing service. FIG. 37 is a flow diagram of an example of computer executable instructions for integrating external services into a process workflow environment. FIG. 38 is a flow diagram of an example of computer executable instructions for persisting data generated in executing in a process workflow. DETAILED DESCRIPTION It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the example embodiments described herein. However, it will be understood by those of ordinary skill in the art that the example embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the example embodiments described herein. Also, the description is not to be considered as limiting the scope of the example embodiments described herein. It is found that many items in a business process can be generic and intrinsic to several processes and appli