Claims:
1. A system for executing a process, the system comprising:
a processor;
a memory coupled to the processor for executing a plurality of modules present in the memory, the plurality of modules comprising:
an executor module configured to select at least a process instance (PI) executor module for execution of at least one process instance (PI) depending on the type of process definition (PD);
the process instance (PI) executor module configured to execute the process instance (PI) for the process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction;
a trace data generator module configured to generate at least an activity trace data for the activity associated with the process definition (PD) executed;
a batch tracer module configured to:
collect the activity trace data generated;
commit, on detection of at least a batch traces size threshold, the activity trace data as at least a batch in at least a process repository; and
initiate, on detection of the activity execution completion, the transaction associated with the process instance (PI), and thereby update the process repository with at least data associated with the process instance (PI).

2. The system as claimed in claim 1, wherein the transaction is at least a success/commit or failure/rollback.

3. The system as claimed in claim 1, wherein the process instance (PI) executor module is further configured to invoke at least create and start process instance.

4. The system as claimed in claim 1, wherein the process instance (PI) executor module is further configured to inserting at least a start state on execution of the process instance (PI) into the process repository.

5. The system as claimed in claim 1, wherein the activity trace data comprises at least the details about the activity selected from a start time or an end time or an activity status or any combination thereof.

6. The system as claimed in claim 1, wherein the batch traces size threshold is at least a timeout or a maximum activity trace count reached or any combination thereof.

7. The system as claimed in claim 1, wherein the batch tracer module is further configured to halt at least one thread associated with the process instance execution.

8. The system as claimed in claim 1 and 7, wherein the batch tracer module is further configured to notify, upon commit, the thread halted to reinitiate the process instance execution.

9. The system as claimed in claim 1, wherein the batch tracer module is further configured to insert at least an end/complete state on execution of the process instance (PI) into the process repository.

10. The system as claimed in claim 1, wherein the data associated with the process instance (PI) updated in the process repository is selected from at least a variable or an activity trace or human task data or comments (associated with PI and Task level) or a state of the PI or a current activity of the PI or a join/split information or any combination thereof.

11. The system as claimed in claim 1, wherein the batch tracer module is further configured to collect the activity trace data generated across multiple PI’s concurrently executing.

12. The system as claimed in claim 1, wherein the process definition (PD) is managed preferably by a business process management (BPM) platform.

13. A method for executing a process, the method comprising:
executing at least one process instance (PI) for at least one process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction;
generating at least an activity trace data for the activity associated with the process definition (PD) executed;
collecting the activity trace data generated;
committing, on detecting at least a batch traces size threshold, the activity trace data as at least a batch in at least a process repository;
initiating, on detecting the activity execution completion, the transaction associated with the process instance (PI), and thereby updating the process repository with at least data associated with the process instance (PI).

14. The method as claimed in claim 13, wherein the transaction is at least a success/commit or failure/rollback.

15. The method as claimed in claim 13, wherein executing further comprises: invoking at least create and start process instance.

16. The method as claimed in claim 13, wherein executing further comprises: inserting at least a start state on execution of the process instance (PI) into the process repository.

17. The method as claimed in claim 13, wherein the activity trace data comprises at least the details about the activity selected from a start time or an end time or an activity status or any combination thereof.

18. The method as claimed in claim 13, wherein the batch traces size threshold is at least a timeout or a maximum activity trace count reached or any combination thereof.

19. The method as claimed in claim 13, wherein collecting further comprises: halting at least one thread associated with the process instance execution.

20. The method as claimed in claim 13 and 19, wherein committing further comprises: notifying the thread halted to reinitiate the process instance execution.

21. The method as claimed in claim 13, wherein updating further comprises: inserting at least an end/complete state on execution of the process instance (PI) into the process repository.

22. The method as claimed in claim 13, wherein the data associated with the process instance (PI) updated in the process repository is selected from at least a variable or an activity trace or human task data or comments (associated with PI and Task level) or a state of the PI or a current activity of the PI or a join/split information or any combination thereof

23. The method as claimed in claim 13, wherein collecting further comprises: collecting the activity trace data generated across multiple PI’s concurrently executing.

24. The method as claimed in claim 13, wherein the process definition (PD) is managed preferably by a business process management (BPM) platform.

25. An apparatus for executing a process, preferably a business process, the apparatus comprising a processor to fetch at least one instruction pre-stored in a memory and configured to:
execute at least one process instance (PI) for at least one process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction, the transaction is at least a success/commit or failure/rollback;
collect the activity trace data generated on execution of the process instance (PI), the activity selected from a start time or an end time or an activity status or any combination thereof;
commit, on detection of a batch traces size threshold selected from at least a timeout or a maximum activity trace count reached, the activity trace data as at least a batch in at least a process repository; and
initiate, on detection of the activity execution completion, the transaction associated with the process instance (PI), and thereby update the process repository with at least data associated with the process instance (PI).
, Description:
TECHNICAL FIELD

The present subject matter described herein, in general, relates to process execution, and more particularly, to systems, methods, and apparatuses for increasing the efficiency of processing of information with minimal dependency on database.

BACKGROUND

Business process management (BPM) is a field in operations management that focuses on improving corporate performance by managing and optimizing a company's business processes. It can therefore be described as a “process optimization process”. BPM places a significant emphasis on business processes within the enterprise both in terms of streamlining process logic to improve efficiency and also to establish processes that are adaptable and extensible so that they can be augmented in response to business change. The business process layer represents a core part of any service-oriented architecture. From a composition perspective, it usually assumes the role of the parent service composition controller.

Business processes are visually modeled using modeling tools and are represented in XML files (also referred to as process) complying with Business Process Model and Notation (BPMN) 2.0 schema. When the processes (XML files) are deployed into BPM, they are stored as Process Definitions (PDs) into database, and are managed by the BPM. The Process Definitions and a set of configuration data are considered as static data, which does not grow or does not get modified very frequently at runtime. Process Instances (PIs) are created and orchestrated following the process definitions as the blue-prints. When process instances are created and started, BPM inserts data corresponding to the process instances and associated process inputs/variables and other related data into database. While the process instances are executed, their state data, execution traces, and other relevant runtime data are also persisted or updated into DB. However, with some applications, the number of process instances created and executed is huge such that BPM will have to interact with database too frequently, thus this frequent database interaction pose as a performance bottleneck.

BPM currently supports defining two kinds of process definitions with respect to the degree of persistence required for the runtime data associated with the PIs i.e., Normal Process Definition and Microflow Process Definition. The PD is referred to as normal process definition when the BPM persists the data when the PI is created, started, and when the PI reached a WAIT_STATE, usually when the execution is suspended/terminated, or when a human task activity is encountered in the flow. Persistence also happens during the execution at points where the user has specified save points and transaction boundaries suitable for processes that need more control over transactions and guaranteed save and continue approach for executing the processes with high data reliability. The PD is referred to as microflow process definition when the, BPM does not do any persistence. The PI will be executed in volatile fashion, meaning there won’t be any trace of PI execution, and there is no way to recover/continue the PI in case the PI execution is interrupted abruptly, possibly due to unexpected system crash, power failure or some other external reasons. The microflow process definition is suitable for those processes that do not do very critical business logics and those activities that carry no harm if repeatedly executed, unlike financially critical activities such as debiting money from a subscriber bank account.

The PI’s of microflow process definition type does not insert or update any data into database (DB). It does not even store execution traces. The BPM interacts with DB only to load the PD for the first time when a PI of this type of PD is created. The entire execution of this type of PI is volatile, meaning that the data changes, state changes, and execution traces are available in-memory only when the PI is being executed. Once the PI execution is stopped, either successfully or with some failure, the data and state associated with this kind of PI are not available any more.

The PI’s of normal process definition type provides maximum data reliability by persisting the data and state (in the form of traces) at every possible step, either automatically determined by BPM engine or as determined by the user at the time of modeling the PD by specifying the save points. By default BPM will persist before starting of the process and will persist whenever any flow is completed or when a management operation such as suspend PI is called. Additionally, when a configured save-point is encountered BPM will commit the data to the DB. The traces are persisted independent of the main transaction outcome (success/commit or failure/rollback) as shown in figure 1. The figure 1 shows a sample process executed by the BPM engine involving DB persistence and commits. The traces are treated just as logs. As traces are considered as logs and the same should not be missed irrespective of whether the PI execution transaction commit or rollback, they are inserted into DB using different transaction than the main transaction every now and then when a trace is generated.

However, in some business scenario it is required to store the data for every step of execution, which causes too many DB interactions and commits thus causing performance overhead. Microflow type of PD cannot be used in these business scenarios as the persistence of the data is critical. Trace of the execution also required to be saved for each PI as the execution traces are very critical for the business. The microflow PD, though it provides maximum performance, cannot be used in cases where the abruptly terminated PIs are expected to be recovered and continued without re-executing already completed activities. So, this kind of PD cannot fully meet the requirement in hand. Just to prevent already completed activities of a PI from re-executing, and to be able to recover the abruptly terminated PIs after where it completed, the user need to specify save-points at every step. This result in more number of commits during execution, which reduces the performance. Every time PI data is inserted to or updated in the DB, the ongoing transaction is committed and a new transaction is started for the next step to be executed, which increase the DB overhead. As the trace records are written independent of outcomes of the main transaction, using which the process execution takes place, the trace records are inserted into DB with each of their own transactions, and hence too many transactions creation and completion overhead and too frequent commits overhead to DB. Also, as the commits happen frequently, the amount of data that can be batched to insert/update with one batch SQL is very less, i.e., number of records that can be collectively inserted/updated between consecutive commit points are very less, hence cannot take advantage of batch SQL operations to have improved performance.

SUMMARY

This summary is provided to introduce concepts related to system, method and apparatus for process execution with minimal dependency on database, and the same are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

A main objective of the present invention is to solve the technical problem as recited above by providing system, method and apparatus for process execution with minimal dependency on database.

Another objective of the present invention is to provide a system, method and apparatus to reduce the DB interactions and commit requests without losing the data and still provide a highly reliable process execution capability that the abruptly terminated PIs can be recovered and continued without re-executing already executed activity again.

Another objective of the present invention is to provide a system, method and apparatus which provide the batch Structured Query Language (SQL) capability and thereby reduce the number of the DB interactions and commits, possibly batch the records across PIs to gain maximum resource utilization.

Another objective of the present invention is to provide a system, method and apparatus for executing a special type of PD (Microflow+) which will perform less DB commits.

Another objective of the present invention is to provide a system, method and apparatus to batch the trace records that are generated across PIs that execute concurrently and commit them with one transaction.

Another objective of the present invention is to provide a system, method and apparatus to enable restoring the process execution state from trace records to continue executing the PIs in the event of unexpected termination of PIs.

Another objective of the present invention is to provide a system, method and apparatus to enable batch-inserting the traces records pertaining to multiple PIs that concurrently execute and commit them using in single transaction.

Another objective of the present invention is to provide a system, method and apparatus to combine microflow and minimal persistence of non-microflow (or normal) process definition to reduce the reliance of DB and transactions.

Yet another objective of the present invention is to provide a system, method and apparatus to support for continuing the process instances based on trace records.

Still another objective of the present invention is to provide a system, method and apparatus to provide a Microflow+ type of PD that allows for minimal persistence but still support for recovering/continuing the PIs without repeating the already executed activities in case of unexpected termination of PIs is required. The Microflow+ type of PD principally does not persists data except for minimal data for ensuring that the PIs can be recovered/continued without repeating executing the previously completed activities, hence Microflow + minimal persistence.

Accordingly, in one implementation, a system for executing a process is disclosed. The system comprises a processor, and a memory coupled to the processor for executing a plurality of modules present in the memory. The plurality of modules comprises an executor module, the process instance (PI) executor module, a trace data generator module, and a batch tracer module. The executor module configured to select at least a process instance (PI) executor module for execution of at least one process instance (PI) depending on the type of process definition (PD). The process instance (PI) executor module configured to execute the process instance (PI) for the process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction. The trace data generator module configured to generate at least an activity trace data for the activity associated with the process definition (PD) executed. The batch tracer module configured to collect the activity trace data generated; commit, on detection of at least a batch traces size threshold, the activity trace data as at least a batch in at least a process repository; and initiate, on detection of the activity execution completion, the transaction associated with the process instance (PI), and thereby update the process repository with at least data associated with the process instance (PI).

In one implementation, the present invention provides a method for executing a process. The method comprises:
• executing at least one process instance (PI) for at least one process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction;
• generating at least an activity trace data for the activity associated with the process definition (PD) executed;
• collecting the activity trace data generated;
• committing, on detecting at least a batch traces size threshold, the activity trace data as at least a batch in at least a process repository;
• initiating, on detecting the activity execution completion, the transaction associated with the process instance (PI), and thereby updating the process repository with at least data associated with the process instance (PI).

In one implementation, the present invention provides an apparatus for executing a process, preferably a business process. The apparatus comprising a processor to fetch at least one instruction pre-stored in a memory. The process is configured to execute at least one process instance (PI) for at least one process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction, the transaction is at least a success/commit or failure/rollback; collect the activity trace data generated on execution of the process instance (PI), the activity selected from a start time or an end time or an activity status or any combination thereof; commit, on detection of a batch traces size threshold selected from at least a timeout or a maximum activity trace count reached, the activity trace data as at least a batch in at least a process repository; and initiate, on detection of the activity execution completion, the transaction associated with the process instance (PI), and thereby update the process repository with at least data associated with the process instance (PI).

In contrast to the prior-art techniques, available if any, the present invention provides a new “Microflow+” type of PD that allows for minimal persistence but still support for recovering/continuing the PIs without repeating the already executed activities in case of unexpected termination of PIs is required. The Microflow+ PD principally does not persists data except for minimal data for ensuring that the PIs can be recovered/continued without repeating executing the previously completed activities, hence Microflow + minimal persistence. Further, the present invention enables to improve the application performance without losing the ability to recover and continue the PI execution without re-executing already completed activities.

The Microflow+ PD combines the microflow and minimal persistence of non-microflow (or normal) process definition to reduce the reliance of DB and transactions. The present invention also enables batch-inserting the traces records pertaining to multiple PIs that concurrently execute and commit them using in single transaction. Further, the present invention also enables to restore the process execution state from trace records to continue executing the PIs in the event of unexpected termination of PIs.

Further, the present invention enables the batch Structured Query Language (SQL) capability i.e., when executing the SQL, instead of executing one by one individually, SQLs of same table insert/update operations are collected and they are executed with a single batch SQL. Conventionally, for each activity trace one insert at a time was performed, whereas according to the present invention, for multiple activity traces that happen simultaneously, multiple insert operations are batched (collected together) and executed with single SQL, and thereby reduces the number of the DB interactions and commits, possibly batch the records across PIs to gain maximum resource utilization

The various options and preferred embodiments referred to above in relation to the first implementation are also applicable in relation to the other implementations.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.

Figure 1 illustrates a sample process executed by the BPM engine involving DB persistence and commits as implemented in the prior-art.

Figure 2 illustrates PI execution as per the prior art, where BPM engine persists and commits the data into the DB very frequently.

Figure 3 illustrates a PI execution as per the new Microflow+ PD, in accordance with an embodiment of the present subject matter.

Figure 4 illustrates a comparison of conventional PI trace generation and the PI trace generation in batch mode in accordance with an embodiment of the present subject matter.

Figure 5 illustrates the flow sequence of a conventional PI execution as available in the prior-art.

Figure 6 illustrates the PI execution in batch mode in accordance with an embodiment of the present subject matter.

Figure 7 illustrates a flow sequence for executing a process, in accordance with an embodiment of the present subject matter.
Figure 8 illustrates a recovering process from trace table, in accordance with an embodiment of the present subject matter.

Figure 9 illustrates a flow sequence of execution for recovering process from trace table, in accordance with an embodiment of the present subject matter.

Figure 10 illustrates system for executing a process, in accordance with an embodiment of the present subject matter.

Figure 11 illustrates a method for executing a process, in accordance with an embodiment of the present subject matter.

It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and may not be to scale.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

The following clearly describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are merely a part rather than all of the embodiments of the present invention. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

The invention can be implemented in numerous ways, as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

System, method and apparatus for process execution with minimal dependency on database are disclosed.

While aspects are described for system, method and apparatus for process execution with minimal dependency on database, the present invention may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary systems, apparatus, and methods.

In one implementation, the present invention provides a new type of PD referred to as “Microflow +” that allows for minimal persistence but still support for recovering/continuing the PIs without repeating the already executed activities in case of unexpected termination of PIs is required. This type of PD is named as Microflow+ as this principally does not persists data except for minimal data for ensuring that the PIs can be recovered/continued without repeating executing the previously completed activities, hence Microflow + minimal persistence.

In one implementation, the present invention comprises an executor server responsible for providing service and selecting the appropriate executor depending on the type of process definition (PD), a PI executor responsible for executing the process as per the type and will take care of persisting the required information, an activity executor responsible for executing the activity and persist the trace information about the activity, a batch tracer responsible to collecting and optimizing the batch insertions of the trace data, and a trace repository responsible to updating the trace data to database.

Referring now to figure 2, a PI execution as per the prior art, where BPM engine persists and commits the data into the DB very frequently with an embodiment of the present subject matter is illustrated. As shown in the figure 2, the convention techniques commits the data very frequently, preferably after completion of each PI, this increases the overall cost of the operation as well as the database.

Referring now to figure 3, a PI execution as per the new Microflow+ PD in accordance with an embodiment of the present subject matter is illustrated. As shown in figure 3, the PI data is inserted or updated once when the PI is created (using createProcessInstance or createAndStartProcessInstance API in one step) or started (using startProcessInstance API after having it created in another step) respectively. With the insert or update, the transaction is committed. From then on, the PI is executed just like how a Microflow process would be executed, there is no transaction held while executing the rest of the process flow until the process reaches the end of the flow (end event). Further as shown in figure 3, when the execution reaches the end of the flow, only then the PI data and state are persisted and committed using another transaction.

Considering the example as shown in figure 1, when a PI executing as per the PD, and suppose the PI execution is stopped after the step “Collect CDR Data” in which CDR data already analyzed. When the server is restarted, In contrast with the conventional techniques available in the prior-art, the CDR Data analysis step will not be executed again for this PI. Instead the execution will continue from the “Raw Total” step with the previously analyzed/calculated data.

In one implementation, when PIs of Microflow+ type PD are created and executed, the BPM engine limits the DB interactions and commits. For Microflow+ PIs, the traces are inserted using a Batch trace handler that collects the traces across multiple PIs that concurrently executing and will be discussed in the proceeding sections. With Microflow+ PIs, the abruptly interrupted PIs are continued executing based on trace records available in the DB, and the PI data is inserted or updated once when the PI is created (using createProcessInstance or createAndStartProcessInstance API in one step) or started (using startProcessInstance API after having it created in another step) respectively. With the insert or update, the transaction is committed. From then on, the PI is executed just like how a Microflow process would be executed, there is no transaction held while executing the rest of the process flow until the process reaches the end of the flow.

When the execution reaches the end of the flow, then the PI data and state are persisted and committed using another transaction. After the PI execution is started and before completing the execution at the end of the process flow, the PI is executed exactly following the Microflow principle that there is no interaction with the DB as long as the process executes positively without any errors. If the PI encounters any error, then the PI execution fall back to execute following Normal PD. The PI execution will fall back to Normal PD mode also in the event of encountering an activity/step that needs the PI to transit to WAIT_STATE or in the event of management operations such as suspend PI are invoked. Other than these special cases, viz., a) execution encountering error, b) execution encountering an activity that requires the PI to transit to WAIT_STATE, c) management operations invoked, which are less likely to happen and may happen with less number of PIs when considering the huge number of PIs executed, for the most time the PIs are executed successfully without requiring to persist data to DB. So, this way of executing the PIs helps to reduce the interactions and commit requests to DB.

In one implementation, each PD is identified using the extension “processExecutionMode” which is specified in the process attribute like below:

Attribute on the process to specify the execution mode of process

In one implementation, a runtime engine will use this information to determine in what mode the PIs should be executed. When the PI is stopped before completion, based on the trace data BPM will resume the execution of the process. So the trace data persistence has to be done for every activity.

Referring now to figure 4, a comparison of conventional PI trace generation and the PI trace generation in batch mode in accordance with an embodiment of the present subject matter is illustrated. Figure 5 illustrates a flow sequence of a conventional PI execution as available in the prior-art is illustrated and figure 6 illustrates the PI execution in batch mode in accordance with an embodiment of the present subject matter.

As shown in the figure 4, when a PI is execution, the trace data is required for reliability. BPM engine is doing the trace commit with batches that are created across PI executions. As shown in figure 4, in the conventional PI executions, the batch operations will happen in the same transaction (also shown in figure 5). However, in contrast with the conventional process (also shown in figure 5), the present invention (as shown in figure 6) creates a batch of the trace entity across the PI which will be committed using different transaction. The BPM also handles the scenario where without performing the commit of trace entity process cannot execute the next activity.

In one implementation, when the PIs are executing concurrently, according to the present invention, the commit data of each PI is added to the batch trace module, which makes the PI to wait (thread wait) and performs the batch commit. Once the commit operation is completed, batch trace signals the threads to continue the execution to next activity. Further, to make the batch effective, according to the present invention, the batch trace waits for the minimum number of entries or minimum timeout that is configured by the application.

The above scenario is explained with an example as provided below: If 3 PIs are executing, in 3 different threads, (PI1 is executing in Thread1, PI2 is executing in Thread2 and PI3 is executing in Thread3), and when one activity is completed in PI1 and PI3, they both will generate the trace data that has to be written to the DB. This data will be sent to the batch tracing module. The batch trace module will be paused the threads, Thread1 and Thread3. The batch trace will commit the collected data using its own thread which will be using different transaction. Once the commit has completed successfully, it will notify the threads Thread1 and Thread3 to continue to the next activity execution.

By the implementation of the present invention, the number of database commits will be less and optimal, and the batching happens across PI, which enables optimal usage of resources.

Referring now to figure 7, a flow sequence for executing a process, in accordance with an embodiment of the present subject matter is illustrated. In one implementation a step wise a step-wise execution of the present invention whose flow sequence for executing the process as shown in figure 7 is provided below:
• Step 1: The users create a process instance (PI) for Microflow+ type of Process Definition (PD). In this step the user invokes create and start process instance (createAndStartProcessInstance) API for creating and start executing the PI.
• Step 2: The PI is inserted to the DB with PI State marked as STARTING state. In this step the data associated with the PI is inserted to the DB for reliability.
• Step 3: The PI starts the execution without transaction. As per the conventional techniques, the PI is executed with a transaction which brings additional overhead; however, in the present invention execution with a transaction is avoided for Microflow+ type of PD.
• Step 4: The first activity of the process is executed (business logic associated with the first activity is executed)
• Step 5: The activity trace entity about this activity is generated. In this step, the activity execution is completed and the details about the activity like, start time, end time, activity status etc. will be added to the entity object.
• Step 6: Add this activity trace to batch trace module. In this step, the activity entity generated will be given to the batch trace module.
• Step 7: The batch trace module collects this activity trace entity and makes the thread to wait. In this step, the batch trace module will collect the trace entity and make the process executing thread to wait.
• Step 8: When batch traces size threshold reaches in batch trace module, it commits the traces in batches. In this step, batch trace module will keep checking the threshold (either timeout or max activity trace count reached) and will insert all the trace entities data as a batch to DB.
• Step 9: Notifies the executing thread to continue to next activity. In this step, the batch trace module will send the notification to the halted threads to complete or initiate their execution.
• Step 10: Repeat step 4 to 9 for each activity in the PI.
• Step 11: Start the transaction and update the PI status as COMPLETED in the database. In this step, the final status of the process is updated in the database. This step will start the transaction to persist all the process related data like variable etc. to the DB.

In one implementation, since the process instance (PI) is persisted during start of the PI and at the end, the trace information for recovering the PI may be easily used during recovery.

Referring now to figure 8 a recovering process from trace table, in accordance with an embodiment of the present subject matter is illustrated. Figure 8 shows the process execution could get interrupted abruptly after executing a certain step and how the execution could be recovered from after where it was interrupted” is provided. In one implementation, when the process is executing, if the process has failed (might be because of any external resource factor or abnormal halt of the system) BPM can execute the remaining of the PI. That is the completed nodes will not be executed again. This is achieved by using the trace data stored in the DB according to the present invention. For example, if the PD as shown in figure 9 is considered, if after the “raw total” task is completed and when applying discount, there was a failure in the system and if the system is rebooted, this process will continue the execution from apply discount task. According to the present indentation, the before steps as those are already completed are not performed again. When executing the PI, the trace data is persisted in different transaction. This provides the reliability, so that when BPM is trying to recover the PI based on the trace data, it identifies which nodes are completed and based on that information, the PI is reloaded to memory and execution is recovered from that point. A flow sequence of execution for recovering process from trace table, in accordance with an embodiment of the present subject matter is illustrated in figure 9.

Further, in continuance with reference to the example as shown in figure 9 which uses to collect the CDR data in one activity, and performs the raw total in next step and then it applies the discount in another activity. In order to understand the present invention, Let us consider, there are 2 such process is created at the same time for execution (PI_1 and PI_2) in two different threads. According to the present invention, for each process execution, once the process is created one save for each PI will happen to DB. Each PI will execute “Collect CDR data” in two threads say T1 and T2. Once this activity for PI_1 which is executing in T1, it will add one activity trace entity to the batch tracer. When this is added, batch tracer will make the thread to wait (That is T1 will be waiting for the entity to be persisted to DB). In the same way when PI_2 which is executing in T2 will also add the entry to the batch trace module and will wait for the entity to be persisted to DB.

Once the threshold is reached in the batch tracer, the collected trace entity data for “Collect CDR Data” will be inserted into the DB in as a batch insert. Suppose if we had configured the batch trace module to batch 100 traces or whatever number of traces given to it within 50 milliseconds, then if there were more than 100 threads assigned their activity traces to the batch trace module, then it would have batch inserted 100 traces using one SQL. Or if there were lesser number of traces assigned to the batch trace modules within 50 milliseconds, then the batch trace module would batch insert whatever number of traces it received by 50 millisecond time using one SQL. After this insertion, batch tracer will notify the threads T1 and T2 to continue the execution, which in-turn will proceed to the next activity execution (That is “Raw Total”). This will continue for all the activity in the process.

In conventional techniques, in normal flow of execution each activity execution will happen in the same thread and will not be batched. In contrast with the convention technique, considering the above example, for executing two PI concurrently by two different threads, the number of interactions to the DB for trace would be 6. (For each activity one insert, so for one PI it is 3, and for two PI it is 6). Also, in batch insert case, the number of activity insert will be 6 (Each activity will be batched and hence the number of interactions will be less). Also, in real time case, if the concurrency is more, then the number of interactions with the DB will be less in the new way of implementation.

Thus, a person skilled in the art after reading the above may clearly understand at least the below mentioned technical advantages achieved by the present invention as:
• Each thread need not perform DB operation (all the DB operations are performed by Batch tracer).
• DB operation is batched which saves the network overhead.
• Reliability is ensured, by making the process to wait in-memory (process is continues only after the successful insertion of the data).
• Transaction overhead for executing the process is reduced.

Referring now to figure 10, a system for executing a process, in accordance with an embodiment of the present subject matter is illustrated. Although the present subject matter is explained considering that the present invention is implemented as a system 1100, it may be understood that the a system 1100 may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. It will be understood that the system 1100 may be accessed by multiple users, or applications residing on the system 1100. Examples of the system 1100 may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, sensors, routers, gateways and a workstation. The system 1100 is communicatively coupled to other devices or a nodes or apparatuses to form a network (not shown).

In one implementation, the network (not shown) may be a wireless network, a wired network or a combination thereof. The network can be implemented as one of the different types of networks, such as GSM, CDMA, LTE, UMTS, intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.

The system 1100 as illustrated in accordance with an embodiment of the present subject matter may include a processor 1102, an interface 1104, and a memory1106. The at least one processor 1102 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor is configured to fetch and execute computer-readable instructions or modules stored in the memory.

The interface (I/O interface) 1104 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface may allow system 1100 to interact with a user directly. Further, the I/O interface may enable the system 1100 to communicate with other devices or nodes, computing devices, such as web servers and external data servers (not shown). The I/O interface can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, GSM, CDMA, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface may include one or more ports for connecting a number of devices to one another or to another server. The I/O interface may provide interaction between the user and the system 1100 via, a screen provided for the interface.

The memory 1106 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory may include plurality of instructions or modules or applications to perform various functionalities. The memory includes routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types.

In one implementation, the present invention provides a system 1100 for executing a process is disclosed. The system 1100 comprises a processor 1102, and a memory 1106 coupled to the processor 1102 for executing a plurality of modules present in the memory 1006. The plurality of modules comprises an executor module 1108, the process instance (PI) executor module 1110, a trace data generator module 1112, and a batch tracer module 1114. The executor module 1108 is configured to select at least a process instance (PI) executor module 1110 for execution of at least one process instance (PI) depending on the type of process definition (PD). The process instance (PI) executor module 1110 is configured to execute the process instance (PI) for the process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction. The trace data generator module 1112 is configured to generate at least an activity trace data for the activity associated with the process definition (PD) executed. The batch tracer module 1114 is configured to collect the activity trace data generated; commit, on detection of at least a batch traces size threshold, the activity trace data as at least a batch in at least a process repository; and initiate, on detection of the activity execution completion, the transaction associated with the process instance (PI), and thereby update the process repository with at least data associated with the process instance (PI).

In one implementation, an apparatus for executing a process, preferably a business process is disclosed. The apparatus comprising a processor 1102 to fetch at least one instruction pre-stored in a memory 1106 and configured to execute at least one process instance (PI) for at least one process definition (PD), wherein the process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction, the transaction is at least a success/commit or failure/rollback; collect the activity trace data generated on execution of the process instance (PI), the activity selected from a start time or an end time or an activity status or any combination thereof; commit, on detection of a batch traces size threshold selected from at least a timeout or a maximum activity trace count reached, the activity trace data as at least a batch in at least a process repository; and initiate, on detection of the activity execution completion, the transaction associated with the process instance (PI), and thereby update the process repository with at least data associated with the process instance (PI).

In one implementation, the transaction is at least a success/commit or failure/rollback.

In one implementation, the process instance (PI) executor module is further configured to invoke at least create and start process instance.

In one implementation, the process instance (PI) executor module is further configured to inserting at least a start state on execution of the process instance (PI) into the process repository.

In one implementation, the activity trace data comprises at least the details about the activity selected from a start time or an end time or an activity status or any combination thereof.

In one implementation, the batch traces size threshold is at least a timeout or a maximum activity trace count reached or any combination thereof.

In one implementation, the batch tracer module is further configured to halt at least one thread associated with the process instance execution.

In one implementation, the batch tracer module is further configured to notify, upon commit, the thread halted to reinitiate the process instance execution.

In one implementation, the batch tracer module is further configured to insert at least an end/complete state on execution of the process instance (PI) into the process repository.

In one implementation, the batch tracer module is further configured to collect the activity trace data generated across multiple PI’s concurrently executing.

In one implementation, the process definition (PD) is managed preferably by a business process management (BPM) platform.

Figure 11 illustrates method for executing a process, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

The order in which the method is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method or alternate methods. Additionally, individual blocks may be deleted from the method without departing from the protection scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be considered to be implemented in the above described system 1100 or an apparatus.

At block 1202, at least one process instance (PI) for at least one process definition (PD) is executed. The process instance is executed, per activity associated with the process definition (PD), and without initiating any transaction. The transaction may be at least a success/commit or failure/rollback. A create and start process instance are also invoked in this step. A start state on execution of the process instance (PI) is inserted into the process repository

At block 1204, at least an activity trace data is generated for the activity associated with the process definition (PD) executed. The activity trace data comprises at least the details about the activity selected from a start time or an end time or an activity status or any combination thereof.

At block 1206, the activity trace data generated is collected. During collection, at least one thread associated with the process instance execution is halted. Also, the activity trace data generated across multiple PI’s concurrently executing is collected.

At block 1208, upon detecting at least a batch traces size threshold, the activity trace data as at least a batch is committed in at least a process repository. The batch traces size threshold is at least a timeout or a maximum activity trace count reached or any combination thereof. The thread halted to reinitiate the process instance execution is notified.

At block 1210, upon detecting the activity execution completion, the transaction associated with the process instance (PI) is initiated.

At block 1212, the process repository with at least data associated with the process instance (PI). During updating, at least an end/complete state on execution of the process instance (PI) into the process repository. The data associated with the process instance (PI) updated in the process repository may include but not limited to variables, activity trace, human task data, comments (PI and Task level), state of the PI, current activity of the PI, join/split information, and the like.

In one implementation, the process definition (PD) is managed preferably by a business process management (BPM) platform.

The implementation of the present invention greatly improves the application performance without losing the ability to recover and continue the PI execution without re-executing already completed activities. A simple analysis to show the advancement was performed. Below mentioned is the result of the analysis:

PD Name Number of SQL Executed TPS
Before After Before After
Retry Sync Flow 54 15 260 1250
Dunning 109 9 160 1600

Apart from what is explained above, the present invention also include the below mentioned advantages or the present invention enables to achieve:
? Providing and executing a special type of PD (Microflow+) which will perform less DB commits. Number of database commits will be less and optimal.
? Batching the trace records that are generated across PIs that execute concurrently and commit them with one transaction. Batching happens across PI, which enables optimal usage of resources.
? Support for continuing the process instances based on trace records.
? The present invention combines the microflow and minimal persistence of non-Microflow (or normal) process definition to reduce the reliance of DB and transactions.
? The present invention enables batch-inserting the traces records pertaining to multiple PIs that concurrently execute and commit them using in single transaction.
? The present invention restores the process execution state from trace records to continue executing the PIs in the event of unexpected termination of PIs

A person skilled in the art may understand that any known or new algorithms by be used for the implementation of the present invention. However, it is to be noted that, the present invention provides a method to be used during back up operation to achieve the above mentioned benefits and technical advancement irrespective of using any known or new algorithms.

A person of ordinary skill in the art may be aware that in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the particular applications and design constraint conditions of the technical solution. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the present invention.

It may be clearly understood by a person skilled in the art that for the purpose of convenient and brief description, for a detailed working process of the foregoing system, apparatus, and unit, reference may be made to a corresponding process in the foregoing method embodiments, and details are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present invention essentially, or the part contributing to the prior art, or a part of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to perform all or a part of the steps of the methods described in the embodiment of the present invention. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disc.

Although implementations for system, method and apparatus for process execution with minimal dependency on database have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations of the system, method and apparatus for process execution with minimal dependency on database.