Background

The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.

A system may interact with the system’s storage (database / data warehouse, other type storage) or an external system such as servers/electronic device/etc through the application’s processes a network interface. To create / modify such a process the system owner needs to ask a computer programmer to program such a process or to use a system that support the required options or to use a system that can trigger processes based on data-manipulation (update/insert/delete), those kinds of systems (for example US11188542B2) run the process’s condition validation on every update/insert/delete which tend to waste the system resources (cpu/memory/storage) especially if one have a huge number of processes.

For example, a seller of electronics goods has a system that executes an application process which creates an order and execute an API call to a computerized warehouse robot to fetch a specific product upon purchase. Currently If the seller wants to send an email with an invoice to the customer or to create a follow-up task for the customer or to order more products from the supplier (due to the absence of the product in the warehouse), then the seller will need to hire a developer for that. The seller must wait for a computer programmer to modify the code of the specific process, compile the code, and load the code into the seller's system. This wait may be lengthy and may need to be repeated if any errors occur during this complex procedure. If the seller will

SUBSTITUTE SHEET (RULE 26) use a system like the one described in patent US11188542B2, such system will check after every order update if the “ship order” logic/code should be triggered. Just as an example, an order could be updated 10-20 times by the user/customer during the normal life-cycle of an order (adding products, changing the billing/shipping address, updating the order totals, discount, ship order, shipping order, returning an order, etc...). In other words, triggering processes based on DML operation could influence system resources and performance.

Brief Summary

In accordance with embodiments, there are provided systems and methods for conditional processing based on event execution on records with an optional conditional processing based on the execution of instructions / code that returns a clear answer such as expected/unexpected. A system stores a process-data-structure for each system process, the process-data-structure consist of an event, actions, an optional object, and an optional X-Structure. The system receives a request to perform an event for record(s). The system fetches the right process-data-structure (based on the event). The system executes the event’s implementation on the record(s) and optional X- Structure and receives a positive/negative answer (expect/unexpected answer) from the execution, the system then executes the process’s actions on the records that received a positive/expect answer for the execution.

For example, a system stores the process-data-structure received from the system’s user for a process named “ship refrigerator and send an sms to the customer", an “shiporder” event that run/extend a DBQuery Event, for the order object, an optional X- Structure in this case consist a JSON structure with a SQL statement with parameters place-holders (to be substituted with the order’s data), for example: “select count(*)' answer' from orders where status- ’paid” id in (<id>) and exists(select * from order_products where order.id=orderid and type- refrigerator’ and exists(select * from products where stock>1 and type- refrigerator and id= order_products.productid)) ”, where <id> is an example for a parameter placeholders to be replaced with the

SUBSTITUTE SHEET (RULE 26) order. id. Such a SQL statement/condition can be easily created by a user through the right Ul (as seen in the figures 2-9). Later when the event dispatcher (part of the process-system) receives a request to “ship-order”, it will trigger the “ship refrigerator and send an sms to the customer” process for the order object, then the event-executor (Figure 9) will run the implementation of the ship-order event, in our case it will run the DBQuery function on the record, the DBQuery function will plugs the data from the order record (that was updated) into the SQL (in a safe manner), and then it will run the SQL statement (with the embedded data). The process-system will receive the answer 0 in case the order has no refrigerators or a positive number if the order has a refrigerator in stock. In case the order has a refrigerator then the process-system will execute the actions that were setup under the process-data-structure. A possible action could be to send an SMS or an email to the customer about the upcoming delivery date (the sms/email will be sent through the actual action implementation based on the actionsettings) or any other actions that is supported by the system. The action executor may also execute an API call through the network interface to the warehouse to prepare the refrigerator for shipment.

Detailed Description

General Overview

Systems and methods are provided for conditional processing based on event execution on records. The following detailed description will first describe a method for conditional processing based on event execution on records. Next, frames of example user interface for conditional processing based on event execution on records are described.

FIG. 1 is an operational flow diagram illustrating a high-level overview of a method 100 for conditional processing based on event execution on records. As shown in FIG. 1 , a system may receive an execution settings “process-data-structure” submitted by a user or a system, the process-data-structure will consist of an event, a set of actions, an optional object and an optional X-Structure in 101. Later, the system receives an event in 102, made by a user or a system, the system fetches all processes (“process-data-

SUBSTITUTE SHEET (RULE 26) structure”) created for the event in 103 and execute the event’s implementation on the X-Structure and records through the event-dispatcher & executor in 104. The system will then run the actions on the records that got a positive/ expected answer form the event execution. In the following description, each of the blocks 101 -106 in the method 100 includes a general description of an execution / action taken by the system, followed by two examples for a possible implementation of method 100.

For purposes of clarity, the first example herein will be referred to as the “sending an invoice” example, the the second example will be referred to as the “updating totals. A user starts by sending the information for creating a process-data-structure in block 101 in Figure 1 . An example user interface for the process-data-structure creation is presented in Figure 2A, the actual process data structure can be implemented as a JSON/XML/other type of flexible structure. For the “sending an invoice example” the user starts in 201 by choosing the opportunity object and then opens the processes / automation manager in 202. In figure 2B, the user creates the actual process-data- structure, the user creates or chooses an update event 220, the user then set the SQL statement under 221 (this can be stored under the process’s X-Structure), in the “sending an invoice” example the user also creates 2 actions for that process (one action to send an email and another action to create a task that is to remind the user to follow up with the customer). The user action type is chosen/created under 222 and an additional condition is set under 223, an example Ul is presented in figure 4, according to the settings in figure 4, the invoice will be sent if the type field equals to “invoice” and the stage field does not equals to “closed won” and there is a contact record linked to the updated opportunity record. All the conditions are checked via the execution of a sql statement/query in this case. The add actions button (224) and the new process button (225) allows the user to add additional actions / processes. Figures 4,5 present an example user interface with a wizard for editing the SQL statement for the update/create events (DB query event implementation is assumed as the default event execution in this case), the user can choose simple (400) /advanced SQL condition (401 ) and

SUBSTITUTE SHEET (RULE 26) add/edit the SQL condition in a human friendly way through options: 403,404,405,406,407,501 ,502,503,504,505.

An example user interface for the “Updating totals” is presented in Figure 3, the user creates a new process as presented in 224,225 for the opportunity object. The user chooses the “create / update” event (a custom event), and doesn’t choose any condition for the process in 300. The user then adds an update action in 301 and chooses the opportunity object in 302, the user then chooses the expected field values in 303 i.e. the new amount SQL expression, and then set a second condition in 304 to be applied to the action’s chosen object in 302. An example Ul for 303 is presented in figures 6,7. An example Ul for 304 is presented in figure 4.

After the “Updating totals” and “sending and invoice” processes are setup and save, a user changes an opportunity record (figure 8), the user changes the discount to 2 the type field is changed to invoice and the stage field to “closed won” (fields 801 , 802, 803) and hit save. The save button triggers the “create / update” event through the event dispatcher event in figure 9. The event dispatcher (901 ) calls block 102 in figure 1 . Block 103 fetches the relevant process that relevant for the “create I update” event. Block 104 then execute the implementation of the “create I update” for the “Updating totals” process (the DB query function) and receives a positive answer for of the “Updating totals” process. Block 105 then execute the actions defined in figure 3, that is the action executor in figure 9 (902) runs the implementation of the following of the “update record” action for the update oppty total sum action.

Once the last execution is done, the user clicks the generate invoice button which trigger the ship-order event (this could be defined under the button’s settings or in another place), the event dispatcher (901 ) calls block 102 in figure 1. Block 103 fetches the relevant processes that relevant for the “ship-order” event. Block 104 then execute the implementation of the “ship-order” for the “sending and invoice” process (the DB query function) and receives a positive answer for of the “sending an invoice” process. Block 105 execute the actions defined in figures 2B, that is the action executor in figure

SUBSTITUTE SHEET (RULE 26) 9 (902) runs the implementation of the following actions: “send email” action for action named “email”, “create record” action for action named “create a task”.

To remove any doubts:

An event dispatcher / executor can be implemented very easily for example by using a “switch statement” for events or through OOP’s polymorphism (an execute interface and multiple classes that implement the execute interface) or through a more advanced implementation that may involve synchronous, asynchronous, local system and/or distributed execution of actions. The action-settings stored under the process-data- structure can be stored as a JSON/XML/other type of flexible structure.

The events execution implementation provided to the event-executor can include for example some basic functions as events with or without the usage of the optional X- Structure, such as a database query event (that runs SQL statements), a DML function event, an API / REST Call functions that executes an API call, an https call functions that execute an https call, a code executor functions / mechanism such as reflection that can run custom code and/or may support the creation of new event-execution or use the defined process as a new event type.

The actions implementation provided to the action-executor can include for example some basic action such as a query database action (that runs SQL statements), a DML operation action for changing data (update/insert/delete/etc), an API / REST Call action that executes an API call, an https call action that execute an https call, a code executor action / mechanism such as reflection that can run custom code and/or may support the creation of new action-execution from a combination of other actions and processes.

SUBSTITUTE SHEET (RULE 26)