WO2023121504A1 - System and method for managing notifications - Google Patents

Abstract

The present invention relates to systems and methods for managing notifications, which allow efficient and rapid identification of events and changes to data in databases, digital files, documents and the like. According to the claimed method for managing notifications, first, an object from a database is changed. Said object is changed by means of a user device. An expression defining the change in the object is generated. The result of the expression is then calculated and the objects used by the expression are stored. Next, changes to the object are stored in an object source by means of an object storage module. After the changes are stored, a notification of the change is created in the form of an expression. For this purpose, first a notification type is identified, then an expression is calculated for the identified notification type. A list of the changed objects used in the calculation of the notification expression is generated. After that, the notification can be executed and the changes in the object are stored in the database. The present invention can be used in corporate information systems for organizing cooperation with other systems, and provides that notifications are managed efficiently and are also sent very quickly to the system.

Description

SYSTEM AND METHOD FOR MANAGING NOTIFICATIONS

Technical field

[0001] The present invention relates to systems and methods for managing alerts that provide efficient and fast identification of events and data changes in databases, digital files, documents, etc. The present invention can be used in corporate information systems to organize interaction with other systems.

State of the art

[0002] Corporate information systems typically operate in conjunction with other systems. To ensure consistency between them, coordination is necessary, which, in turn, requires that each of the systems respond to external events. In this regard, almost any corporate information system uses event-driven components.

[0003] Events can be divided into 2 classes: explicitly triggered named events, incl. parameterized, and events related to data change. Within the framework of the present invention, a variant of events generated by data changes is considered.

[0004] Data changes can be either atomic, when a change event of a single record of a particular type is processed, or complex, when the event is triggered only in the event of a complex change of a certain set of interrelated data. In most information systems, there is the functionality of processing events for creating, changing and deleting a single record, for example, triggers in database management systems. However, many business events are difficult to describe by such changes. For example, changing data by other users and systems entails the need to update part of the user interface, however, the interface is usually built hierarchically and you need to monitor not a fixed object, but the object that is “current”, i.e., is the result of a chain of links from the root object .

[0005] To monitor only part of the events associated with the change of fixed objects, a similar approach, i.e. tracing the chain of references from the root object results in complex multi-level code, which also needs to be carefully modified when changes are made to the user interface. [0006] A solution is known, described in the patent US9292587B2 (publ. 03/22/2016; IPC: G06F 17/30). It provides systems and methods for providing notifications to a remote application about changes made to a database table. The system and methods manage notification of changes to a table in a database by notifying an application configured to receive notifications of changes made to a database table. The database manager running on the device may receive a registration request for an application that will be notified when the first table of the plurality of tables in the database is changed. The database manager may set up a notification table containing the fields of the first table and one or more additional fields to manage the notification. The database manager can set a trigger on the first table to call a trigger procedure to copy the modified row of the first table to the notification table. The database manager can create a notification table rule to notify registered applications when a new row is inserted in the notification table. The first disadvantage of the analog is that it monitors the entire set of changes in the database, which slows down the system. The second drawback is that in the analog, an alert occurs for every change in the database table.

[0007] US7836031B2 (published Nov. 16, 2010; IPC: G06F 7/00; G06F 17/00) describes systems and methods for using a trigger-based mechanism to detect changes in a database table, provide notification when a database table changes data and registration for notification. Systems and methods use a listener table to store information associated with registered database tables. After a database table change, the database change trigger mechanism makes it easy to find the listener table for the parameter associated with the changed database table. If the modified database table is registered, information from the listener table is provided to the delivery service, which sends a message indicating that the registered database table has changed. Upon receipt of the message, the notification runtime service may send a notification to the client(s) registered to receive the notification. One of the differences of the analog from the present invention is that the analog provides for the stage of registering a table for subsequent receipt of notifications about its change. In the present invention, this step is not required, since it is supposed that changes of tables/files/documents are initially monitored. Another difference is that in similarly, to make changes to a table, you need to request permission to make changes to the table. The present invention initially defines a list of persons who have access to make changes to the table/file/document, as well as a control user who will receive change notifications. The first disadvantage of the analogue is that it monitors the entire set of changes in the database, which requires additional computing power of the server, and also creates unnecessary notifications for the control user. The second drawback is that in the analog, an alert occurs for every change in the database table, which also creates unnecessary alerts [0008] Also known is the invention according to patent US6617969B2 (publ. which describes methods and apparatus for sending a notification message in accordance with a set of notification preferences. A notification message is sent when an event is detected or a condition is met for the detected event. The set of notification preferences may indicate the desired notification medium through which the notification message is to be sent, the notification destination to which the notification message is to be sent, and/or the notification time preference indicating the date and/or time during which the notification is to be sent (or received). The first disadvantage of the analog is that it monitors the entire set of changes in the database, which requires additional computing power of the server, and also generates notifications for the managing user about all changes. The second drawback is that in the analog, an alert occurs for every change in the database table, which also creates unnecessary alerts in the system.

[0009] The invention of US9591059B2 (publ. 03/07/2017; IPC: H04L 29/08; G06F 17/30) describes a device for notifying a file change, including a notification creation module that creates a message on the first local node with a file change notification in response to a client creating, deleting, and/or modifying a file system element addressed via a file path. The first local node notifies the associated local client processes representing the clients connected to the first local node and flagged for file change information. The device includes a node identification module that checks the global node for second local nodes flagged for file change information for the file path, and a notification propagation module that sends a message in response. file change notifications from the first local node to the second local nodes, prior to obtaining the identity of the second local nodes. The second local node notifies the associated local client processes representing the clients connected to the second local node and flagged for information about the file path change. The first disadvantage of the analogue is that it monitors the entire set of changes in the database, while in this way the present invention monitors certain records in files, and the list of checked records is generated automatically based on the expression. This allows you to significantly reduce the computing power of the server, and also not notify the managing user of all changes. The second drawback is that in the analog, to receive an alert, you must send a request to receive an alert. In the present invention, the server decides which notifications and in what form to send to the managing user. This allows the managing user to be notified only of significant changes, rather than all of them. The main difference of the present invention from the analog is that the analog is intended only for monitoring changes in the files of the NAS system, as well as for sending notifications about these changes. (NAS (English Network Attached Storage) - data storage server at the file level). The present invention can monitor changes in any kind of files/documents/tables, including database tables.

[00010] US20140195476A1 (publ. 07/10/2014; IPC: G06F 17/30) describes a computer-implemented method for generating an in-memory database update notification, including: detecting an in-memory database event that inserts, deletes, or changes the first entry in the in-memory database; executing a first database trigger that corresponds to the detected database event in memory; identifying a first business event definition that maps to the executed first database trigger; and creating a first notification that matches the identified first business event definition, a first notification generated for a first subscriber to the identified first business event definition. The first disadvantage of the analogue is that it monitors the entire set of changes in the database, while in this way the present invention monitors certain records in files, and the list of checked records is generated automatically based on the expression. This allows you to significantly reduce the computing power of the server, and also not notify the managing user of all changes. Second the disadvantage is that in the analog, an alert occurs for every change in the database table. In the present invention, the server decides which notifications and in what form to send to the managing user. This allows the managing user to be notified only of significant changes, rather than all of them.

The essence of the invention

[00011] The objective of the claimed invention is to create and develop a system and method for managing alerts that provide efficient and fast identification of events and data changes, as well as the creation of quick alerts based on them.

[00012] The technical result, to which the claimed invention is directed, is to ensure the efficiency of notification management, as well as the speed of sending notifications to the system. The technical result is achieved including, but not limited to, due to:

[00013] describing the monitoring event as an expression in an expression language; [00014] monitoring certain objects in the database, not all objects;

[00015] monitoring only as changes occur in objects;

[00016] the decision by the control server about what notifications and in what form to send to the control user.

[00017] A more complete technical result is achieved thanks to an alert management system that includes at least one user device with an interface, at least one database and a server connected to each other. In this case, the server includes at least one object source, a notification component, an expression evaluation component, and a storage component. The alert component is configured to generate alerts and includes an alert service, an alert expression object parser, and an alert executor. At the same time, the alert service, the alert expression object parser, and the alert executor interact with each other sequentially. The expression evaluation component is configured to monitor object changes and includes at least one expression initiator, expression executor, and a list of objects to monitor. In this case, the list of objects to be monitored interacts with the notification executor, and at least one expression initiator interacts with at least one source of objects and with the executor expressions. The persistence component is configured to persist changes to a database and includes an object caching module and an object persistence module. In this case, the object caching module interacts with the expression executor and with the object persistence module, and the object persistence module interacts with at least one database.

[00018] At the same time, at least one user device is required to make changes to database objects and/or to receive change notifications. The interface is needed by the user device to inform the user of the user device about what is happening. At least one database is needed to organize access of the server and the user device to the database objects, and the server is needed to notify the user of the user device about changes in the database and save the changes to the database. At the same time, at least one source of objects is required to organize server access to the database. The alert component is required to create alerts. At the same time, the alert service is needed to directly create alerts based on the changes made and determine the type of alert, the alert expression object analyzer is needed to calculate the alert and generate a list of used objects. An alert executor is required to execute custom code that must be executed when an alert is fired. However, the alert service, the alert expression object parser, and the alert executor must interact sequentially with each other to create an alert. The expression evaluation component is required to monitor object changes. The fact that the expression evaluation component includes at least one expression initiator is necessary for the generation of an expression that specifies an object change. The executor of the expression is needed to evaluate the result of the expression, and the list of objects to monitor is needed to determine which objects need to be monitored for changes in order to generate an alert. The fact that the list of objects to monitor interacts with the notification executor, and at least one expression initiator interacts with at least one object source and the expression executor, is necessary to directly monitor object changes. The save component is required to save changes to the database. The caching module, at the same time, is necessary for organizing quick access to objects, and the object saving module is necessary for writing to the database, performing the necessary checks and transmitting events to various services, including notifications. The fact that the object caching module interacts with the expression executor and the object persistence module, and the object persistence module interacts with at least one database, is necessary for the direct organization of the ability to save changes to objects in the database.

[00019] At least one database may be hosted on a server and/or be an external database, depending on the specific application of the present system.

[00020] Application code may be used as at least one initiator of the expression.

[00021] Also in the alert management system, additional options for the interaction of its components and elements can be organized, which will ensure the implementation of an additional technical result. For example, to check if an alert has worked, or to update the list of objects to monitor.

[00022] Also, the technical result is achieved by a notification management method, according to which the object from the database is first changed, and then the notification event is created in the form of an expression. At the same time, at the stage of changing the object from the database: changing the object using the user device; generate an expression that defines the change of the object; calculate the result of the expression; store the objects used by the expression; and saving changes to the object in the object source using the object persistence module. At the stage of creating an alert: determine the type of alert using the alert service; calculate the alert expression for the specific alert type; forming a list of changed objects used in the calculation of the notification expression; execute notification; updating the list of objects in the list of objects to be monitored based on the calculated alert expression; and save changes to the object in the database.

[00023] In this case, the step of changing the object using the user device is necessary to make a change on the basis of which an alert will be created. The stage of generating the expression and calculating the result of the expression is necessary to change the value of the objects on the basis of which the notification will be calculated, as well as to link the expression with other objects involved in the calculation. Storing the objects used by the expression and saving the change to the object in the object source is necessary to create a list of objects associated with the alert. The step of determining the type of alert is necessary to determine whether whether the alert is fast or not, for the subsequent decision to create an alert. Calculation of the alert expression for a specific alert type is required to check if the result of the alert expression has changed. Formation of the list of changed objects is necessary to compare it with the list of objects for monitoring. Execution of the notification is necessary for the direct output of the notification to the interface of the user device. Updating the list of objects in the list of objects for monitoring based on the calculated expression is necessary for the subsequent monitoring by objects, as a result of which changes the value of the notification expression may change. Saving changes to objects is necessary in order to save the changes made to the object by the user in the database.

[00024] At the stage of executing the alert, the alert executor can additionally execute the program code included in the alert. This may be necessary if the alert includes additional code that allows you to implement complex scenarios for reacting to the alert.

[00025] After the step of executing the alerts, it may be further checked whether the alert has been executed. This can be done by passing objects from the object saver to the list of objects to monitor, checking if the object is in the list of objects to monitor, and sending an alert to the alert executor. At the same time, if the notification on the change of this object has been executed, then they can pass the object to the notification service and visualize the notification in the user interface.

[00026] After the execution phase, alerts can also update the list of objects to monitor. This can be done by passing objects from the object saver to the list of objects to monitor, passing the object to the object parser of the alert expression, and checking if the list of alert objects has changed. If the list of objects has changed, then they can transfer the new list to the list of objects for monitoring and update the object in the list of objects for monitoring.

[00027] At the same time, the steps of checking whether an alert has been executed and updating the list of objects to monitor can be performed in parallel to further speed up the process.

Description of drawings [00028] In FIG. 1 is a schematic view of an alert management system according to the present invention.

[00029] In FIG. 2 is a schematic view of an alert management system, with the additional capability of verifying the execution of an alert, in accordance with the present invention.

[00030] In FIG. 3 is a schematic view of an alert management system with the additional ability to update the list of objects to be monitored in accordance with the present invention.

[00031] In FIG. 4 is a schematic view of an alert management system with all the additional features of the present invention.

[00032] In FIG. 5 is a block diagram illustrating the notification management method according to the present invention.

[00033] In FIG. 6 is a flow diagram illustrating the additional steps of the notification management method for implementing notification execution verification in accordance with the present invention.

[00034] In FIG. 7 is a flow diagram illustrating the additional steps of the alert management method for implementing updates to the list of objects to monitor in accordance with the present invention.

[00035] In FIG. 8 is a flow diagram illustrating all of the additional steps in the method for managing alerts in accordance with the present invention.

Detailed description

[00036] In the following detailed description of the invention, numerous implementation details are provided to provide a clear understanding of the present invention. However, it will be obvious to one skilled in the art how the present invention can be used, both with and without these implementation details. In other cases, well-known methods, procedures and components are not described in detail so as not to obscure the features of the present invention.

[00037] In addition, from the foregoing, it is clear that the invention is not limited to the above implementation. Numerous possible modifications, alterations, variations, and substitutions that retain the spirit and form of the present invention will be apparent to those skilled in the art.

[00038] In FIG. 1 is a schematic representation of an alert management system configured with the ability to modify objects and create alerts, according to the present invention. The system includes at least one user device 1 with a software interface, a server 2, and at least one database 3. Server 2, in turn, includes at least one object source 210, an alert component 220, an expression evaluation component 230, and a persistence component 240. The alert component 220 includes an alert service 221, an alert expression object parser 222, and an alert executor 223. The expression evaluation component 230 includes an expression initiator 231, an expression executor 232, and a list of objects to monitor 233. And a persistence component includes an object caching module 241 and a module storing objects 242. In this case, the database 3 interacts with the object source 210, which, in turn, interacts with the software interface. Using the software interface, it is possible to change objects from at least one source of objects 210. A change trigger is sent using the software interface to the alert service 221 interacting with it, which interacts with the alert object expression parser 222. The alert expression object parser 222 interacts with the performer alert 223 and alert 223 with a list of objects to monitor 230. At least one object source 210 interacts with an expression initiator 231. in turn, interacts with the object persistence module 242. The object persistence module 242 interacts with at least one database 3, which closes the chain of interaction between the alert management system elements. This system configuration allows you to modify objects from database 3 and generate alerts based on the changes made.

[00039] At least one user device 1 may be any electronic computer (computer) configured to access the Internet and includes a memory and a processor. For example, it can be a desktop computer such as a personal computer (PC), home computer, monoblock, Plug PC (Plug Personal Computer), gaming computer. It can also be an Internet device, such as a netbook, an Internet tablet, a netbook tablet, a nettop. Also, the user device 1 may be a small and/or mobile computer, such as a mobile Internet device, a PDA, a laptop, a smartphone, etc.

[00040] The user device 1 interface 110 is the boundary between two functional entities (the user device 1 and the server 2), the requirements for which are determined by the standard; a set of means, methods and rules of interaction (management, control, etc.) between the elements of the system. In this case, the interface 1 can be used as an element of the user device 1, for example, a display, a set of buttons and switches for settings, plus rules for managing them related to the human-machine interface. The keyboard, mouse, and other input devices, which are elements of the human-computer interface, can also be used. Also, both types of interfaces can be used in combination with each other.

[00041] Server 2 is one of the alert management system hardware. It 2 may be a dedicated or specialized computer for executing service software. Server (service) software is a software component of a computing system that performs service (servicing) functions at the request of the client, providing him with access to certain resources or services.

[00042] The server 2 within the framework of the present invention includes at least one source of objects 210. It 210 is used to communicate objects from the database 3 with the server 2 and the user device 1. Digital object - an object consisting of a structured sequence of bytes, having a name, a unique identifier and attributes describing its properties. In the context of the present invention, a digital object refers to any document, file, spreadsheet or any of their components placed in a digital environment. In the preferred embodiment, the object is an element from the database 3.

[00043] The alerts component 220 is designed to generate alerts directly. The fact that it 220 includes the alert service 221 allows the type of alert to be determined. Notification is the automatic creation of an event when the value of an expression in the expression language changes as a result of a change in one of the objects involved in the calculation of the value of the expression. They are divided into two types: fast and standard. Fast alerts are alerts that do not require a round-robin recalculation of the alert expression to be processed. Standard alerts require regular recalculation. A standard alert is calculated when application processes run at regular intervals. Objects will be updated when the form's main alert expression is recalculated, or the secondary alert (if any) is recalculated. For example, the main expression for the attribute Attribute! can be specified as Credit.Client, and optionally as Credit.Client. Age. In this case, when changing the value of the client's age, all form elements that depend on the attribute Attribute! will be updated. The identifier represents the "coordinates" of the object in database 3.

[00044] In order for a notification to be fast, the notification expression must satisfy the following list of requirements: it must use only the functions supported in fast notifications, and it must receive attribute values of the context type. At the same time, the attributes must be non-collectible, and, in the case of form attributes, stored. It is allowed to get the value of a chain of stored attributes, for example, notification Client.Contract. The status that receives the value of the stored attribute of the form Client (reference to type Client) will be fast.

[00045] An expression is text in an expression language that can be calculated (executed). At the same time, the values of object attributes can be used and changed in the calculation process. Alerts, in turn, are an entity that contains an expression and is intended to notify the creator of the alert that the value of this expression has changed. Such expressions are referred to in the text as "alert expressions". All other expressions that are sent for execution by other components of the system and generate changes to objects are referred to as an "expression".

[00046] The alert expression object parser 222, when creating a new alert instance, recursively processes the expression as if it were evaluating its value, but in addition to the calculation itself, it generates a list of objects that were used in evaluating the expression. These objects fall into the list of objects for monitoring 233.

[00047] The alert executor 223 is an execution adapter for executing the alert itself. Also, it 223 may contain user program code to be executed when the alert is triggered. The result of triggering an alert can be either an update of some parts of the user interface of the software that are explicitly marked as depending on the alert, or the execution of arbitrary program code, which allows you to implement complex scenarios for reacting to the alert.

[00048] At the same time, the sequential interaction of the alert service 221, the alert expression object parser 222, and the alert executor 223 allows you to create an alert, determine its type, objects associated with the alert and their identifiers, and directly execute the alert. [00049] The expression evaluation component 230 is an object change checking layer. Whenever objects are changed in any way—through the user interface or by automated data handlers—all changed or deleted objects are checked to see if they are included in the list of objects to be monitored 233. This includes at least one expression initiator 231, expression executor 232, and list of objects for monitoring 233.

[00050] The initiator of expressions 231 is designed to generate expressions corresponding to the change of objects. The expression executor 232 is an alert expression evaluator that checks whether the result of the alert expression has changed and also generates a new list of objects that participated in the evaluation of the alert expression. The list of objects to monitor 233, in turn, stores the identifiers of objects that need to be checked when changing, as well as a map of the object and the list of alerts that depend on it.

[00051] At the same time, the notification executor 223 interacts with the list of objects to monitor 233 to check whether the object on which the notification should be executed is included in the list of objects to monitor 233. And the initiator of expressions 232 interacts with at least one source of objects 231 in order to detect changes to objects for the subsequent creation of a notification event associated with the object, and with the expression executor 232 - to pass an expression to it in order to subsequently calculate the value of the expression.

[00052] The persistence component 240 is then designed to store object changes from the database 3. The object cache module 241 may temporarily store the changes. In data computing, a cache is a high-speed storage layer in which a required set of data is typically temporary. Access to data at this level is carried out much faster than to the main place of their storage. With the help of caching, it becomes possible to efficiently reuse previously received or calculated data.

[00053] At the same time, object changes can also be carried out by the object persistence module 242 connected to at least one database 3. It 242 writes to the database 3, performing the necessary checks and transmitting events to various services, including alerts.

[00054] The alert management system shown in FIG. 1 works as follows. First, object changes are made using user device 1. The change, as a trigger event, is sent to an expression initiator 231 which generates an expression specifying the change of the object. The generated expression is then sent to the expression executor 232, which in turn evaluates the result of the expression. After that, the objects that were used during the evaluation of the expression are sent to the object cache module 241, which temporarily stores the objects with changes, and then they are transferred to the object saver 242, which in turn stores the changed objects in the object source 210. Simultaneously with the change of the object, a notification event about this change is also created. Using the service alerts 221 determine the type of alert, as described above. For a certain type of alerts, namely for quick alerts, the expression is then calculated using the alert expression object parser 222. At this stage, a list of objects that were used in the calculation of the alert expression, also using the alert expression object parser 222, is formed. The list consists of changed objects used in evaluating the alert expression. After that, notifications are executed using the notification executor 223. The notification executor 223, in addition to the notification itself, can also execute program code that can be included in the notification executor 223. After that, object changes are saved using the object saver 242 in the database 3.

[00055] In FIG. 2 is a schematic view of an alert management system, with the additional capability of verifying the execution of an alert, in accordance with the present invention. The ability to check the execution of alerts is an additional technical result in the framework of the present invention, which can be achieved by adding additional interaction options for the elements of the alert management system shown in FIG. 2. In this case, in order to achieve simultaneous additional and main technical results, the above and below described interactions must be used in combination.

[00056] The object store module 242 may further interact with the list of objects to monitor 233. This may be necessary in order to transfer the objects stored in the database 3 by the object store module 242 to the list of objects to monitor 233. Using the list of objects to monitor 233. monitoring 233 check the presence of this object in the list 233.

[00057] The list of objects to monitor 233, in turn, can interact with the alert performer 223. Thus, the list of objects to monitor 233 conveys to the alert performer 223 information about whether whether this object is present in the list 233, as well as the object itself. It 223 checks to see if a notification has been executed to change this object.

[00058] The alert executor 223 may further interact with the alert service 221, and the alert service 221 interacts with the software interface. In this case, if the object change notification has been executed, the object is transferred from the notification executor 223 to the notification service 221, and then to the software interface, in which the notification is visualized using the notification service 221.

[00059] The visualization of the notification itself may imply a change in the visual embodiment of objects, i.e. the change itself, as well as some pop-up notification of the change. These alert visualization options can be used individually or in combination. At the same time, if the notification executor 223 contains additional user program code, the notification can be visualized by various complex scenarios. For example, alerts may include functional elements such as buttons, input fields, etc. Thus, various ways of user reaction to alerts will be implemented. For example, he can cancel the change, accept it, send a request to check the correctness of the changes made, etc.

[00060] The portion of the alert management system shown in FIG. 2 works as follows. After the step of executing the alert by the alert executor 223, it is checked whether the alert has been executed. At the same time, objects are transferred from the object storage module 242 to the list of objects for monitoring 233. Using the list of objects for monitoring 233, they check the presence of this object in the list 233 and transmit information about the presence / absence of the object in the list, as well as the object itself (more precisely, its identifier ) to the notification executor 223. If the notification to change this object has been executed, then the object is transferred to the notification service 221, and then the notification is visualized in the user interface of the software using the notification service 221.

[00061] The alert management system shown in FIG. 1 in combination with additional interactions shown in FIG. 2 works as follows. First, changes are made to the object using the user device 1. The change is sent as a trigger event to the expression initiator 231, which generates an expression defining the change of the object. The generated expression is then sent to the expression executor 232, which in turn evaluates the result of the expression. After that, the objects that were used during the evaluation of the expression are sent to the object cache module 241, which temporarily stores the objects with changes, and then they are passed to the object saver 242, which in turn saves the changed objects to the object source 210. At the same time as the object is changed, a notification event about this change is also generated in the notification links. Using the service alerts 221 determine the type of alert, as described above. For a certain type of alerts, namely for quick alerts, the expression is then calculated using the alert expression object parser 222. At this stage, a list of objects that were used in the calculation of the alert expression, also using the alert expression object parser 222, is formed. The list consists of changed objects used in evaluating the alert expression. After that, notifications are executed using the notification executor 223. The notification executor 223, in addition to the notification itself, can also execute program code that can be included in the notification executor 223. After that, changes to the object are saved using the object saver 242 in the database 3. After the stage of executing the notification by the notification executor 223 also checks whether the notification has been executed. At the same time, objects are transferred from the object storage module 242 to the list of objects for monitoring 233. Using the list of objects for monitoring 233, they check the presence of this object in the list 233 and transmit information about the presence / absence of the object in the list, as well as the object itself (more precisely, its identifier ) to the notification executor 223. If the notification to change this object has been executed, then the object is transferred to the notification service 221, and then the notification is visualized in the user interface of the software using the notification service 221.

[00062] In FIG. 3 is a schematic view of an alert management system with the additional ability to update the list of objects to be monitored 233 in accordance with the present invention. The ability to update the list of objects for monitoring 233 is an additional technical result in the framework of the present invention, which can be achieved by adding additional interaction options for the elements of the alert management system shown in FIG. 3. At the same time, in order to achieve simultaneous additional and main technical results, the interaction options shown in FIG. 1 and the interactions described below should be used in combination.

[00063] As shown in FIG. 3, the object persistence module 242 may interact with the list of objects to monitor 233. This may be necessary to check if the stored objects are contained in the list 233. [00064] The list of objects to monitor 233 may further interact with the object parser of the alert expression 222 in a two-way manner. This may be necessary to check if the list of alert expression objects has changed.

[00065] The portion of the alert management system shown in FIG. 3 works as follows. After the notification execution step, the notification executor 223 updates the list of objects for monitoring 233. To do this, objects are first transferred from the object storage module 242 to the list of objects for monitoring 233. It checks 233 whether the stored objects are contained in the list 233. After that, the object is transferred to the alert expression object parser 222. The parser 222 checks to see if the list of alert expression objects has changed. If the list of objects of the alert expression has changed, then the new list is passed to the list of objects to be monitored 233 and the list 233 is updated with the new list.

[00066] The alert management system shown in FIG. 1 in combination with additional interactions shown in FIG. 3 works as follows. First, changes are made to the object using the user device 1. The change is sent as a trigger event to the expression initiator 231, which generates an expression defining the change of the object. The generated expression is then sent to the expression executor 232, which in turn evaluates the result of the expression. After that, the objects that were used during the evaluation of the expression are sent to the object cache module 241, which temporarily stores the objects with changes, and then they are transferred to the object saver 242, which in turn stores the changed objects in the object source 210. Simultaneously with the change of the object, a notification event about this change is also created in the form of a link to the notification. Using the service alerts 221 determine the type of alert, as described above. For a certain type of alerts, namely for quick alerts, the alert expression is then calculated using the alert expression object analyzer 222. At this stage, a list of objects that were used in the alert calculation also using the alert expression object analyzer 222 is formed. The list consists of changed objects used in evaluating the alert expression. After that, notifications are executed using the notification executor 223. The notification executor 223, in addition to the notification itself, can also execute program code that can be included in the notification executor 223. After that, changes to the object are saved using the module for storing objects 242 in the database 3. After the stage of execution of the notification by the notification executor 223, the list of objects for monitoring 233 is also updated and in parallel it is checked whether the notification has been executed. To update the list of objects to monitor 233, objects are first passed from the object saver 242 to the list of objects to be monitored 233. It checks 233 whether the stored objects are contained in the list 233. After that, the object is passed to the object analyzer of the notification expression 222. Using the analyzer 222 check if the list of alert expression objects has changed. If the list of objects of the alert expression has changed, then the new list is passed to the list of objects to be monitored 233 and the list 233 is updated with the new list. In this case, the verification of notification execution is performed as follows. Objects are transferred from the object storage module 242 to the list of objects for monitoring 233. Using the list of objects for monitoring 233, the presence of this object is checked in the list 233 and information about the presence / absence of the object in the list, as well as the object itself (more precisely, its identifier) is transmitted to notification executor 223. If the notification to change this object has been executed, then the object is transferred to the notification service 221, and then the notification is visualized in the user interface of the software using the notification service 221.

[00067] At the same time, the interaction options for the elements of the notification management system shown in FIG. 1, Fig. 2 and FIG. 3 can be used in combination as shown in FIG. 4. First, changes to the object are carried out using the user device 1. The change is sent as a trigger event to the initiator of the expression 231, which generates an expression defining the change of the object. The generated expression is then sent to the expression executor 232, which in turn evaluates the result of the expression. After that, the objects that were used during the evaluation of the expression are sent to the object cache module 241, which temporarily stores the objects with changes, and then they are transferred to the object saver 242, which in turn stores the changed objects in the object source 210. Simultaneously with the change of the object, a notification event about this change is also created in the form of a link to the notification. Using the service alerts 221 determine the type of alert, as described above. For a certain type of alerts, namely for quick alerts, the alert expression is then calculated using the alert expression object analyzer 222. At this stage, a list of objects that were used in the calculation of the expression is generated. alerts also using the alert expression object parser 222. The list consists of the changed objects used in the calculation of the alert expression. After that, the notification is executed using the notification executor 223. The notification executor 223, in addition to the notification itself, can also execute program code that can be included in the notification executor 223. After that, changes to the object are saved using the object saver 242 in the database 3. After At the notification execution stage, the notification executor 223 also updates the list of objects for monitoring 233. To do this, objects are first transferred from the object storage module 242 to the list of objects for monitoring 233. It checks 233 whether the stored objects are contained in the list 233. After that, the object is transferred to the alert expression object parser 222. The parser 222 checks to see if the list of alert expression objects has changed. If the list of notification objects has changed, then the new list is passed to the list of objects to be monitored 233 and the list 233 is updated with the new list.

[00068] The database 3, which is part of the notification management system, can be either hosted on the server 2 or be an external database. It can also use external databases and databases hosted on the server in combination. There can be any number of them, depending on the specific implementation of the system and needs.

[00069] Application code (forms) may be used as at least one initiator of expression 231 . Processes and web services can also be used.

[00070] The software interface of the user device 1 may be implemented in any human-readable manner, i. e. in the form of any human-machine interface. For example, using the command line interface. The command line interface is a user interface implemented by the user typing command text and reading response text. A gesture interface can also be used, allowing the user to interact with the computer (give commands to it) using gestures. In this case, it is also worthwhile to provide for the inclusion in the user device 1 of a camera and/or a webcam capable of recognizing human movements. It is also possible to implement a voice interface, with the help of which commands are given by voice. In this case, a microphone must also be connected to user device 1. The most preferred option is to use the graphical user interface. It is implemented through the formation of graphic images and their manipulation. [00071] In FIG. 5 is a block diagram illustrating the notification management method according to which the notification management system shown in FIG. 1. First, changes to the object are made using the user device 1. The change is sent as a trigger event to the expression initiator 231, which generates an expression specifying the change of the object. The generated expression is then sent to the expression executor 232, which in turn evaluates the result of the expression. After that, the objects that were used during the evaluation of the expression are sent to the object cache module 241, which temporarily stores the objects with changes, and then they are transferred to the object saver 242, which in turn stores the changed objects in the object source 210. Simultaneously with the change of the object, a notification event about this change is also created in the form of a link to the notification. Using the service alerts 221 determine the type of alert, as described above. For a certain type of alerts, namely for quick alerts, the alert expression is then calculated using the alert expression object analyzer 222. At this stage, a list of objects that were used in the calculation of the alert expression also using the alert expression object analyzer 222 is formed. The list consists of changed objects used in the calculation of the alert expression. After that, notifications are executed using the notification executor 223. The notification executor 223, in addition to the notification itself, can also execute program code that can be included in the notification executor 223. After that, object changes are saved using the object saver 242 in the database 3.

[00072] The stage of changing the object using the user device 1 may involve changing its visual embodiment, changing the data contained in the object, etc. This can be done through additional input devices, for example, through a computer mouse, keyboard and other input devices, for example, a microphone .

[00073] The ID generation step involves parsing the "coordinate" of the object in the database 3. "Coordinate" is the ID of the object. Identifier, as the "coordinate" of the object, while also setting the alert identifier.

[00074] At the stage of evaluating the result of the alert expression, the expression is essentially "unpacked" by determining which objects are involved in the calculation of a particular expression. For example, the expression Client.Agreement. Status includes objects: Status, available by expression Client.Agreement. Status, Agreement, available by expression Client.Agreement, and Client, available by expression Client. To determine the entire chain of used objects, the expression executor 232 recursively evaluates the expression, thus forming a list of used objects. The list of used objects is sent to the object caching module 241 for temporary quick access to them, and also stored in the object source 210 for later creation of an alert.

[00075] Alert type determinations involve determining whether an alert is a quick alert or a standard alert based on whether it uses only features supported in quick alerts and based on getting the context type attribute value as previously described. In this case, notifications are executed only for fast notifications. If the notification is standard, then at the stage of determining the type of notification, the algorithm completes its work.

[00076] Calculation of the alert expression by the alert expression object parser 222 when creating a new alert instance implies recursive processing of the expression, as in the calculation of its value, but in addition to the calculation itself, it generates a list of objects that were used in the calculation of the expression. These objects fall into the list of objects for monitoring 233.

[00077] In FIG. 6 is a flow diagram illustrating additional steps of the notification management method, providing an additional technical result of being able to check whether the notification has been executed. According to it, after the step of executing the notification by the notification executor 223, it is checked whether the notification has been executed. At the same time, objects are transferred from the object storage module 242 to the list of objects for monitoring 233. Using the list of objects for monitoring 233, they check the presence of this object in the list 233 and transmit information about the presence / absence of the object in the list, as well as the object itself (more precisely, its identifier ) to the notification executor 223. If the notification event for changing this object has been executed, then the object is passed to the notification service 221, and then the notification is rendered in the user interface 110 using the notification service 221.

[00078] Another additional technical result can also be achieved by adding the steps shown in FIG. 7. After the notification execution step, the notification executor 223 updates the list of objects for monitoring 233. To do this, objects are first transferred from the object storage module 242 to the list of objects for monitoring 233. It checks 233 whether the saved objects are contained in the list 233. After that the object is passed to the object parser alert expressions 222. The parser 222 checks to see if the list of alert expression objects has changed. If the list of objects of the alert expression has changed, then the new list is passed to the list of objects to be monitored 233 and the list 233 is updated with the new list. This allows the list of objects to be monitored 233 to be updated, which also adds more automation to the system.

[00079] Also, in any of the embodiments of the notification management method, additionally, at the stage of executing the notification, using the notification executor 223, additionally execute the program code included in the notification and / or in the execution adapter, which is the notification executor 223. As already described earlier, this can allow complex scenarios for reacting to an alert.

[00080] Also, the additional steps shown in FIG. 6 and FIG. 7 and those described above and the main steps shown in FIG. 5 may be used in combination to form the alert management method shown in FIG. 8. In this case, changes to the object are first performed by the user device 1. The change is sent as a trigger event to the expression trigger 231, which generates an expression specifying the change of the object. The generated expression is then sent to the expression executor 232, which in turn evaluates the result of the expression. After that, the objects that were used during the evaluation of the expression are sent to the object cache module 241, which temporarily stores the objects with changes, and then they are transferred to the object saver 242, which in turn stores the changed objects in the object source 210. Simultaneously with the change of the object, a notification event about this change is also created. Using the service alerts 221 determine the type of alert, as described above. For a certain type of alerts, namely for quick alerts, the alert expression is then calculated using the alert expression object parser 222. At this stage, a list of objects that were used in the calculation of the expression is also generated using the alert expression object parser 222. The list consists of changed objects used in evaluating the alert expression. After that, notifications are executed using the notification executor 223. The notification executor 223, in addition to the notification itself, can also execute program code that can be included in the notification executor 223. After that, changes to the object are saved using the object persistence module 242 in the database data 3. After the stage of execution of the notification by the notification executor 223, the list of objects for monitoring 233 is also updated. To do this, objects are first transferred from the object storage module 242 to the list of objects for monitoring 233. It checks 233 whether the stored objects are contained in the list 233. The object is then passed to the alert expression object parser 222. The parser 222 checks to see if the list of alert expression objects has changed. If the list of notification objects has changed, then the new list is passed to the list of objects to be monitored 233 and the list 233 is updated with the new list. At the notification execution stage, the program code included in the notification and/or in the notification executor 223 is also executed.

[00081] The present application materials provide a preferred disclosure of the implementation of the claimed technical solution, which should not be used as limiting other, private embodiments of its implementation that do not go beyond the requested scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims

Claim 1. An alert management system that includes at least one user device with an interface, at least one database and a server connected to each other, while the server includes: • at least one source of objects; • notification component configured to create notifications and includes: o notification service; o Alert expression object parser; about the performer of the notification; at the same time, the notification service, the analyzer of the notification expression objects and the notification executor interact sequentially, • an expression evaluation component configured to monitor object changes and including: o at least one expression initiator; o performer expression alerts; o list of objects for monitoring; while the list of objects to be monitored interacts with the notification executor, and at least one expression initiator interacts with at least one source of objects and with the expression executor, • and a persistence component configured to persist changes to a database and comprising: o an object caching module; o an object persistence module, wherein the object cache module interacts with the expression executor and the object persistence module, and the object persistence module interacts with at least one database. 2. The notification management system according to claim 1, characterized in that the object storage module additionally interacts with the list of objects for monitoring, and the list of objects for monitoring interacts with the notification executor. 3. The notification management system according to claim 2, characterized in that the notification executor additionally interacts with the notification service. 24 4. The notification management system according to claim 1, characterized in that the list of objects for monitoring additionally interacts with the object storage module and with the analyzer of the notification expression objects. 5. Alert management system according to claim 1, characterized in that the database is located on the server. 6. Alert management system according to claim 1, characterized in that the database is an external database. 7. Alert management system according to claim 1, characterized in that at least one expression initiator is application code. 8. Alert management system according to claim 1, characterized in that the user device interface is a graphical interface. 9. Alerts management method, according to which: • change the object from the database, namely: change the object using the user device; o generate an expression that defines a change to the object; o calculate the result of the expression; o store the objects used by the expression; o save changes to the object in the object source using the object persistence module, • create a notification in the form of an expression, namely: o define the type of notification using the notification service; o calculate an expression for a certain type of notification; o form a list of changed objects used in the calculation of the alert expression; o executing the notification using the notification executor; save changes to the object in the database. 10. The notification control method according to claim 9, characterized in that at the stage of executing the notification with the help of the notification executor, the program code included in the notification is additionally executed. 11. The notification management method according to claim 9, characterized in that after the notification execution stage, it is checked whether the notification has been executed, namely: • transfer objects from the object storage module to the list of objects for monitoring; • check the presence of this object in the list of objects for monitoring; • send the notification to the notification executor; if the notification on the change of this object was executed, then: • pass the object to the notification service; • render the alert in the user interface using the alert service. 12. The notification management method according to claim 9, characterized in that after the notification execution stage, the list of objects for monitoring is updated, namely: • transfer objects from the object storage module to the list of objects for monitoring; • pass the object to the object parser of the alert expression using the list of objects to monitor; • check whether the list of alert objects has changed using the alert expression object parser; if the list of objects has changed, then: • transfer the new list to the list of objects for monitoring; • update the object in the list of objects to be monitored. 13. The notification management method according to claim 11 and claim 12, characterized in that the steps of checking the execution of the notification and updating the list of objects for monitoring are performed in parallel.