DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
METHOD AND SYSTEM FOR RECOVERY MANAGEMENT IN A NETWORK
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3.PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to the field of telecommunications and network management, more particularly relates to recovery management in a network.
BACKGROUND OF THE INVENTION
[0002] In a telecommunication network, while processing a service API request, there may exist error conditions or exceptional conditions. It is preferred to automatically identify those error conditions and automatically derive solutions from those error conditions. However, identification of the errors (using error codes) while processing requests is a major challenge. Further, challenges also exist with respect to identification of resolution steps corresponding to the errors.
[0003] There is, therefore, a need for solutions for automated managing of recovery from unfavorable system aware situation. The system aware situation refers to situations where the system is aware of the internal conditions or state, including errors or failures.
SUMMARY OF THE INVENTION
[0004] One or more embodiments of the present invention provides a method and a system for recovery management in a network.
[0005] In one aspect of the present invention, the method for recovery management in a network is disclosed. The method includes the step of receiving one or more workflows for each of a one or more Application Programming Interfaces (APIs) from a user interface. The method further includes the step of analysing each of the one or more APIs during execution to detect one of an error and a failure in the execution of the one or more workflows of each of the one or more APIs. The method further includes the step of initiating one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows.
[0006] In one embodiment, wherein the one or more recovery steps, includes at least one of but not limited to, resource reallocation, state synchronization, failover activation, performance tuning, dependency checking, connection re-establishment, service deactivation and reconfiguration.
[0007] In one embodiment, the one or more workflows comprises one or more steps for each of a one or more scenarios, and wherein the one or more scenarios pertains to at least one of a consumer onboarding, a consumer offboarding, a subscription update, and a subscription deletion.
[0008] In one embodiment, on receiving the one or more workflows, the method comprises the step of configuring, by the one or more processors, conditions corresponding to one of the errors and the failure in the one or more workflows.
[0009] In an embodiment, the conditions include at least one of, but not limited to, retry condition, fallback procedure, error logging, error handling routine, component isolation, and traffic rerouting.
[0010] In one embodiment, the each of the one of the errors and the failures comprises one of transaction failure, system failure, system error, local error, network failure, and data corruption.
[0011] In one embodiment, upon initiating, the one or more recovery steps, the method comprises the step of transmitting, by the one or more processors, one of a notification and an alert indicating one of the errors and the failures in the execution of the one or more workflows of each of the one or more APIs.
[0012] In another aspect of the present invention, the system for recovery management in the network is disclosed. The system includes a receiving unit configured to receive one or more workflows for each of a one or more Application Programming Interfaces (APIs) from a user interface. The system further includes an analysing unit configured to analyse each of the one or more APIs during execution to detect one of an error and failure in the execution of the one or more workflows of each of the one or more APIs. The system further includes an initiating unit configured to initiate, one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows.
[0013] In another aspect of the present invention, a User Equipment (UE) is disclosed. One or more primary processors of the UE is communicatively coupled to one or more processors. The one or more primary processors are coupled with a memory. The memory stores instructions which when executed by the one or more primary processors causes the UE to transmit, one or more workflows for each of a one or more Application Programming Interfaces (API) via a user interface of the UE.
[0014] In yet another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by a processor causes the processor to, receive, one or more workflows for each of a one or more Application Programming Interfaces (API) from a user interface. The processor is further configured to analyse each of the one or more APIs during execution to detect one of an error and failure in the execution of the one or more workflows of each of the one or more APIs. The processor is further configured to initiate one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows.
[0015] The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS
[0016] 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. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0017] FIG. 1 is an exemplary block diagram of a communication system for recovery management in a network, according to one or more embodiments of the present disclosure;
[0018] FIG. 2 is an exemplary block diagram of a system for recovery management in the network, according to one or more embodiments of the present disclosure;
[0019] FIG. 3 is a schematic representation of a workflow of the system of FIG. 2 communicably coupled with a User equipment (UE), according to one or more embodiments of the present disclosure
[0020] FIG. 4 is an exemplary diagram of an architecture of the system of the FIG. 2, according to one or more embodiments of the present disclosure;
[0021] FIG. 5 is a signal flow diagram for recovery management in a network, according to one or more embodiments of the present disclosure; and
[0022] FIG. 6 is a flow chart illustrating a method for recovery management in a network, according to one or more embodiments of the present disclosure.
[0023] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0024] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0025] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0026] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0027] The present disclosure addresses the challenges faced in established technologies for recovery management in a network associated with handling Application Program Interface (API) service requests. The present invention provides an auto-detection of unfavorable negative cases by enabling real-time identification of errors or exceptions as they occur. The present invention facilitates the automatic resolution of errors via a predefined workflow. Due to performing automatic resolution, the present invention is less complex and facilitates consistent and efficient error handling. The present invention incorporates workflow-based execution for error detection and resolution, by providing a systematic approach to managing exceptions.
[0028] Referring to FIG. 1, FIG. 1 illustrates an exemplary block diagram of a communication system 100 for recovery management in a network 105. The communication system 100 includes a network 105, a User Equipment (UE) 110, a server 115, and a system 120. The UE 110 aids a user to interact with the system 120.
[0029] For the purpose of description and explanation, the description will be explained with respect to the UE 110, or to be more specific will be explained with respect to a first UE 110a, a second UE 110b, and a third UE 110c, and should nowhere be construed as limiting the scope of the present disclosure. Each of the first UE 110a, the second UE 110b, and the third UE 110c is configured to connect to the server 115 via the network 105. In alternate embodiments, the UE 110 may include a plurality of UEs as per the requirement. For ease of reference, each of the first UE 110a, the second UE 110b, and the third UE 110c, will hereinafter be collectively and individually referred to as the “User Equipment (UE) 110”.
[0030] In an embodiment, the UE 110 is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as smartphones, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device.
[0031] The network 105 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 105 may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, a VOIP or some combination thereof.
[0032] The network 105 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0033] The communication system 100 includes the server 115 accessible via the network 105. The server 115 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise side, a defense facility side, or any other facility that provides service.
[0034] The communication system 100 further includes the system 120 communicably coupled to the server 115 and the UE 110 via the network 105. The system 120 is adapted to be embedded within the server 115 or is embedded as the individual entity. However, for the purpose of description, the system 120 is illustrated as remotely coupled with the server 115, without deviating from the scope of the present disclosure.
[0035] Operational and construction features of the system 120 will be explained in detail with respect to the following figures.
[0036] FIG. 2 illustrates an exemplary block diagram of the system 120 for the recovery management in the network 105, according to one or more embodiments of the present disclosure.
[0037] As per the illustrated embodiment, the system 120 includes one or more processors 205, a memory 210, a UI 215 and a database 220. For the purpose of description and explanation, the description will be explained with respect to one processor 205 and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the system 120 may include more than one processor 205 as per the requirement of the network 105. The one or more processors 205, hereinafter referred to as the processor 205 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions.
[0038] As per the illustrated embodiment, the processor 205 is configured to fetch and execute computer-readable instructions stored in the memory 210. The memory 210 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium. The memory 210 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0039] In an embodiment, the UI 215 includes a variety of interfaces, for example, interfaces for data input and output devices, referred to as Input/Output (I/O) devices, storage devices, and the like. The UI 215 facilitates communication of the system 120. In one embodiment, the UI 215 provides a communication pathway for one or more components of the system 120.
[0040] In an embodiment, the database 220 is one of, but not limited to, a Elasticsearch database, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 220 types are non-limiting and may not be mutually exclusive e.g., the database can be both commercial and cloud-based, or both relational and open-source, etc.
[0041] The processor 205 includes one or more modules. In one embodiment, the one or more modules includes, but not limited to, a receiving unit 225, an analysing unit 230, a configuration unit 235, an initiating unit 240, a transmittal unit 245, a retrieving unit 250, a selecting unit 255, and a managing unit 260 communicably coupled to each other.
[0042] The receiving unit 225, the analysing unit 230, the configuration unit 235, the initiating unit 240, the transmittal unit 245, the retrieving unit 250, the selecting unit 255, and the managing unit 260 in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 205. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 205 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for processor 205 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor 205. In such examples, the system 120 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 120 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.
[0043] In an embodiment, the receiving unit 225 is configured to receive one or more workflows for each of a one or more Application Programming Interfaces (APIs) from the UI 215.
[0044] In an alternate embodiment, the receiving unit 225 is configured to receive the one or more workflows for each of a one or more Application Programming Interfaces (APIs) from the UE 110.
[0045] The API refers to a service interface. The one or more APIs follow received one or more workflows to perform execution of the one or more tasks. The one or more tasks includes but are not limited to, handling requests from the API consumer 405 (the information about the API consumer 405 is illustrated in the FIG.4), performing validations, performing transformations, and performing recovery processes. The API facilitates seamless interaction between the API consumer 405 and the API provider 450 (the information about the API provider 450 is illustrated in the FIG.4).
[0046] The one or more workflows refers to a predefined sequence of one or more steps followed by the one or more APIs to handle the API requests and responses. In an embodiment the one or more steps include but are not limited to, error checking of the one or more APIs, updating the API consumer 405 settings, authenticating the API consumer 405 credentials and the like.
[0047] The one or more steps of the workflows are tailored with one or more scenarios. The one or more scenarios pertains to at least one of, but not limited to a consumer onboarding, a consumer offboarding, a subscription update, and a subscription deletion.
[0048] In an embodiment, the consumer onboarding refers to the process of integrating a new consumer into the system 120. The consumer onboarding includes one or more steps. The one or more steps include but are not limited to, collecting and validating consumer details, setting up a new user profile in the system 120, confirming the API consumer 405 via email verification and the like.
[0049] The API consumer 405 offboarding refers to the process of removing and/or deactivating the API consumer 405 from the system 120. The API consumer 405 offboarding includes one or more steps. The one or more steps include but are not limited to, confirming the API consumer’s 405 request to leave, disabling and/or deleting the API consumer’s 405 access to the system 120, removing the API consumer’s 405 data, sending a notification confirming the account closure.
[0050] The subscription update refers to the process of modifying the terms or details of an existing subscription. The subscription update includes one or more steps. The one or more steps for the subscription update include but are not limited to, verifying the details of the update request by the API consumer’s 405, modifying the subscription details in the system 120, recalibrating charges based on the new subscription details, informing the API consumer’s 405 about the successful update.
[0051] The subscription deletion refers to the process of permanently removing the API consumer’s 405 subscription from the system 120. The subscription deletion involves revoking all associated access, services, and resources linked to the subscription.
[0052] In view of the above, the one or more scenarios ensure smooth and efficient management of consumer interactions and subscription, by providing a structured approach to handle different stages of the consumer lifecycle.
[0053] Further while executing the received one or more workflows, the analysing unit 230 of the system 120 is configured to analyse each of the one or more APIs during execution of the one or more workflows. After analysing, the analysing unit 230 detects one of an error and a failure in the execution of the one or more workflows of each of the one or more APIs. The one of the errors and failure include, at least one of but not limited to, a transaction failure, a system failure, a system error, a local error, a network failure, and data corruption.
[0054] In an embodiment, the transaction failure refers to the inability of the network 105 to complete a specific request and/or command due to processing or handling errors within the network 105. The system failure refers to the malfunctioning of the network 105, which results in disrupting normal operations of the network 105. The system errors refer to misconfigurations in the network 105 management systems, the system errors result in erroneous data routing or signaling failures. The local error refers to a fault confined to a specific segment of the network 105 without impacting the overall network functionality. The network failure refers to the disruptions in the network 105 infrastructure, thereby the network 105 impedes its ability to facilitate communication and data exchange across the external networks. The data corruption refers to incorrect processing or failure in data delivery, affecting the integrity and accuracy of the any information transmitted. Therefore, the analysing unit 230 efficiently manages and addresses network issues by performing analysis on the each of the one or more APIs during execution of the one or more workflows. The analysis performed by the analysing unit 230 includes at least one of but not limited to, a real-time analysis of the one or more APIs, detecting errors and failures, and generating diagnostic information essential for the future.
[0055] Based on the detection of the one of errors and failures in the execution of the one or more workflows of each of the one or more APIs, the configuration unit 235 of the system 120 configures conditions corresponding to the one of the errors and the failures in the one or more workflows. In an exemplary embodiment, the conditions configured by the configuration unit 235 includes at least one of, but not limited to, retry condition, fallback procedure, error logging, error handling routine, component isolation, traffic rerouting, and the like. The configuration unit 235 facilitates the system 120 to respond to the one of errors and failures by configuring conditions and actions. By configuring conditions, the configuration unit 235 mitigates the impact of issues on system performance and further ensures the one or more workflows are managed efficiently.
[0056] Upon configuring the conditions corresponding to one of the errors and the failures in the one or more workflows, the initiating unit 240 initiates the one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows. The one or more recovery steps aid in overcoming of each of the one of the errors and failures. The one or more recovery steps includes at least one of but not limited to, resource reallocation, state synchronization, failover activation, performance tuning, dependency checking, connection re-establishment, service deactivation and reconfiguration.
[0057] The resource reallocation refers to the redistributing system resources such as, but not limited to, processing power of the one or more processors 205, the memory 210, the network 105 bandwidth in response to the one of the errors and the failures. The state synchronization refers to coordinating and aligning the states of different services to prevent discrepancies that lead to failures. The different services include, but are not limited to, load balancers, microservices, message queues, cache system, database 220 and the like. The failover activation refers to the process of auto handling the system 120 component failures to ensure the system 120 resilience and service continuity. The performance tuning refers to the systematic process of optimizing the performance of the system 120. The performance tuning facilitates several advantages such as but not limited to, efficient operation of the system 120, maximizing the throughput, reduced response time, and optimal resource utilization. The dependency checking refers to the process of evaluating and verifying the dependencies of the system 120 components. By performing dependency check on the system 120, the system 120 ensures that all the system 120 components are incorporated with the all the required resources, libraries, and the like for proper functioning of the system 120. The connection re-establishment refers to the process of restoring the network 105 connectivity between the system 120 components and the API consumer 405, or between the network 105 and the server 115 after the one of the errors and failures. The service deactivation and reconfiguration include, but not limited to, systematically disabling the service and subsequently modifying the service configuration parameters to address issues and/or optimize performance of the system 120.
[0058] Further upon initiating of the one or more recovery steps, the transmittal unit 245 of the system 120 transmits one of a notification and an alert indicating one of the errors and the failures in the execution of the one or more workflows of each of the one or more APIs. In one or more embodiments, the notification and alert indicating one of the errors and the failures is displayed on the UI 215 and UE 110.
[0059] In an exemplary embodiment, during operation, on detection of at least one of the errors and the failures in the execution of the one or more workflows, the initiating unit 240 is configured to initiate the one or more following recovery steps. Initially on detection of one of the errors and the failures in the execution of the one or more workflows, an API call is received from the UE 110. The API call refers to the process by which a software program communicates with another program through a set of pre-defined rules and protocols, typically using the API. The API call includes, but not limited to, API token and API key. The API token is a secure, unique identifier used to authenticate and authorize access when making API calls. The API tokens carry additional information such as user permissions, scopes, and expiration times. The API key is a simple, unique identifier assigned to UE 110 that wants to make API calls. The API keys serve as a basic form of authentication to track and control how the API is being used. Upon receiving the API call from the UE 110, at least one of, the API tokens and API keys present in the API call is validated.
[0060] Based on validation of at least one of the API token and the API key, if the at least one of the API token and the API key is valid, the retrieving unit 250 is configured to retrieve a valid access plan of the API from the database 220. The access plan includes at least one of an API request status, an API request permission and an API request expiry date. Alternatively, on non-retrieval of the valid access plan, transmittal unit 245 is configured to at least one of, but not limited to, transmit a message indicates unavailability of the valid access plan in the database 220 to the UE 110, providing a follow up call to the UE 110 with a default API access plan, and a fixed number of API calls is allowed as a part of test drill. Further, in a scenario where the retrieved valid access plan is expired, an action is performed as defined in the workflow of the API. The action includes, but is not limited to, extension of the validity of the access plan for a time period.
[0061] In another embodiment, based on validation of the at least one of the API token and the API key, if the at least one of the API token and the API key is invalid, the transmittal unit 245 is configured to transmit a negative notification to the UE 110. The negative notification indicates the failure of validation of the API token or the API key.
[0062] In an embodiment, upon retrieval of the valid API access plan, the retrieving unit 250 is configured to retrieve an API profile associated with the API request from the database 220. The API profile is a set of predefined configurations, rules, and parameters that govern how the API behaves or how the API request is processed. The API profile is utilized for pre-processing the API request. In an embodiment, if the API request includes a call back request, a mapping between an API provider and the consumer is created.
[0063] Upon retrieval of the valid API access plan, the selecting unit 255 is configured to select an API provider instances from a pool of API provider instances. The API provider instance refers to an instance or deployment of a service that responds to API requests. The API provider instance is responsible for executing the functionality exposed by the API, such as processing data, returning results, or performing operations. Subsequently, the managing unit 260 is configured to manage the one or more errors by the selected API service provider. More specifically, in order to manage the one or more errors, the managing unit 260 in communication with the API provider instance is configured to provide at least one of a positive response and a negative response. The positive response includes the one or more recovery steps to rectify the one or more errors. The one or more recovery steps in the positive response includes one of, but not limited to, the resource reallocation, the state synchronization, the failover activation, the performance tuning, the dependency checking, the connection re-establishment, the service deactivation and the reconfiguration.
[0064] The negative response indicates that the API request failed to process correctly due to one or more errors. Further, on receiving the negative response, the selecting unit 255 is configured to retry by selecting the other API provider instance from the pool of API provider instances. The selecting of the different API provider instance from the pool of API provider instances is retried until the API request is successfully processed.
[0065] By automatic identification of one of the errors and the failures in the one or more workflows conditions the system 120 facilitates optimal resource utilization and reduced execution time. Further, auto resolution of the one or more scenarios facilitates consistent and efficient handling of issues, due to which, the system 120 facilitates the API consumers by reducing downtime and service interruptions.
[0066] FIG. 3 is a schematic representation of a workflow of the system of FIG. 2 communicably coupled with the User equipment (UE) 110, according to one or more embodiments of the present disclosure. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE 110a and the system 120 for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0067] As mentioned earlier in FIG. 1, the first UE 110a may include an external storage device, a bus, a main memory, a read-only memory, a mass storage device, communication port(s), and a processor. The exemplary embodiment as illustrated in FIG. 3 will be explained with respect to the first UE 110a without deviating from the scope of the present disclosure and limiting the scope of the present disclosure.
[0068] The first UE 110a includes one or more primary processors 305 communicably coupled to the one or more processors 205 of the system 120.The one or more primary processors 305 are coupled with a memory 310 storing instructions which are executed by the one or more primary processors 305. Execution of the stored instructions by the one or more primary processors 305 enables the first UE 110a to transmit one or more workflows for each of a one or more Application Programming Interfaces (API) via a user interface of the UE 110. In one embodiment, the one or more primary processors 305 enables the first UE 110a to display one of the notifications and an alert indicating one of the errors and the failures in the execution of the one or more workflows of each of the one or more APIs.
[0069] As mentioned earlier in FIG. 2, the one or more processors 202 of the system 120 are configured for recovery management in the network 105. The system 120 includes the one or more processors 205, the memory 210, the UI 215, and the database 220. The operations and functions of the one or more processors 205, the memory 210, the UI 215, and the database 220 are already explained in FIG. 2. For the sake of brevity, a similar description related to the working and operation of the system 120 as illustrated in FIG. 2 has been omitted to avoid repetition.
[0070] Further, the processor 205 includes the receiving unit 225, the analysing unit 230, the configuration unit 235, the initiating unit 240, the transmittal unit 245, the retrieving unit 250, the selecting unit 255, and the managing unit 260 which are already explained in FIG. 2. Hence, for the sake of brevity, a similar description related to the working and operation of the system 120 as illustrated in FIG. 2 has been omitted to avoid repetition. The limited description provided for the system 120 in FIG. 3, should be read with the description provided for the system 120 in the FIG. 2 above, and should not be construed as limiting the scope of the present disclosure.
[0071] FIG. 4 is an exemplary architecture 400 which can be implemented in the system 120 of the FIG.2 for recovery management in the network 105, according to one or more embodiments of the present invention. The exemplary embodiment as illustrated in the FIG. 4 includes the Application Programing Interface (API) consumer 405, a Common API Framework (CAPIF) 410, an Access Management System (AMS) 415, an Edge Load balancer (ELB) 420, an Identity and Access Management (IAM) 425, a persistent database 430, a cache 435, an Element management system (EMS) 440, an API dashboard 445, an API provider 450.
[0072] In one embodiment, the API consumer 405 calls the service API from the API provider 450 by transmitting the API request to the system 120. The API consumer 405 is the source of the API request. The API consumer 405 includes at least one of but not limited to, developers, and enterprise and the like.
[0073] The CAPIF 410 of the system 120 receives and processes the API request sent by the API consumer 405. Initially the CAPIF 410 validates the API token provided in the API request. The API token refers to a security credential used to authenticate and authorize the API requests to the API service. In an embodiment, the API token is validated as part of the API call process by the CAPIF 410. If the token is valid, the received API request is processed further. If the token is not valid, the CAPIF 410 transmits a negative response with a proper message to the API consumer 405 on the API dashboard 445.
[0074] Upon successful token validation, the CAPIF 410 extracts the API key from the received API request. The API key is included in the at least one of, but not limited to, an API request header, an API request body, and an API request Uniform Resource Locator (URL) parameter. Further the CAPIF 410 forwards the extracted API key to the IAM 425 for the API key validation. The IAM 425 manages the API key validation process. On receipt of the API key from the CAPIF 410, the IAM 425 queries the persistent database 430 to check the existence and associated permissions of the API key. The IAM 425 interacts with the persistent database 430 to check if the API key is valid and generates the validation result of the API key. In an embodiment, the persistent database 430 stores information related to the API keys. The information includes but is not limited to, validity of the API key, associated consumer of the API key, and permissions associated with the API key. After validating the API key by interacting with the persistent database 430, the IAM 425 transmits the validation result to the CAPIF 410. Based on the validation result, if the API key validation is not successful, the CAPIF 410 transmits the negative response with a proper message to the API consumer 405 on the API dashboard 445. If the API key validation is successful, the CAPIF 410 transmits the API request to the AMS 415 for access plan validation.
[0075] The AMS 415 queries the persistent database 430 to retrieve information about the consumer access plan. The access plan includes but is not limited to, the API request status, the API requests permissions, and the API request expiry date.
[0076] In an embodiment, if no access plan is associated with the API request, the AMS 415 performs one or more steps to specify the API consumer 405 about the issue. The one or more steps includes, but are not limited to, transmitting the negative response indicating no plan is associated with the API request, allowing the API request to proceed with a default plan if pre–defined by the API consumer 405, permitting a limited number of API calls for testing purposes and subsequently transmitting the negative response.
[0077] In alternate embodiment, if the valid access plan is associated with the API request, further the AMS 415 verifies expiration status of the access plan. If the access plan is expired, the AMS 415 handles the access plan as per the predefined recovery steps, such as but not limited to, notifying stakeholders and/or prompting the consumer to update the plan. The predefined recovery steps are defined by the API management and/ administration team for creating and maintaining the policies and procedures to govern various scenarios, including expired access plans.
[0078] After successful validation of the access plan of the API request, the next step is preparing the API request by manipulation and transformation as required by the API provider 450. The CAPIF 410 handles the manipulation and transformation of the received API request by performing one or more tasks. The one or more tasks include but are not limited to, formatting, adding or removing headers, changing request parameters, and other modifications as required by the API providers 450.
[0079] In an embodiment, the CAPIF 410 retrieves the API profiles from the persistent database 430 for the manipulation and transformation of the API request. The API profiles refer to configurations that define the characteristics and behavior of the APIs. In one embodiment, if the API profile is not associated with the API request, the CAPIF 410 automatically assigns the default API profile to the API request. The API stakeholders and/ API administrators are notified after assigning the default API profile. Further the CAPIF 410 facilitates the API stakeholders and/ API administrators to review and adjust the default settings of the associated default API profile if required. In alternate embodiment, if the API profile is associated with the API request, the CAPIF 410 utilizes the associated API profile to guide the API request manipulation and transformation. The manipulation and transformation ensure that the API requests are correctly formatted, include necessary information, and adhere to the API provider’s 450 requirements.
[0080] In one embodiment, if the API consumer 405 has requested for the callbacks in the API request, the CAPIF 410 creates a mapping between callback URLs provided by the API consumer 405 and the corresponding service API providers 450. Further the CAPIF 410 stores the callback URL in the persistent database 430 and retrieves when required to transmit the notifications to the designated callback endpoints provided by API consumers 405. The CAPIF 405 ensures that the updates about the API requests are accurately conveyed to the API consumers 405.
[0081] Further the CAPIF 410 initiates the selection of the API provider 450 instance from the available pool of the API provider 450 instances. Depending upon the API request, the CAPIF 410 selects the API provider 450 instance to handle the API call. In one embodiment, if stickiness is applied, the system 120 ensures that the subsequent API requests from the same API consumer 405 are routed to the same API provider 450 instance. In an embodiment, the stickiness is an essential feature in load balancing and session management. The stickiness maintains continuity and consistency in the user interactions by routing requests from the same user to the same backend server or instance.
[0082] The ELB 420 provides load balancing and routing of the API requests to the selected API provider 450 instance based on logic and the stickiness settings. The logic includes at least one of but not limited to, round robin, weighted round-robin, least connections, geolocation-based routing, content-based routing, priority-based routing.
[0083] In an embodiment, the ELB 420 assists the CAPIF 405 in detecting the API provider 450 unavailability and routing the API request to alternative instances in the API provider’s 450 pool of instances.
[0084] After routing the API request to the selected API provider instance, the API provider 450 returns the response to the CAPIF 410. The CAPIF 410 determines the received response from the API provider 450.
[0085] In one embodiment, if the response received from the API provider 450 is positive, the CAPIF 450 executes a series of processes to manage the positive response efficiently. The process includes, but are not limited to, performing manipulation and transformation on the received response to align the response with the requirements of the API consumer 405, coordinating with any registered callbacks to transmit the response to designated callback URLs, as specified by the API consumer 405, facilitating the transmission of the finalized positive response to the API consumer 405, updating the cache 435 with the received response.
[0086] In an alternate embodiment, if the response received from the API provider 450 is negative, the CAPIF 410 applies retry policy for handing the negative response from the API provider 450. By applying the retry policy, the CAPIF 410 assesses the defined retry policy applicable to the negative response. The retry policy applicable to the negative response are defined by at least one of but not limited to, the API provider 450, system administrators, developers, and the like, depending on the system 120 design and operational requirements. The retry policy includes, but are not limited to, fixed interval retry, exponential backoff, linear backoff, jittered backoff, retry with circuit breaker.
[0087] FIG. 5 is a signal flow diagram for recovery management in the network 105, according to one or more embodiments of the present invention. For the purpose of description, the signal flow diagram is described with the embodiments as illustrated in FIG. 2 and FIG. 4 and should nowhere be construed as limiting the scope of the present disclosure.
[0088] At step 505, the API Consumer 405 transmits an API request to the CAPIF 410.
[0089] At step 510, on receipt of the API request, the CAPIF 410 validates the API token provided in the API request. If the token is not valid, the CAPIF 410 transmits a negative response with a proper message to the API consumer 405 on the API dashboard 445.
[0090] At step 515, If the token is valid, the CAPIF 410 extracts the API key from the received API request and forwards the extracted API key to the IAM 425 for the API key validation.
[0091] At step 520, on receipt of the API key from the CAPIF 410, the IAM 425 interacts with the persistent database 430 to check if the API key is valid and generates the validation result of the API key.
[0092] At step 525, after validating the API key by interacting with the persistent database 430, the IAM 425 transmits the validation result to the CAPIF 410.
[0093] At step 530, based on the validation results, if the API key validation is not successful, the CAPIF 410 transmits the negative response with at least one of a message and an alert to the API consumer 405 on the API dashboard 445.
[0094] At step 535, If the API key validation is successful, the CAPIF 410 transmits the API request to the AMS 415 for access plan validation.
[0095] At step 540, the AMS 415 queries the persistent database 430 to retrieve information about the consumer 405 access plan.
[0096] At step 545, if no access plan is associated with the API request, the AMS 415 performs one or more steps to specify the API consumer 405 about the issue. If the valid access plan is associated with the API request, further the AMS 415 verifies the expiration status of the access plan. If the access plan is expired, the AMS 415 handles the access plan as per predefined steps, such as but not limited to, notifying stakeholders and/or prompting the consumer to update the plan.
[0097] At step 550, after successful validation of the access plan of the API request, the next step is preparing the API request by manipulation and transformation as required by the API provider 450. The CAPIF 410 retrieves the API profiles from the persistent database 430 for the manipulation and transformation of the API request. The CAPIF 410 utilizes the associated API profile to guide the API request manipulation and transformation. The manipulation and transformation ensure that the API requests are correctly formatted, include necessary information, and adhere to the API provider’s 450 requirements.
[0098] At step 555, if the API profile is not associated with the API request, the CAPIF 410 automatically assigns the default API profile to the API request.
[0099] At step 560, if the API consumer 405 has requested for the callbacks in the API request, the CAPIF 410 creates a mapping between callback URLs provided by the API consumer 410 and the corresponding service API providers 450.
[00100] At step 565, further the CAPIF 410 stores the callback URL in the persistent database 430. Further, the CAPIF 410 retrieves the stored callback URL, if required to transmit the notifications to the designated callback endpoints provided by API consumers 405.
[00101] At step 570, the CAPIF 410 initiates the selection of the API provider instance from an available pool of the API provider instances by transmitting the API request to the ELB 420.
[00102] At step 575, the ELB 420 provides load balancing and routing of the API requests to the selected API provider 450 instance.
[00103] At step 580, after routing the API request to the selected API provider instance, the API provider 450 returns the response to the CAPIF 410.
[00104] At step 585, the CAPIF 410 determines the received response from the API provider 450. If the response received from the API provider 450 is positive, the CAPIF 450 executes a series of processes to manage positive response efficiently. If the response received from the API provider 450 is negative, the CAPIF 410 applies retry policy for handing the negative response from the API provider 450
[00105] FIG. 6 is a flow diagram illustrating the method 600 of recovery management in the network 105, according to one or more embodiments of the present disclosure. For the purpose of description, the flow diagram is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[00106] At step 605, the method 600 includes the step of receiving one or more workflows for each of a one or more Application Programming Interfaces (APIs) from the UI 215. The one or more steps of the workflows are tailored with one or more scenarios. The one or more scenarios pertains to at least one of, but not limited to a consumer onboarding, a consumer offboarding, a subscription update, and a subscription deletion.
[00107] At step 610, each of the one or more APIs are analyzed during execution to detect one of errors and failures in the execution of the one or more workflows of each of the one or more APIs. The analysing unit 230 facilitates the system 120 to detect one of the errors and failures in the execution of the one or more workflows of each of the one or more APIs. The one of the errors and failures include, at least one of but not limited to, a transaction failure, a system failure, a system error, a local error, a network failure, and data corruption. Based on the detection of one of errors and failures in the execution of the one or more workflows of each of the one or more APIs, the configuration unit 235 of the system 120 configures the conditions corresponding to one of the errors and the failures in the one or more workflows.
[00108] At step 615, the method 600 includes the step of initiating one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows. The one or more recovery steps aid in overcoming of each of the one of the errors and failures. The one or more recovery steps includes at least one of but not limited to, resource reallocation, state synchronization, failover activation, performance tuning, dependency checking, connection re-establishment, service deactivation and reconfiguration. Further upon initiating of the one or more recovery steps, the transmittal unit 245 of the system 120 transmits the one of a notification and an alert indicating one of the errors and the failures in the execution of the one or more workflows of each of the one or more APIs. In one or more embodiments, the notification and alerts indicating one of the errors and the failures is displayed on the UI 215 and UE 110.
[00109] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 205. The processor 205 is configured to receive one or more workflows for each of a one or more Application Programming Interfaces (API) from a user interface. The processor 205 is further configured to analyse, each of the one or more APIs during execution to detect one of errors and failures in the execution of the one or more workflows of each of the one or more APIs. The processor 205 is further configured to initiate one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows.
[00110] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-6) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[00111] The present disclosure incorporates technical advancement for recovery management in the network 105. The present invention facilitates auto detection of one of errors and failures in the execution of the one or more workflows of each of the one or more APIs. Further the present invention facilitates auto resolution for resolving the common issues or exceptions that occur during API interactions. The present invention detects and performs recovery actions based on the predefined one or more workflows tailored with one or more scenarios such as, but not limited to, a consumer onboarding, a consumer offboarding, a subscription update, and a subscription deletion.
[00112] The present invention provides various advantages, including optimal resource utilization, reduced execution, automated detection and resolution of the issues. The present invention facilitates reliability by consistent handling of errors and failures via the predefined one or more workflows. The present invention provides suggested resolutions for resolving detected errors and failures. Further the present invention generates detailed reports on all detected cases, either automatically or upon request from the end user such as but not limited to, API consumers.
[00113] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS
[00114] Communication system – 100
[00115] Network – 105
[00116] User Equipment – 110
[00117] Server – 115
[00118] System – 120
[00119] Processor -205
[00120] Memory – 210
[00121] UI – 215
[00122] Database- 220
[00123] Receiving unit - 225
[00124] Analysing unit - 230
[00125] Configuration unit - 235
[00126] Initiating unit – 240
[00127] Transmittal unit – 245
[00128] Retrieving unit- 250
[00129] Selecting unit- 255
[00130] Managing unit -260
[00131] one or more primary processor- 305
[00132] memory- 310
[00133] API consumer - 405
[00134] Common API Gateway for API Consumer (CAPIF) - 410
[00135] Access Management System (AMS) - 415
[00136] Edge Load balancer (ELB) – 420
[00137] Identity and access management (IAM) – 425
[00138] Persistent DB – 430
[00139] Cache - 435
[00140] Element management system (EMS) - 440
[00141] API dashboard - 445
[00142] API provider - 450
,CLAIMS:CLAIMS:
We Claim:
1. A method (600) of recovery management in a network (105), the method (600) comprising the steps of:
receiving (605), by one or more processors (205), one or more workflows for each of a one or more Application Programming Interfaces (APIs) from a user interface;
analysing (610), by the one or more processors (205), each of the one or more APIs during execution to detect one of an error and a failure in the execution of the one or more workflows of each of the one or more APIs; and
initiating (615), by the one or more processors (205), one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows.

2. The method as claimed in claim 1, wherein the one or more recovery steps, includes at least one of but not limited to, resource reallocation, state synchronization, failover activation, performance tuning, dependency checking, connection re-establishment, service deactivation and reconfiguration.

3. The method (600) as claimed in claim 1, wherein the one or more workflows comprises one or more steps for each of a one or more scenarios, and wherein the one or more scenarios pertains to at least one of a consumer onboarding, a consumer offboarding, a subscription update, and a subscription deletion.

4. The method (600) as claimed in claim 1, wherein on receiving the one or more workflows, the method comprises the step of configuring, by the one or more processors (205), conditions corresponding to one of the errors and the failures in the one or more workflows.

5. The method as claimed in claim 4, wherein the conditions include at least one of, but not limited to, retry condition, fallback procedure, error logging, error handling routine, component isolation, and traffic rerouting.

6. The method (600) as claimed in claim 1, wherein each of the one of the errors and the failures comprises one of a transaction failure, a system failure, a system error, a local error, a network failure, and data corruption.

7. The method (600) as claimed in claim 1, wherein upon initiating, the one or more recovery steps, the method comprises the step of transmitting, by the one or more processors (205), one of a notification and an alert indicating one of the errors and the failures in the execution of the one or more workflows of each of the one or more APIs.

8. A system (120) for recovery management in a network, the system comprising:
a receiving unit (225) configured to receive, one or more workflows for each of a one or more Application Programming Interfaces (APIs) from a user interface;
an analysing unit (230) configured to analyse, each of the one or more APIs during execution to detect one of errors and failures in the execution of the one or more workflows of each of the one or more APIs; and
an initiating unit (240) configured to initiate, one or more recovery steps on detection of one of the errors and the failures in the execution of the one or more workflows.

9. The system as claimed in claim 8, wherein the one or more recovery steps, includes at least one of but not limited to, resource reallocation, state synchronization, failover activation, performance tuning, dependency checking, connection re-establishment, service deactivation and reconfiguration.

10. The system (120) as claimed in claim 8, wherein the one or more workflows comprises one or more steps for each of a one or more scenarios, and wherein the one or more scenarios pertains to at least one of a consumer onboarding, a consumer offboarding, a subscription update, and a subscription deletion.

11. The system (120) as claimed in claim 8, comprising a configuration unit (235) configured to configure conditions corresponding to one of the errors and the failures in the one or more workflows upon receipt of the one or more workflows.

12. The system as claimed in claim 11, wherein the conditions include at least one of, but not limited to, retry condition, fallback procedure, error logging, error handling routine, component isolation, and traffic rerouting.

13. The system (120) as claimed in claim 8, wherein each of the one of the errors and the failures comprises one of transaction failure, system failure, system error, local error, network failure, and data corruption.

14. The system (120) as claimed in claim 8, comprising a transmittal unit (245) configured to transmit, one of a notification and an alert indicating one of the errors and the failures in the execution of the one or more workflows of each of the one or more APIs upon initiating of the one or more recovery steps.

15. A User Equipment (UE) (110), comprising:
one or more primary processors (305) communicatively coupled to one or more processors (205), the one or more primary processors (305) coupled with a memory (310), wherein said memory (310) stores instructions which when executed by the one or more primary processors (305) causes the UE (110) to:
transmit, one or more workflows for each of a one or more Application Programming Interfaces (API) via a user interface of the UE,
wherein the one or more processors (205) is configured to perform the steps as claimed in claim 1.