Method and system for managing events using an event routing management module

Abstract

The present disclosure relates to a method and a system for managing events using an event routing management (ERM) module The method comprises receiving, by an elastic load balancer (ELB) unit [502], from one or more publishing microservice (MS) modules, one or more events. The method comprises publishing, by a publish handler [504], the received one or more events facilitating dynamic event subscription management. The method comprises notifying, by a notify handler [506], the published one or more events to one or more subscriber microservice (MS) modules. The method comprises storing, by a storage unit [510], in a database, a set of transactional logs data associated with the one or more events.

Description

METHOD AND SYSTEM FOR MANAGING EVENTS USING AN EVENT ROUTING MANAGEMENT MODULE TECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to network performance management systems. More particularly, embodiments of the present disclosure relate to managing events using an event routing management (ERM) module. BACKGROUND

[0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.

[0003] A network function virtualization (NFV) software defined networking (SDN) server is based on micro service architecture. These microservices servers have specific task and functionality which they all need to perform. The microservices servers work in tandem to achieve the overall functionality of the NFV SDN server. Each microservice server has exposed certain application programming interfaces (APIs) which are called by other microservices servers. In conventional network implementations, a crisscross model has been adopted, where each microservice server is communicating with all the other microservice servers directly. Thus, there exists a need for a server that it can route event requests of one microservices server to another.

[0004] Thus, there exists an imperative need in the art for a system and a method for event routing management, which the present disclosure aims to address. SUMMARY

[0005] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.

[0006] An aspect of the present disclosure may relate to a method for managing events using an event routing management (ERM) module. The method comprises receiving, by an elastic load balancer (ELB) unit, from one or more publishing microservice (MS) modules, one or more events. Further, the method comprises publishing, by a publish handler, the received one or more events facilitating dynamic event subscription management. Furthermore, the method comprises notifying, by a notify handler, the published one or more events to one or more subscriber microservice (MS) modules. Hereinafter, the method comprises storing, by a storage unit, in a database, a set of transactional logs data associated with the one or more events.

[0007] In an exemplary aspect of the present disclosure, the one or more publishing MS modules correspond to microservices that generate and send the one or more events to the Event Routing Manager (ERM).

[0008] In an exemplary aspect of the present disclosure, the step of notifying, by the notify handler

[0306] , the published one or more events to the one or more subscriber MS modules is based on a set of context metadata information associated with each of the one or more events.

[0009] In an exemplary aspect of the present disclosure, the set of context metadata information comprises details to identify context of the one or more events, wherein the set of context metadata comprises at least an end point information associated with the one or more events, priority level of the one or more events, and subscriber ID for each of the one or more events.

[0010] In an exemplary aspect of the present disclosure, the one or more events are categorized based on at least a type or purpose, wherein the one or more events comprises at least one of: a user registered event, a payment event, and an order placed event.

[0011] In an exemplary aspect of the present disclosure, the method comprises providing, by the one or more subscriber MS modules, to the ERM module using a subscribe handler, the set of context metadata information based on at least one of a subscribing action, and an unsubscribing action. The at least one of the subscribing action, and the unsubscribing action is associated with an event from the one or more events.

[0012] In an exemplary aspect of the present disclosure, the method comprises receiving, by each of the one or more subscriber MS modules, a notification associated with one or more target eventsfrom the published one or more events, and wherein the notification is based on the subscribing action associated with the one or more target events.

[0013] In an exemplary aspect of the present disclosure, the method comprises checking, by the subscribe handler, a status of the one or more subscriber MS modules. The step of checking the status of the one or more subscriber MS modules comprises identifying, by the subscribe handler, a first request from the one or more subscriber MS modules for unsubscribing from a first target event.

[0014] In an exemplary aspect of the present disclosure, the method comprises removing, by the subscribe handler, a set of target context metadata information, and wherein the set of target context metadata information is associated with identification of the first request.

[0015] In an exemplary aspect of the present disclosure, the method comprises managing, by a fault, configuration, accounting, performance and security (FCAPS) unit, a set of performance counter data and a set of alarm data, and wherein the set of performance counter data and the set of alarm data are associated with functions of an operations and management (OAM) module connected with at least the ERM module.

[0016] In an exemplary aspect of the present disclosure, the set of transactional logs data comprises at least one of: context metadata information, FCAPS performance counter data, FCAPS alarm data, types of microservice nodes, registration data of the microservice nodes, deregistration data of the microservice nodes, subscription data of the microservice nodes, and unsubscribe data of the microservice nodes for the one or more events.

[0017] Another aspect of the present disclosure may relate to a system for managing events using an event routing management (ERM) module. The system comprises an elastic load balancer (ELB) unit configured to receive, from one or more publishing microservice (MS) modules, one or more events. The system further comprises a publish handler connected to at least the ELB unit. The publish handler is configured to publish the received one or more events facilitating dynamic event subscription management. The system further comprises a notify handler connected to at least the publish handler. The notify handler is configured to notify the published one or more events to one or more subscriber microservice (MS) modules. The system further comprises a storage unit connected to at least the notify handler. The storage unit is configured to store, in a database, a set of transactional logs data associated with the one or more events.

[0018] Yet another aspect of the present disclosure may relate to a non-transitory computer readable storage medium storing instructions for managing events using an event routing management (ERM) module, the instructions include executable code which, when executed by one or more units of a system cause an elastic load balancer (ELB) unit to receive, from one or more publishing microservice (MS) modules, one or more events. The instructions when executed by the system further cause a publish handler unit to publish the received one or more events facilitating dynamic event subscription management. The instructions when executed by the system further cause a notify handler unit to notify the published one or more events to one or more subscriber microservice (MS) modules. The instructions when executed by the system further cause a storage unit to store, in a database, a set of transactional logs data associated with the one or more events. OBJECTS OF THE INVENTION

[0019] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.

[0020] It is an object of the present disclosure to provide a system and a method for event routing management.

[0021] It is another object of the present disclosure to provide a solution which acts as a central service to keep information of all events in a network.

[0022] It is yet another object of the present disclosure to provide a solution that enables storing transactional logs in a database server, which would be helpful to debug in case of event failure.

[0023] It is yet another object of the present disclosure to provide a solution that allows addition of new events to an ERM server dynamically, thereby reducing code overhead in the event any microservice server wants to use same event functionality which is already being used by other microservice server.

[0024] It is yet another object of the present disclosure to provide a solution that enables parallel, or sequential message delivery can be defined for each event that has multiple subscriber server.

[0025] It is yet another object of the present disclosure to provide a solution that supports redundancy in the event one ERM server goes down. DESCRIPTION OF THE DRAWINGS

[0026] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system according to the disclosure are illustrated herein to highlight the advantages of the disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry commonly used to implement such components.

[0027] FIG. 1 illustrates an exemplary block diagram representation of event routing manager (ERM) architecture, in accordance with exemplary implementations of the present disclosure.

[0028] FIG.2 illustrates an exemplary implementation of an ERM Redundant model, in accordance with exemplary implementations of the present disclosure.

[0029] FIG. 3 illustrates an implementation of the ERM method flow, in accordance with exemplary implementations of the present disclosure.

[0030] FIG. 4 illustrates an exemplary block diagram of a computing device upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.

[0031] FIG. 5 illustrates an exemplary block diagram of a system for managing events using an event routing management (ERM) module, in accordance with exemplary implementations of the present disclosure.

[0032] FIG. 6 illustrates a method flow diagram for managing events using an event routing management (ERM) module, in accordance with exemplary implementations of the present disclosure.

[0033] The foregoing shall be more apparent from the following more detailed description of the disclosure. DETAILED DESCRIPTION

[0034] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter may each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above.

[0035] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0036] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail.

[0037] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure.

[0038] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed hereinis not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.

[0039] As used herein, a “processing unit” or “processor” or “operating processor” includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. A processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a (Digital Signal Processing) DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor or processing unit is a hardware processor.

[0040] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smart- device”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a mobile communication device”, “a communication device” may be any electrical, electronic and / or computing device or equipment, capable of implementing the features of the present disclosure. The user equipment / device may include, but is not limited to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any other computing device which is capable of implementing the features of the present disclosure. Also, the user device may contain at least one input means configured to receive an input from at least one of a transceiver unit, a processing unit, a storage unit, a detection unit and any other such unit(s) which are required to implement the features of the present disclosure.

[0041] As used herein, “storage unit” or “memory unit” refers to a machine or computer-readable medium including any mechanism for storing information in a form readable by a computer or similar machine. For example, a computer-readable medium includes read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices or other types of machine-accessible storage media. The storage unit storesat least the data that may be required by one or more units of the system to perform their respective functions.

[0042] As used herein “interface” or “user interface” refers to a shared boundary across which two or more separate components of a system exchange information or data. The interface may also be referred to a set of rules or protocols that define communication or interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.

[0043] All modules, units, components used herein, unless explicitly excluded herein, may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc.

[0044] As used herein the transceiver unit include at least one receiver and at least one transmitter configured respectively for receiving and transmitting data, signals, information or a combination thereof between units / components within the system and / or connected with the system.

[0045] As discussed in the background section, the current known solutions have several shortcomings. The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing method and system of managing events using an event routing management (ERM) module.

[0046] Referring to FIG.1, an illustration of an exemplary block diagram representation of event routing manager (ERM) architecture

[0100] , in accordance with exemplary implementations of the present disclosure is shown.

[0047] The system comprises one or more microservices, a MS-x

[0104] , an event routing manager (ERM) module

[0102] , a NoSQL database

[0124] , an operation and management (OAM) interface

[0126] , a command line interface (CLI)

[0128] , an elastic load balancer (ELB) [130a], an ELB [132b], an ELB [134c] for a MS-a

[0130] , a MS-b

[0132] and a MS-c

[0134] respectively.

[0048] Further, the ERM module

[0102] comprises an elastic load balancer (ELB)

[0106] , a publish handler

[0108] , a logging service

[0112] , a bootstrap service unit

[0114] , a database (DB) client

[0116] , a fault, configuration, accounting, performance and security (FCAPS) handler

[0118] , a notify handler

[0120] and a data modelling service

[0122] . In general, the logging service

[0112] is used to record information about the events that occur within a system or application, such as errors and user actions. The data modelling service

[0122] utilizes non-relational database (such as NOSQL) for data modelling in to manage and control mapping of information (such as events, publisher, subscriber).

[0049] The one or more microservices are implemented in a network function virtualization (NFV) and software defined network (SDN) design function module which is based on microservice architecture. Each of the one or more microservices have specific tasks and functionality which each of the one or more microservices perform. Each of the microservices in combination achieve overall functionality of the NFV SDN module.

[0050] The MS-x

[0104] refers to a publisher microservice. The MS-x

[0104] publishes an event and sends it to the ELB

[0106] of the ERM

[1042] .

[0051] The ERM module

[0102] is a system to route events from one microservice to another efficiently instead of adopting a crisscross model as is implemented in the known in the art inventions, where each of the microservice communicates to the other microservices directly. The ERM module

[0102] routes the events between each of the microservices by using a publish subscribe model. The ERM module

[0102] maintains a list of a publisher microservice and a subscriber microservice for each event from one or more events. Based on the event list, the ERM module

[0102] delivers the events to each of the subscriber microservices. The ERM module

[0102] is configured to perform the routing via an instance of the ERM module

[0102] . If one ERM instance goes down, a second instance may be configured to route the event.

[0052] The bootstrap service unit

[0114] in the ERM module

[0102] is configured to initiate all the modules in the ERM

[0102] in order to manage event routing between the one or more microservices.

[0053] The FCAPS handler

[0118] is conjured to manage faults, configuration, accounting, performance and security related functionality of the ERM module

[0102] . The FCAPS handler

[0118] is interfacing with the OAM

[0126] via an OAM client.

[0054] The notify handler

[0120] is configured to notify the published one or more events to one or more subscriber microservice (MS) modules. The one or more subscriber MS modules are components that receive notifications about the one or more events from the ERM module

[0102] . Examples of the one or more subscriber MS modules include “User Notification Service” that sends alerts or notifications to users (e.g., email, SMS) when certain events occur, like a user registration or order placement, and “Analytics Service” that processes event data to derive insights or generate reports. For example, it may analyse user registration events to determine trends. In addition, example of the one or more subscriber MS modules may include “Payment Processing Service” that is used for payment events to confirm transactions and may trigger follow-up actions, such as sending receipts or updating user accounts.

[0055] The notify handler

[0120] may send a notification via message, alert, and the like. The notify handler

[0120] may send the notification by parallel message delivery or sequential message delivery.

[0056] The database (DB) client

[0116] is configured to interact with the NoSQL database

[0124] to store a set of transactional logs data.

[0057] The OAM

[0126] is a central connecting point of all the microservices. The microservices may register, deregister and reregister with the OAM

[0126] using the OAM client.

[0058] The NoSQL database

[0124] refers to a non-relational database. The non-relational database stores data in a non-tabular form and is more flexible than a traditional, SQL-based database structure. The NoSQL database

[0124] interacts with the DB client

[0116] to store the list of events, a context metadata information of each of the one or more microservices.

[0059] The CLI

[0128] refers to a text-based interface for a user to interact with the ERM

[0102] . The CLI

[0128] allows users to interact with the ERM

[0102] by entering text based commands in a hardware like a keyboard, and the like. The CLI

[0128] does not use visual elements like icons, etc.

[0060] The MS-a

[0130] , the MS-b

[0132] , and the MS-c

[0134] refers to the subscriber microservice. The event published by the MS-x

[0104] may be routed to at least one of the MS-a

[0130] , the MS- b

[0132] and the MS-c

[0134] based on the event list stored at the ERM

[0102] .

[0061] Referring to FIG.2, an exemplary implementation of an ERM Redundant model

[0200] , in accordance with exemplary implementations of the present disclosure is shown.

[0062] As shown in FIG. 2, an exemplary architecture of the ERM Redundant model

[0200] comprises a user interface (UI)

[0202] or a user experience (UX), an elastic load balancer (ELB) 1

[0204] , an ELB 2

[0206] , an identity and access management (IAM) unit

[0208] , an event routing manager (ERM) unit

[0102] , an ELB 3

[0212] , an ELB 4

[0214] , a microservice system

[0216] , an elastic search database

[0218] , an orchestration manager (OAM) interface

[0126] , and a Central Log Management System (CLMS)

[0222] , wherein all the components are assumed to be connected to each other in a manner as obvious to the person skilled in the art for implementing features of the present disclosure. The microservice system

[0216] may comprise multiple microservice instances a MS 1 [216-1], a MS 2 [216-2], a MS 3 [216-3],….., a MS N [216-N]. The CLMS

[0222] facilitates a centralised process to manage and monitor log information of all microservices. In addition, the CLMS

[0222] helps to view the log or trace in one interface / GUI in a distributed process or microservice deployment.

[0063] The UI

[0202] refers to a system to interact with the system architecture

[0200] by a user. The user may be a system operator, a network consumer, and the like. The UI

[0202] may be one of a graphical user interface (GUI), a command line interface, and the like. In an implementation of the present disclosure, the UI

[0202] is the CLI

[0128] as depicted in FIG.1. The CLI refers to a text-based interface to interact with the system

[0200] as by the user. The user may input text lines called as command lines in the CLI to access the event in the system.

[0064] The ELB 1

[0204] , the ELB 2

[0206] , the ELB 3

[0212] , and the ELB 4

[0214] are exemplary ELBs. The system may include ‘N’ number of ELBs. The ELBs are configured to distribute the load on the microservice instances the MS 1 [216-2], the MS 2 [216-2], …. The MS N [216-N]. The ELBs are further configured to distribute traffic of incoming events based on availability of the microservice instances. The distribution of traffic enhances fault tolerance. The fault tolerance refers to a capability of the microservice system

[0216] to handle failures even when one of the microservice instances fail.

[0065] The IAM unit

[0208] refers to a unit that verifies identity of the user who is trying to access a system, a network or a database. The verification may include entering a password, a biometric, and the like. Based on the authentication, the IAM unit

[0208] may authorise access for the user. The verification and the authorisation ensures that the user who is making the access request getsaccess to the system, and the user has the right level of access to the system, the database, or the network. Further, the IAM unit

[0208] is configured to define roles and access privileges of the user.

[0066] The ERM module

[0102] is a system to route events from one microservice to another efficiently instead of adopting a crisscross model as is implemented in the known in the art inventions, where each of the microservice communicates to the other microservices directly. The ERM

[0102] routes the events between each of the microservices by using a publish subscribe model. The ERM

[0102] maintains a list of a publisher microservice and a subscriber microservice for each event from one or more events. Based on the event list, the ERM

[0102] delivers the events to each of the subscriber microservices.

[0067] The microservice system

[0216] refers to a system to perform a specific function. In one example, the microservice system

[0216] includes one or more microservice instances. The one or more microservice instances handles requests related to the specific function. Each of the microservice instance may be served by at least two ELB units. For instance, the MS 1 [216-1] may be served by the ELB 3

[0212] and the ELB 4

[0214] . The one or more MS instances may have an active status or an inactive status.

[0068] The elastic search database

[0218] refers to a database that organizes data into documents. The documents are grouped into different headers based on characteristics of the data. The elastic search database

[0218] stores, performs searches and analyses the data quickly and in real-time to give a response in milliseconds. The elastic search database

[0218] produces a fast search response based on performing the search in the header instead of the whole data.

[0069] The OAM interface

[0126] is a framework that stores data of the instances of the microservices. The data includes but may not be limited to an internet protocol (IP) address, a port, a server disk location. The OAM interface

[0126] is further configured to maintain a ping-pong communication with all the instances of the microservice system

[0216] . The OAM interface

[0126] maintains the ping-pong communication to check whether an instance is running or is down.

[0070] Referring to FIG.3, an implementation of the ERM method flow

[0300] , in accordance with exemplary implementations of the present disclosure is shown.

[0071] In order to manage event routing, a bootstrap service unit

[0114] of ERM module

[0102] is configured to initiate all modules of ERM module

[0102] . The ERM module

[0102] is further configured to receive an event from a publisher MS1

[0302] and a publisher MS2

[0304] .

[0072] Further, the ERM module

[0102] is configured to publish the event received from the publisher handler

[0108] .

[0073] The ERM module

[0102] is configured to notify via the notify handler

[0118] to at least one of a subscriber MS1

[0306] , a subscriber MS2

[0308] and a subscriber MS3

[0310] based on the list of events and the list of publisher MS and subscriber MS for each of the event from the list of events stored in the NoSQL database

[0124] . If the subscriber MS modules are more than one subscriber MS module for the event, the notify handler

[0506] may be configured to send the notification via parallel message delivery. In another example, the notification may be sent via sequential delivery. The parallel delivery refers to sending the notification to each of the one or more subscriber MS modules together at same time, whereas the sequential delivery refers to delivering the notification in a pre-defined sequence. The predefined sequence may be defined by the user.

[0074] The notification may be provided to the one or more subscriber MS based on a context metadata information provided by the one or more subscriber MS to the ERM module

[0102] while subscribing to the event received from the publish handler

[0108] .

[0075] For instance, as shown in FIG.3, the subscriber MS1

[0306] and the subscriber MS3

[0308] are configured to be routed for event 1 published by the publisher MS1

[0302] , the ERM module 1

[0002] may send the notification via the notify handler

[0120] to both the subscriber MS via parallel message delivery or sequential message delivery. Similarly, the subscriber MS3

[0310] is configured to be routed for event 2 published by the publisher MS2

[0304] , a notification may be sent to the subscriber MS3

[0310] for the event2.

[0076] The FCAPS handler

[0118] is configured to manage a set of performance counter data and a set of alarm data. The set of performance counter data and the set of alarm data are associated with functions of an operations and management (OAM) module

[0126] as depicted in FIG.1. Since the OAM module

[0126] is the central connecting point for all the microservices, faults, configuration, accounting, performance and security of all the microservices may be monitored via the OAM module

[0126] . In one example, the FCAPS handler

[0118] detects and manages faultsat each of the microservice. Further the FCAPS handler

[0118] may monitor and manage changes in configuration of each of the microservice. Further, the FCAPS handler

[0118] may track usage data and allocate costs to the user accordingly. Furthermore, the FCAPS handler

[0118] may monitor performance metrics like one of a latency, bandwidth, etc. to ensure that each of the microservice is performing properly. Further, the FCAPS handler

[0118] may implement security policies and monitor each of the microservice for any potential breach to ensure security of the ERM module

[0102] . The set of performance counter data corresponds to collection and analysis of the performance metrics and the set of alarm data refers to monitoring faults at each of the microservice. Based on detection of a fault, the FCAPS handler

[0118] may generate an alarm to alert the user or to the OAM module

[0126] to fix the faults.

[0077] Furthermore, an ERM server is further configured to store transactional logs in a database server (not shown in FIG.3).

[0078] For each of the one or more events transmitted by the publishing MS1

[0302] or the publishing MS2

[0304] , the publish handler

[0108] is configured to send a response to the publishing MS1

[0302] or the publishing MS2

[0304] . The response includes but may not be limited to a delivery report to confirm delivery of the one or more events. In case of a timeout for the published event from the one or more subscriber MS modules, the subscribe handler

[0508] attempts re-delivery for a pre-defined number of times. The pre-defined number of times may be defined by the ERM module

[0102] . In case the delivery of the published event fails even after retrying for the pre- defined number of times, the publish handler

[0108] informs the same to the one or more publishing MS modules in the response.

[0079] In one implementation, if the subscriber MS3

[0310] sends a request to the ERM module

[0102] to remove the subscriber MS3

[0310] from the event, the context metadata is used to identify the event from which subscription needs to be removed. By referencing an identifier of the subscriber MS3

[0310] , the context metadata associated with the subscriber MS3

[0310] , the subscriber MS3

[0310] may efficiently locate and unsubscribe the subscriber MS3

[0310] from the event to ensure no further notifications is sent.

[0080] Referring to FIG.4, an exemplary block diagram of a computing device

[0400] upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure. In an implementation, the computing device

[0400] may also implement a method for managing events using an event routing management (ERM) moduleutilising the system. In another implementation, the computing device

[0400] itself implements the method for managing events using an event routing management (ERM) module, using one or more units configured within the computing device

[0400] , wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.

[0081] The computing device

[0400] may include a bus

[0402] or other communication mechanism for communicating information, and a hardware processor

[0404] coupled with bus

[0402] for processing information. The hardware processor

[0404] may be, for example, a general-purpose microprocessor. The computing device

[0400] may also include a main memory

[0406] , such as a random access memory (RAM), or other dynamic storage device, coupled to the bus

[0402] for storing information and instructions to be executed by the processor

[0404] . The main memory

[0406] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the processor

[0404] . Such instructions, when stored in non-transitory storage media accessible to the processor

[0404] , render the computing device

[0400] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device

[0400] further includes a read only memory (ROM)

[0408] or other static storage device coupled to the bus

[0402] for storing static information and instructions for the processor

[0404] .

[0082] A storage device

[0410] , such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus

[0402] for storing information and instructions. The computing device

[0400] may be coupled via the bus

[0402] to a display

[0412] , such as a cathode ray tube (CRT), Liquid crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying information to a computer user. An input device

[0414] , including alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus

[0402] for communicating information and command selections to the processor

[0404] . Another type of user input device may be a cursor controller

[0416] , such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor

[0404] , and for controlling cursor movement on the display

[0412] . This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.

[0083] The computing device

[0400] may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and / or program logic which in combination with the computing device

[0400] causes or programs the computing device

[0400] to be a special-purpose machine. According to one implementation, the techniques herein are performed by the computing device

[0400] in response to the processor

[0404] executing one or more sequences of one or more instructions contained in the main memory

[0406] . Such instructions may be read into the main memory

[0406] from another storage medium, such as the storage device

[0410] . Execution of the sequences of instructions contained in the main memory

[0406] causes the processor

[0404] to perform the process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.

[0084] The computing device

[0400] also may include a communication interface

[0418] coupled to the bus

[0402] . The communication interface

[0418] provides a two-way data communication coupling to a network link

[0420] that is connected to a local network

[0422] . For example, the communication interface

[0418] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface

[0418] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface

[0418] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0085] The computing device

[0400] can send messages and receive data, including program code, through the network(s), the network link

[0420] and the communication interface

[0418] . In an example, a server

[0430] might transmit a requested code for an application program through the Internet

[0428] , the ISP

[0426] , the local network

[0422] , the host

[0424] and the communication interface

[0418] . The received code may be executed by the processor

[0404] as it is received, and / or stored in the storage device

[0410] , or other non-volatile storage for later execution.

[0086] The present disclosure is implemented by a system

[0400] (as shown in FIG. 4). In an implementation, the system

[0400] may include the computing device

[0400] (as shown in FIG.4). It is further noted that the computing device

[0400] is able to perform the steps of a method

[0500] (as shown in FIG.5).

[0087] Referring to FIG.5, an exemplary block diagram of a system

[0500] for managing events using an event routing management (ERM) module is shown, in accordance with the exemplary implementations of the present disclosure. The system

[0500] comprises at least one elastic loadbalancer (ELB) unit

[0502] , at least one publish handler

[0504] , at least one notify handler

[0506] , at least one subscribe handler

[0508] , at least one storage unit

[0510] and at least one fault, configuration, accounting, performance and security (FCAPS) module

[0512] . Also, all of the components / units of the system

[0500] are assumed to be connected to each other unless otherwise indicated below. As shown in the figures all units shown within the system should also be assumed to be connected to each other. Also, in FIG. 5 only a few units are shown, however, the system

[0500] may comprise multiple such units or the system

[0500] may comprise any such numbers of said units, as required to implement the features of the present disclosure. Further, in an implementation, the system

[0500] may be present in a user device to implement the features of the present disclosure. The system

[0500] may be a part of the user device / or may be independent of but in communication with the user device (may also referred herein as a UE). In another implementation, the system

[0500] may reside in a server or a network entity. In yet another implementation, the system

[0500] may reside partly in the server / network entity and partly in the user device.

[0088] The system

[0500] is configured for managing events using an event routing management (ERM) module

[0102] , with the help of the interconnection between the components / units of the system

[0500] . In one example, a first instance of the ERM module

[0102] is managing the events. In another example, if the first instance of the ERM module

[0102] goes down, a second instance may be configured to manage the events.

[0089] The ELB unit

[0502] is configured to receive one or more events from one or more publishing microservice (MS) modules. The one or more publishing MS modules corresponds to microservices that generate and send the one or more events to the Event Routing Manager (ERM) module

[0502] as depicted in FIG. 1. The one or more events are categorized based on at least a type or purpose. The type of the one or more events includes but may not be limited to a user registered event, a payment event, an order placed event. For example, the one or more publishing MS modules detects a new user getting registered to a system, the one or more publishing MS module is configured to detect ‘a user registered’. The user registered event may be required by one or more subscriber microservice (MS) modules to perform a function based on the registration of the user. In an embodiment, the type of the one or more events defines what each event represents. Further, the purpose of the one or more events (e.g., Transactional, Informational, System Event) categorizes events based on their role, providing context of the one or more events. In general, the context of an event refers to the specific circumstances, conditions, and attributes surrounding its occurrence. The context of the one or more events facilitates interpreting theevent's significance and implications. The subscriber MS modules refer to the microservices that are configured to perform specific task based on the event. For instance, a microservice A may send a welcome message to the user, a microservice B needs to monitor usage of the system by the user, etc. The ELB module

[0502] transmits the one or more events to the publish handler

[0504] .

[0090] The publish handler

[0504] is configured to publish the received one or more events. To publish the received one or more events, the publisher handler

[0504] may receive and identify the one or more events.

[0091] The notify handler

[0506] is configured to notify the published one or more events to the one or more subscriber microservice (MS) modules. In one example, a notification may be sent via a message, alert, and the like. In one example, if the subscriber MS modules are more than one subscriber MS module for the event, the notify handler

[0506] may be configured to send the notification via parallel message delivery. In another example, the notification may be sent via sequential delivery. The parallel delivery refers to sending the notification to each of the one or more subscriber MS modules together at same time, whereas the sequential delivery refers to delivering the notification in a pre-defined sequence. The predefined sequence may be defined by the user.

[0092] When the one or more subscriber MS modules subscribes to the ERM module

[0102] , the one or more subscriber MS modules are configured to provide a set of context metadata information based on at least one of a subscribing action, and an unsubscribing action. The set of context metadata is provided to the ERM module

[0102] using the subscribe handler

[0508] . The set of context metadata information corresponds to information required to identify nature or context of the one or more events. The set of context metadata includes but may not be limited to at least end point information associated with the one or more events, priority level of the one or more events, and subscriber ID for each of the one or more events. The endpoint information refers to an identifier of the endpoint, where the endpoint may be any physical device connected to the network, including computers, laptops, mobile phones. An example of the endpoint information may be an internet protocol (IP) address.

[0093] For example, if a payment event is triggered by a user's mobile app, the endpoint information may include the mobile device's IP address and potentially other identifiers (like device ID). In an example, the identifier of the endpoint may lie within the context metadata that the subscriber MS module provide to the ERM module

[0102] through the subscribe handler

[0508] .The identifier is not explicitly defined in a specific physical location, but rather are part of a data structure managed by the subscribe handler

[0508] .

[0094] In an example, the event can be defined as a notification of a significant change or occurrence within the system

[0500] that other components or services might be interested in. Examples of events include user actions (like signing up), system changes (like database updates), or external triggers (like payment confirmations). Further, in an embodiment, event may be of several types and may vary in nature (as defined above). Some of the events may be transactional (e.g., a completed order), while others could be informational (e.g., a service being updated). Each event carries data relevant to the change, which is essential for subscribers to react appropriately.

[0095] The at least one of the subscribing action and the unsubscribing action is associated with an event from the one or more events. The storage unit

[0510] stores a list of one or more publisher MS modules and the one or more subscriber MS modules for each event from one or more events. Based on the event list and the published one or more events, the one or more subscriber MS modules may subscribe or unsubscribe to the ERM module

[0102] .

[0096] When the one or more subscriber MS modules wants to subscribe to an event, the one or more subscriber MS modules may communicate with the subscribe handler

[0508] . The one or more subscriber MS modules may send a request to the ERM module

[0102] that includes the context metadata. The context metadata is created and sent to the ERM module

[0102] , enabling the system to register the microservice as a subscriber to specific events. The ERM module

[0102] stores the context metadata to route notifications. The context metadata are stored in the storage unit

[0510] .

[0097] When the one or more subscriber MS modules wants to unsubscribe from the event, the one or more subscriber MS modules interacts with the ERM module via the subscribe handler

[0508] . The one or more subscriber MS modules sends a request to the remove subscription for the event. During unsubscribing, the context metadata is used to identify the event from which subscription needs to be removed. By referencing an identifier of the one or more subscriber MS modules and the context metadata associated with the one or more subscriber MS modules, the subscribe handler

[0508] may efficiently locate and unsubscribe the one or more subscriber MS modules from the event to ensure no further notifications is sent.

[0098] In an embodiment, the subscribe handler

[0508] is configured to check a status of the one or more subscriber MS modules by identifying a first request from the one or more subscriber MSmodules for unsubscribing from a first target event. In addition, the subscribe handler

[0508] is configured to remove a set of target context metadata information. The set of target context metadata information is associated with identification of the first request. The set of target context metadata information associated with identification of the first request refers to how specific pieces of context metadata are linked to a particular action (like an unsubscribe request) made by the subscriber microservice (MS) module. The target context metadata may include all relevant details about the event, such as: “Subscriber ID” that identifies which subscriber made the request, “Event Type” that specifies which event the unsubscribe action pertains to, “Timestamp” that indicates when the request was made. The identification of the first request means that the system

[0500] may track and distinguish this particular unsubscribe request from others ensuring that when the subscriber requests to unsubscribe from an event, the system

[0500] can accurately retrieve and reference the associated metadata to process the request effectively.

[0099] The FCAPS module

[0512] is configured to manage a set of performance counter data and a set of alarm data. The set of performance counter data and the set of alarm data are associated with functions of an operations and management (OAM) module

[0126] as depicted in FIG.1. Since the OAM module

[0126] is the central connecting point for all the microservices, faults, configuration, accounting, performance and security of all the microservices may be monitored via the OAM module

[0126] . In one example, the FCAPS module

[0512] detects and manages faults at each of the microservice. Further the FCAPS module

[0512] may monitor and manage changes in configuration of each of the microservice. Further, the FCAPS module

[0512] may track usage data and allocate costs to the user accordingly. Furthermore, the FCAPS module

[0512] may monitor performance metrics like one of a latency, bandwidth, etc. to ensure that each of the microservice is performing properly. Further, the FCAPS module

[0512] may implement security policies and monitor each of the microservice for any potential breach to ensure security of the ERM module

[0102] . The set of performance counter data corresponds to collection and analysis of the performance metrics and the set of alarm data refers to monitoring faults at each of the microservice. Based on detection of a fault, the FCAPS module

[0512] may generate an alarm to alert the user or to the OAM module

[0126] to fix the faults.

[0100] The storage unit

[0510] stores in a database, a set of transactional logs data associated with the one or more events. The set of transactional logs refers to a list of one or more publisher MS modules and the one or more subscriber MS modules for each event from one or more events. Based on the event list and the published one or more events, the one or more subscriber MS modules may subscribe or unsubscribe to the ERM module

[0102] .

[0101] Further in one example, for each of the one or more events transmitted by the one or more publishing MS modules, the publish handler

[0504] is configured to send a response to the one or more publishing MS modules. The response includes but may not be limited to a delivery report to confirm delivery of the one or more events. In case of a timeout for the published event from the one or more subscriber MS modules, the subscribe handler

[0508] attempts re-delivery for a pre-defined number of times. The pre-defined number of times may be defined by the system

[0500] . In case the delivery of the published event fails even after retrying for the pre-defined number of times, the publish handler

[0504] informs the same to the one or more publishing MS modules in the response.

[0102] Referring to FIG.6, an exemplary method flow diagram

[0600] for managing events using an event routing management (ERM) module, in accordance with exemplary implementations of the present disclosure is shown. In an implementation the method

[0600] is performed by the system

[0500] . Further, in an implementation, the system

[0500] may be present in a server device to implement the features of the present disclosure. Also, as shown in FIG.6, the method

[0600] starts at step

[0602] .

[0103] At step

[0604] , the method

[0600] comprises receiving, by an elastic load balancer (ELB) unit

[0502] , from one or more publishing microservice (MS) modules, one or more events. The one or more publishing MS modules corresponds to microservices that generate and send the one or more events to the Event Routing Manager (ERM) module

[0502] as depicted in FIG.1. The one or more events are categorized based on at least a type or purpose. The type of the one or more events includes but may not be limited to a user registered event, a payment event, an order placed event. For example, the one or more publishing MS modules detects a new user getting registered to a system, the one or more publishing MS module is configured to detect ‘a user registered’. The user registered event may be required by one or more subscriber microservice (MS) modules to perform a function based on the registration of the user. The subscriber MS modules refers to the microservices that are configured to perform specific task based on the event. For instance, a microservice A may send a welcome message to the user, a microservice B needs to monitor usage of the system by the user, etc. The ELB module

[0502] transmits the one or more events to the publish handler

[0504] .

[0104] At step

[0606] , the method

[0600] comprises publishing, by a publish handler

[0504] , the received one or more events facilitating dynamic event subscription management. To publish thereceived one or more events, the publish handler

[0504] may receive and identify the one or more events. In an embodiment, the dynamic event subscription management facilitates flexible subscription to events, allowing subscriber services to dynamically manage their interest in certain events, thereby enhancing responsiveness and adaptability to changing business needs. In other words, the dynamic event subscription management allows services to adjust their subscriptions to events based on their current needs or conditions. In an example, dynamic event subscription herein refers to as analytics service that is dynamically subscribed to following events: order creation, order update, order cancellation, and the like.

[0105] Next at step

[0608] , the method

[0600] comprises notifying, by a notify handler

[0506] , the published one or more events to one or more subscriber microservice (MS) modules.

[0106] In one example, a notification may be sent via a message, alert, and the like. In one example, if the subscriber MS modules are more than one subscriber MS module for the event, the notify handler

[0506] may be configured to send the notification via parallel message delivery. In another example, the notification may be sent via sequential delivery. The parallel delivery refers to sending the notification to each of the one or more subscriber MS modules together at same time, whereas the sequential delivery refers to delivering the notification in a pre-defined sequence. The predefined sequence may be defined by the user.

[0107] When the one or more subscriber MS modules subscribes to the ERM module

[0102] , the one or more subscriber MS modules are configured to provide a set of context metadata information based on at least one of a subscribing action, and an unsubscribing action. The set of context metadata is provided to the ERM module

[0102] using the subscribe handler

[0508] . The set of context metadata information corresponds to information required to identify nature or context of the one or more events. The set of context metadata includes but may not be limited to at least end point information associated with the one or more events, priority level of the one or more events, and subscriber ID for each of the one or more events. The endpoint information refers to an identifier of the endpoint, where the endpoint may be any physical device connected to the network, including computers, laptops, mobile phones. An example of the endpoint information may be an internet protocol (IP) address. In an example, the identifier of the endpoint may lie within the context metadata that the subscriber MS module provide to the ERM module

[0102] through the subscribe handler

[0508] . The identifier is not explicitly defined in a specific physical location, but rather are part of a data structure managed by the subscribe handler

[0508] .

[0108] The at least one of the subscribing action and the unsubscribing action is associated with an event from the one or more events. The subscribe handler

[0508] is configured to maintain a list of one or more publisher MS modules and the one or more subscriber MS modules for each event from one or more events. Based on the event list and the published one or more events, the one or more subscriber MS modules may subscribe or unsubscribe to the ERM module

[0102] .

[0109] When the one or more subscriber MS modules wants to subscribe to an event, the one or more subscriber MS modules may communicate with the subscribe handler

[0508] . The one or more subscriber MS modules may send a request to the ERM module

[0102] that includes the context metadata. The context metadata is created and sent to the ERM module

[0102] , enabling the system to register the microservice as a subscriber to specific events. The ERM module

[0102] stores the context metadata to route notifications. The context metadata are stored in the storage unit

[0510] .

[0110] When the one or more subscriber MS modules wants to unsubscribe from the event, the one or more subscriber MS modules interacts with the ERM module via the subscribe handler

[0508] . The one or more subscriber MS modules sends a request to the remove subscription for the event. During unsubscribing, the context metadata is used to identify the event from which subscription needs to be removed. By referencing an identifier of the one or more subscriber MS modules and the context metadata associated with the one or more subscriber MS modules, the subscribe handler

[0508] may efficiently locate and unsubscribe the one or more subscriber MS modules from the event to ensure no further notifications is sent.

[0111] The FCAPS module

[0512] is configured to manage a set of performance counter data and a set of alarm data. The set of performance counter data and the set of alarm data are associated with functions of an operations and management (OAM) module

[0126] as depicted in FIG.1. Since the OAM module

[0126] is the central connecting point for all the microservices, faults, configuration, accounting, performance and security of all the microservices may be monitored via the OAM module

[0126] . In one example, the FCAPS module

[0512] detects and manages faults at each of the microservice. Further the FCAPS module

[0512] may monitor and manage changes in configuration of each of the microservice. Further, the FCAPS module

[0512] may track usage data and allocate costs to the user accordingly. Furthermore, the FCAPS module

[0512] may monitor performance metrics like one of a latency, bandwidth, etc. to ensure that each of the microservice is performing properly. Further, the FCAPS module

[0512] may implement security policies and monitor each of the microservice for any potential breach to ensure security of the ERM module

[0102] . The set of performance counter data corresponds to collection and analysis ofthe performance metrics and the set of alarm data refers to monitoring faults at each of the microservice. Based on detection of a fault, the FCAPS module

[0512] may generate an alarm to alert the user or to the OAM module

[0126] to fix the faults.

[0112] Next at step

[0610] , the method

[0600] comprises storing, by the storage unit

[0510] , in a database, a set of transactional logs data associated with the one or more events. The set of transactional logs refers to a list of one or more publisher MS modules and the one or more subscriber MS modules for each event from one or more events. Based on the event list and the published one or more events, the one or more subscriber MS modules may subscribe or unsubscribe to the ERM module

[0102] .

[0113] Further, in one example, for each of the one or more events transmitted by the one or more publishing MS modules, the publish handler

[0504] is configured to send a response to the one or more publishing MS modules. The response includes but may not be limited to a delivery report to confirm delivery of the one or more events. In case of a timeout for the published event from the one or more subscriber MS modules, the subscribe handler

[0508] attempts re-delivery for a pre-defined number of times. The pre-defined number of times may be defined by the system

[0500] . In case the delivery of the published event fails even after retrying for the pre-defined number of times, the publish handler

[0504] informs the same to the one or more publishing MS modules in the response.

[0114] The method

[0600] terminates at step

[0612] .

[0115] The present disclosure further discloses a non-transitory computer readable storage medium storing instructions for managing events using an event routing management (ERM) module

[0102] , the instructions include executable code which, when executed by one or more units of a system, cause the elastic load balancer (ELB) unit

[0502] to receive, from one or more publishing microservice (MS) modules, one or more events. The instructions when executed by the system further cause the publish handler unit

[0504] to publish the received one or more events facilitating dynamic event subscription management. The instructions when executed by the system further cause the notify handler unit

[0506] to notify the published one or more events to one or more subscriber microservice (MS) modules. The instructions when executed by the system further cause the storage unit

[0510] to store, in a database, a set of transactional logs data associated with the one or more events.

[0116] As is evident from the above, the present disclosure provides a technically advanced solution for managing events using an event routing management (ERM) module. The present solution provides a system and a method for event routing management. The system and method provided by the present solution acts as a central service to keep information of all events in a network. The present disclosure further enables storing transactional logs in a database server, which would be helpful to debug in case of event failure. The system and method allows addition of new events to an ERM server dynamically, thereby reducing code overhead in the event any microservice server wants to use same event functionality which is already being used by other microservice server. Further, the present disclosure provides a solution that enables parallel or sequential message delivery can be defined for each event that has multiple subscriber server. The present disclosure further provides a solution that supports redundancy in the event one ERM server goes down.

[0117] While considerable emphasis has been placed herein on the disclosed implementations, it will be appreciated that many implementations can be made and that many changes can be made to the implementations without departing from the principles of the present disclosure. These and other changes in the implementations of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

[0118] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various components / units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.

Claims

We Claim:

1. A method for managing events using an event routing management (ERM) module [102], the method comprising: - receiving, by an elastic load balancer (ELB) unit [502], from one or more publishing microservice (MS) modules, one or more events; - publishing, by a publish handler [504], the received one or more events facilitating dynamic event subscription management; - notifying, by a notify handler [506], the published one or more events to one or more subscriber microservice (MS) modules; and - storing, by a storage unit [510], in a database, a set of transactional logs data associated with the one or more events.

2. The method as claimed in claim 1, wherein the one or more publishing MS modules correspond to microservices that generate and send the one or more events to the Event Routing Manager (ERM) module [102].

3. The method as claimed in claim 1, wherein the step of notifying, by the notify handler [506], the published one or more events to the one or more subscriber MS modules is based on a set of context metadata information associated with each of the one or more events.

4. The method as claimed in claim 3, wherein the set of context metadata information comprises details to identify context of the one or more events, wherein the set of context metadata comprises at least an end point information associated with the one or more events, priority level of the one or more events, and subscriber ID for each of the one or more events.

5. The method as claimed in claim 1, wherein the one or more events are categorized based on at least a type or purpose, wherein the one or more events comprises at least one of: a user registered event, a payment event, and an order placed event.

6. The method as claimed in claim 3, wherein the method comprises providing, by the one or more subscriber MS modules, to the ERM module [102] using a subscribe handler [508], wherein the set of context metadata information based on at least one of a subscribing action, and an unsubscribing action, and wherein the at least one of the subscribing action, and the unsubscribing action is associated with an event from the one or more events.

7. The method as claimed in claim 3, wherein the method comprises receiving, by each of the one or more subscriber MS modules, a notification associated with one or more target events from the published one or more events, and wherein the notification is based on the subscribing action associated with the one or more target events.

8. The method as claimed in claim 3, wherein the method comprises checking, by the subscribe handler [508], a status of the one or more subscriber MS modules, and wherein the step of checking the status of the one or more subscriber MS modules comprises identifying, by the subscribe handler [508], a first request from the one or more subscriber MS modules for unsubscribing from a first target event.

9. The method as claimed in claim 6, wherein the method comprises removing, by the subscribe handler [508], a set of target context metadata information, and wherein the set of target context metadata information is associated with identification of the first request.

10. The method as claimed in claim 1, wherein the method comprises managing, by a fault, configuration, accounting, performance and security (FCAPS) unit, a set of performance counter data and a set of alarm data, and wherein the set of performance counter data and the set of alarm data are associated with functions of an operations and management (OAM) module connected with at least the ERM module [102].

11. The method as claimed in claim 1, wherein the set of transactional logs data comprises at least one of: context metadata information, FCAPS performance counter data, FCAPS alarm data, types of microservice nodes, registration data of the microservice nodes, deregistration data of the microservice nodes, subscription data of the microservice nodes, and unsubscribe data of the microservice nodes for the one or more events.

12. A system for managing events using an event routing management (ERM) module [102], the system comprising: - an elastic load balancer (ELB) unit [502] configured to receive, from one or more publishing microservice (MS) modules, one or more events; - a publish handler [504] connected to at least the ELB unit [502], and configured to publish the received one or more events facilitating dynamic event subscription management;- a notify handler [506] connected to at least the publish handler [504], and configured to notify the published one or more events to one or more subscriber microservice (MS) modules; and - a storage unit [510] connected to at least the notify handler [506], and configured to store, in a database, a set of transactional logs data associated with the one or more events.

13. The system as claimed in claim 12, wherein the one or more publishing MS modules correspond to microservices that generate and send the one or more events to the Event Routing Manager (ERM) module [102].

14. The system as claimed in claim 12, wherein the notify handler [506] is configured to notify the published one or more events to the one or more subscriber MS modules, based on a set of context metadata information associated with each of the one or more events.

15. The system as claimed in claim 12, wherein the set of context metadata information comprises details to identify nature or context of the one or more events, wherein the set of context metadata comprises at least end point information associated with the one or more events, priority level of the one or more events, and subscriber ID for each of the one or more events.

16. The system as claimed in claim 12, wherein the one or more events are categorized based on at least a type or purpose, wherein the one or more events comprises at least one of: a user registered event, a payment event, and an order placed event.

17. The system as claimed in claim 12, wherein the one or more subscriber MS modules are configured to provide, to the ERM module [102] using a subscribe handler [508], wherein the set of context metadata information based on at least one of a subscribing action, and an unsubscribing action, and wherein the at least one of the subscribing action and the unsubscribing action is associated with an event from the one or more events.

18. The system as claimed in claim 14, wherein each of the one or more subscriber MS modules is configured to receive a notification associated with one or more target events from the published one or more events, and wherein the notification is based on the subscribing action associated with the one or more target events.

19. The system as claimed in claim 17, wherein the subscribe handler [508] is configured to check a status of the one or more subscriber MS modules, and wherein, to check the status of the one or more subscriber MS modules, the subscribe handler [508] is configured to identify a first request from the one or more subscriber MS modules for unsubscribing from a first target event.

20. The system as claimed in claim 17, wherein the subscribe handler [508] is configured to remove a set of target context metadata information, and wherein the set of target context metadata information is associated with an identification of the first request.

21. The system as claimed in claim 12, wherein the system comprises a fault, configuration, accounting, performance and security (FCAPS) module [512], wherein the FCAPS module [512] is configured to manage a set of performance counter data and a set of alarm data, and wherein the set of performance counter data and the set of alarm data are associated with functions of an operations and management (OAM) module connected with at least the ERM module [102].

22. The system as claimed in claim 12, wherein the set of transactional logs data comprises at least one of: context metadata information, FCAPS performance counter data, FCAPS alarm data, type of microservice nodes, registration data of the microservice nodes, deregistration data of the microservice nodes, subscription data of the microservice nodes, and unsubscribe data of the microservice nodes for the one or more events.

23. A non-transitory computer-readable storage medium storing instructions for managing events using an event routing management (ERM) module [102], the storage medium comprising executable code which, when executed by one or more units of a system [300], causes: - an elastic load balancer (ELB) unit [502] to receive, from one or more publishing microservice (MS) modules, one or more events; - a publish handler [504] connected to at least the ELB unit [502], to publish the received one or more events facilitating dynamic event subscription management; - a notify handler [506] connected to at least the publish handler [504], to notify the published one or more events to one or more subscriber microservice (MS) modules; and - a storage unit [510] connected to at least the notify handler [506], to store, in a database, a set of transactional logs data associated with the one or more events.

Images