FORM 2
THE PATENTS ACT, 1970 (39 of 1970) THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
PROGRAMMING INTERFACES (APIS) IN A NETWORK
Ambawadi, Ahmedabad - 380006, Gujarat, India; Nationality : India
The following specification particularly describes
the invention and the manner in which
it is to be performed

RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material,
which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
FIELD OF DISCLOSURE
[0002] The present disclosure generally relates to a wireless
telecommunications network. More particularly, the present disclosure relates to a fulfilment management system and a method for configuring Application Programming Interfaces (APIs) in a network.
DEFINITION
[0003] As used in the present disclosure, the following terms are generally
intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression "API" or "Application Programming Interface" used
hereinafter in the specification refers to a set of rules, protocols, and tools for building software applications. APIs define how software components should interact and enable communication between different systems.
[0005] The expression "Northbound Interface (NBI)" used hereinafter in the
specification refers to an interface that allows a specific component to communicate with a higher-level component in a network.

[0006] The expression "Southbound Interface" used hereinafter in the
specification refers to an interface that enables a specific component to communicate with a lower-level component in a network.
[0007] The expression "Fulfilment Management System (FMS)" used
hereinafter in the specification refers to a system responsible for managing and orchestrating the fulfilment of service requests, including the configuration and management of APIs in a network.
[0008] The expression "Workflow" used hereinafter in the specification
refers to a sequence of tasks or API calls that are executed in a specific order to achieve a desired outcome or fulfill a service request.
[0009] The expression "Workflow Configuration Definitions" used
hereinafter in the specification refer to a set of rules, templates, and parameters that define the structure, behaviour, and execution of workflows in the FMS.
[0010] The expression "Network Node" used hereinafter in the specification
refers to a physical or virtual component in a network that performs specific functions, such as routing, processing, or storing data. Examples of network nodes include servers, switches, routers, and databases.
[0011] The expression "Attribute" used hereinafter in the specification
refers to a characteristic or property of an API request or response, such as a parameter, header, or data field.
[0012] The expression "Attribute Transformation" used hereinafter in the
specification refers to the process of modifying, converting, or manipulating the values of attributes in API requests or responses based on predefined rules or functions.
[0013] The expression "Mapping" used hereinafter in the specification
refers to the process of defining how data from one source, such as an incoming

request, is translated or transformed to fit the requirements of another destination, such as an API request.
[0014] The expression "Order status" used hereinafter in the specification
refers to a current state or condition of a service request or order being processed by the FMS, indicating whether it is pending, in progress, completed, or failed.
[0015] The expression "Inventory" used hereinafter in the specification
refers to a database or repository that keeps track of available resources, such as numbers, Internet Protocol (IP) addresses, or service configurations, that can be assigned to users or services.
[0016] These definitions are in addition to those expressed in the art.
BACKGROUND OF DISCLOSURE
[0017] The following description of 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 be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0018] In the field of network management and service orchestration, the
efficient configuration and management of application programming interfaces (APIs) play a crucial role in enabling seamless communication between various components of a network. APIs act as the bridge between different systems, allowing them to exchange data and functionality. In particular, northbound interfaces facilitate communication with higher-level components, while southbound interfaces enable interaction with lower-level components.
[0019] Fulfilment management systems are essential tools in the network
management domain. The fulfilment management systems translate incoming requests from northbound interfaces into a series of predefined API calls to

southbound interfaces. This process ensures that the requested services or configurations are properly implemented across the network. However, the current state of the art presents significant challenges and limitations.
[0020] One of the primary issues faced by network operators and service
providers is the lack of flexibility in handling changes to southbound requests. In existing systems, any modification to the request schema, such as altering a key or value, necessitates a new release or code-level changes. This rigid approach leads to increased development effort, as software engineers must manually intervene and modify the codebase to accommodate the changes. Moreover, the integration effort required to incorporate these updates into the existing system adds further complexity and prolongs the deployment timeline.
[0021] The inflexibility of current solutions not only burdens the
development and integration teams but also results in service impact. When changes to southbound requests require a new release or code modifications, it often entails downtime or service disruptions. This can be particularly problematic in mission-critical networks where service availability and reliability are of utmost importance. The inability to seamlessly adapt to changes without affecting service continuity is a significant drawback of existing FMS implementations.
[0022] Furthermore, the manual intervention required to handle southbound
request changes introduces the risk of human error. With each modification, there is a possibility of introducing bugs or misconfigurations, which can lead to unexpected behaviour or even system failures. The lack of a streamlined and automated process for managing these changes increases the chances of costly mistakes and compromises the overall stability and performance of the network.
[0023] It is therefore a need of a system and method that enables the
dynamic configuration of southbound APIs, allowing for seamless adaptation to changes in request schemas without requiring code modifications or service disruptions.

SUMMARY
[0024] One embodiment of the present subject matter relates to a fulfilment
management system (FMS) for configuring application programming interfaces (APIs) in a network. The FMS may comprise one or more processors and a memory coupled to the processors. The memory may store a set of workflow configuration definitions and a set of instructions that, when executed by the processors, cause the FMS to configure the APIs.
[0025] The FMS may receive a request from a receiving unit containing
attributes corresponding to a plurality of APIs associated with network nodes. Based on the set of stored workflow configuration definitions, the FMS may determine a workflow corresponding to the request, where the workflow comprises a sequence of API calls. For each API call in the sequence, the FMS may generate a new request by deriving values for one or more attributes corresponding to each API call from the attributes in the received request using mappings specified in the set of stored workflow configuration definitions. The FMS may also perform a set of attribute transformations specified in the workflow configuration definitions. The FMS may send the new request to a corresponding network node and receive a response from the node. The FMS may update an order status based on the responses received from the network nodes and provide the receiving unit a response based on the updated order status and the responses received from the network nodes.
[0026] The FMS may further receive, via a user interface, an update to the
mappings specified in the workflow configuration definitions for a specific API. For subsequent requests from the receiving unit, the FMS may generate new requests for the specific API using the updated mappings. The workflow configuration definitions may comprise various elements, such as request and response schemas for each API, attributes defining data elements required for each API request and response, end points indicating the network nodes associated with each API, mappings between attributes in the received request and attributes of each

API, the sequence of API calls, and the set of attribute transformations to be performed.
[0027] The FMS may create the workflow by linking the API calls based on
the request schemas, response schemas, attributes, and end points specified in the 5 workflow configuration definitions. The attribute transformations may include operations such as matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement. The network nodes associated with the APIs may include various network functions, such as a Policy Control Function (PCF), a Policy and Charging Rules Function (PCRF), a User Data Function (UDF), 10 an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Slice Selection Function (NSSF), an Over-The-Air (OTA) server, and a Business Telephony Application Server (BTAS).
[0028] One embodiment of the present subject matter relates to a method
for configuring application programming interfaces (APIs) in a network. The
15 method may involve storing, in a memory, a set of workflow configuration definitions. The method includes receiving a request from a receiving unit containing attributes corresponding to a plurality of APIs associated with network nodes. Based on the workflow configuration definitions, one or more processors may determine a workflow corresponding to the request, where the workflow
20 comprises a sequence of API calls.
[0029] For each API call in the sequence, the method includes generating a
new request by deriving values for one or more attributes corresponding to each API call from the attributes in the received request using mappings specified in the workflow configuration definitions. The method includes performing a set of 25 attribute transformations specified in the workflow configuration definitions. The one or more processors may send the new request to a corresponding network node and receive a response from the node. The method may further involve the one or more processors updating an order status based on the responses received from the
7

network nodes and providing, to the receiving unit, a response based on the updated order status and the responses received from the network nodes.
[0030] The method includes receiving, via a user interface, an update to the
mappings specified in the workflow configuration definitions for a specific API. 5 For subsequent requests from the receiving unit, the method includes generating new requests for the specific API using the updated mappings. The workflow configuration definitions may comprise various elements, such as request and response schemas for each API, attributes defining data elements required for each API request and response, end points indicating the network nodes associated with 10 each API, mappings between attributes in the received request and attributes of each API, the sequence of API calls, and the set of attribute transformations to be performed.
[0031] The method includes creating the workflow by linking the API calls
based on the request schemas, response schemas, attributes, and end points
15 specified in the workflow configuration definitions. The attribute transformations may include operations such as matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement. The network nodes associated with the APIs may include various network functions, such as a Policy Control Function (PCF), a Policy and Charging Rules Function (PCRF), a User Data
20 Function (UDF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Slice Selection Function (NSSF), an Over-The-Air (OTA) server, and a Business Telephony Application Server (BTAS).
[0032] In another embodiment, the present disclosure relates to a user
25 equipment communicatively coupled to a Fulfilment Management System (FMS) through a network. The FMS comprises one or more processors and a memory coupled to the processors. The memory stores a set of workflow configuration definitions and instructions that, when executed by the processors, cause the FMS to perform the steps of a method of configuring APIs in the network. The method
8

involves storing a set of workflow configuration definitions in the memory and receiving a request from a receiving unit. The receiving unit may be a Northbound Interface (NBI). The request may contain one or more attributes corresponding to a plurality of APIs associated with the network nodes. The method involves 5 determining a workflow based on the workflow configuration definitions. The workflow comprises a sequence of API calls, and for each API call in the sequence, the method involves generating a new request by deriving values for one or more attributes of the API from the one or more attributes in the received request using mappings specified in the workflow configuration definitions, performing a set of 10 attribute transformations, sending the new request to a corresponding network node, and receiving a response from the corresponding network node. The method further includes updating an order status based on the responses received from the network and providing a response to the receiving unit based on the updated order status and the responses received from the network nodes.
15 [0033] The potential the advantage of the FMS is its ability to automate and
streamline the process of configuring and managing APIs in a network. By leveraging workflow configuration definitions and attribute transformations, the method may reduce the complexity and manual effort of integrating and orchestrating services across multiple network nodes. The system’s flexibility in
20 handling updates to mappings and generating new requests based on those updates may also contribute to improved agility and responsiveness in the face of changing requirements.
OBJECTS OF THE PRESENT DISCLOSURE
[0034] Some of the objects of the present disclosure, which at least one
25 embodiment herein satisfies, are as listed herein below.
[0035] It is an object of the present subject matter to provide a Fulfilment
Management System (FMS) and a method for configuring application programming interfaces (APIs) in a network.
9

[0036] It is an object of the present subject matter to provide an FMS and a
method that caters to any changes in APIs, by simply changing the configuration from an FMS user interface.
[0037] It is an object of the present subject matter to provide an FMS and a
5 method that takes a single request containing a superset of all attributes of all the APIs and executes a sequence of API calls and provides a final response after completion of single/all APIs.
[0038] It is an object of the present subject matter to provide an FMS and a
method that increases flexibility to cater to any changes in the APIs.
10 [0039] It is an object of the present subject matter to provide an FMS and a
method that supports multiple types of mapping in order to derive attribute values from the request and send the derived values to the interface.
[0040] It is an object of the present subject matter to provide an FMS and a
method that supports sequential, parallel, conditional, and loop workflow patterns.
15 BRIEF DESCRIPTION OF DRAWINGS
[0041] 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
20 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 the disclosure of electrical components, electronic components
25 or circuitry commonly used to implement such components.
[0042] FIG. 1 illustrates an exemplary network architecture for
implementing a fulfilment management system (FMS) for configuring the
10

application programming interfaces (APIs) in a network, in accordance with an embodiment of the present disclosure.
[0043] FIG. 2 illustrates an exemplary block diagram of the FMS, in
accordance with an embodiment of the present disclosure.
5 [0044] FIG. 3 illustrates an exemplary flow diagram implementing a
method for configuring the APIs using the FMS, in accordance with an embodiment of the present disclosure.
[0045] FIG. 4 illustrates another exemplary block diagram representing an
implementation of the FMS, in accordance with an embodiment of the present 10 disclosure.
[0046] FIG. 5 illustrates another exemplary flow chart implementing the
method for configuring the APIs, in accordance with an embodiment of the present disclosure.
[0047] FIG. 6 illustrates an exemplary architecture of the FMS, in
15 accordance with an embodiment of the present disclosure.
[0048] FIG. 7 illustrates another exemplary flowchart of the method, in
accordance with an embodiment of the present disclosure.
[0049] FIG. 8 illustrates another exemplary block diagram of the FMS, in
accordance with an embodiment of the present disclosure.
20 [0050] FIG. 9 illustrates a computer system in which or with which the
embodiments of the present disclosure may be implemented.
[0051] The foregoing shall be more apparent from the following more
detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
25 100 – Network Architecture
11

102-1, 102-2…102-N – User (s)
104-1, 104-2…104-N – User Equipment (s)
106 – Network
108 – FMS 5 202 – One or more processor(s)
204 – Memory
206 –Interfaces
208 – Processing Engine (s)
210 – Database 10 212, 402 – Receiving Unit
404-1, 404-2…404-N – Network Node(s)
602 – Operation and Management Module
604 – Load Balancer
606 – Workflow Manager 15 608 – Dynamic Activator
610-1 – Graph Database
610-2 – Distributed Data Lake
610-3–Cache Data Store
612 – User interface 20 614 – Dynamic routing manager
616 – Command line interface
910 – External Storage Device
920 – Bus
930 – Main Memory 25 940 – Read Only Memory
950 – Mass Storage Device
960 – Communication Port
970 – Processor
30
12

BRIEF DESCRIPTION OF THE INVENTION
[0052] 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 5 embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can 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. Some of the problems discussed above might not be 10 fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
[0053] The ensuing description provides exemplary embodiments only, and
15 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 20 of the disclosure as set forth.
[0054] 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, networks, processes, and other 25 components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
13

[0055] Also, it is noted that individual embodiments may be described as a
process that 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 can be performed in 5 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. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling 10 function or the main function.
[0056] 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 herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not
15 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 like the term
20 “comprising” as an open transition word without precluding any additional or other elements.
[0057] Reference throughout this specification to “one embodiment” or “an
embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included 25 in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
14

[0058] The terminology used herein is to describe particular embodiments
only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms 5 “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the
10 associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms
15 is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
[0059] As used herein, an “electronic device”, or “portable electronic
20 device”, or “user device” or “communication device” or “user equipment” or
“device” refers to any electrical, electronic, electromechanical, and computing
device. The user device is capable of receiving and/or transmitting one or
parameters, performing function/s, communicating with other user devices, and
transmitting data to the other user devices. The user equipment may have a
25 processor, a display, a memory, a battery, and an input-means such as a hard keypad
and/or a soft keypad. The user equipment may be capable of operating on any radio
access technology including but not limited to IP-enabled communication, Zig Bee,
Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi,
Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to,
30 a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR)
15

devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.
[0060] Further, the user device may also comprise a “processor” or
5 “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The 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 DSP core, a controller, a microcontroller, Application Specific 10 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 is a hardware processor.
15 [0061] As portable electronic devices and wireless technologies continue to
improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The
20 development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), and now fifth generation (5G), and more such generations are expected to continue in the forthcoming time.
[0062] While considerable emphasis has been placed herein on the
components and component parts of the preferred embodiments, it will be 25 appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing
16

descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0063] At present, the configuration and management of application
programming interfaces (APIs) in a network can be a complex and time-consuming 5 process. Traditional methods often require manual intervention and code-level changes to accommodate modifications in API one or more attributes, leading to increased development efforts, prolonged deployment times, and potential service disruptions. The present subject matter addresses these challenges by providing a Fulfilment Management System (FMS) and a method that enables dynamic 10 configuration of APIs through a user-friendly interface. By leveraging workflow configuration definitions and attribute mappings stored in the FMS, the present subject matter allows for seamless adaptation to changes in API requirements, ensuring swift and efficient integration of services across multiple network nodes.
[0064] The present subject matter serves the purpose of enhancing the
15 agility and scalability of network operations by streamlining the process of configuring and managing APIs. The FMS and method provided by the present subject matter enable network administrators to rapidly define and update workflows, attribute mappings, and transformations, without the need for extensive coding or system downtime. By simplifying the orchestration of services across 20 various network functions, such as Policy Control Functions (PCFs), Session Management Functions (SMFs), and Business Telephony Application Servers (BTASs), the present subject matter empowers service providers to deliver high-quality, customizable solutions to their customers, while minimizing operational complexity and costs.
25 [0065] The present subject matter relates to a Fulfilment Management
System (FMS) and a method for configuring application programming interfaces (APIs) in a network. The FMS comprises one or more processors and a memory storing workflow configuration definitions and instructions. The FMS receives a request containing one or more attributes corresponding to multiple APIs from a
17

Northbound Interface receiving unit, determines a workflow based on the configuration definitions, and executes a sequence of API calls. For each API call, the FMS generates a new request by deriving attribute values using specified mappings and transformations, sends the request to a network node, and receives a 5 response. The FMS updates an order status based on the responses and provides a consolidated response to the receiving unit. The method involves storing configuration definitions, receiving requests, determining workflows, generating, and sending API requests, performing transformations, updating order status, and providing responses, enabling dynamic configuration of APIs in a network.
10 [0066] The various embodiments throughout the disclosure will be
explained in more detail with reference to FIG. 1- FIG. 9.
[0067] FIG. 1 illustrates an exemplary network architecture (100) for
implementing a fulfilment management system (FMS) (108) for configuring application programming interfaces (APIs) in a network (106). The network 15 architecture (100) includes one or more computing devices (104-1, 104-2...104-N), collectively referred to as computing devices (104) or user equipment (UE) (104), connected to the FMS (108) through the network (106). One or more users (102-1, 102-2...102-N), collectively referred to as users (102), may provide requests to the FMS (108) via the computing devices (104).
20 [0068] In an embodiment, the computing device (104) may include, but not
be limited to, a mobile, a laptop, etc. Further, the computing device (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, audio aid, microphone, or keyboard. Furthermore, the computing device (104) may include a mobile phone, smartphone,
25 virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, and a mainframe computer. Additionally, input devices for receiving input from the user (102) such as a touchpad, touch-enabled screen, electronic pen, and the like may be used.
18

[0069] In an embodiment, the network (106) 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, 5 waves, voltage or current levels, some combination thereof, or so forth. The network (106) 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), 10 a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0070] The FMS (108) is designed to handle a single request containing a
superset of one or more attributes for multiple southbound APIs. Upon receiving the request, the FMS (108) executes a sequence of southbound API calls, referred 15 to as a workflow, and provides a final response after completing one or all of the API calls. The FMS (108) supports various workflow patterns, including sequential, parallel, conditional, and loop patterns.
[0071] Although FIG. 1 shows exemplary components of the network
architecture (100), in other embodiments, the network architecture (100) may 20 include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).
25 [0072] FIG. 2 illustrates an exemplary block diagram (200) of the FMS
(108), in accordance with an embodiment of the present disclosure.
[0073] Referring to FIG. 2, in an embodiment, the FMS (108) may include
one or more processor(s) (202), and a receiving unit (212). The one or more processor(s) (202) may be implemented as one or more microprocessors,
19

microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory 5 (204) of the FMS (108). The memory (204) may be configured to store a set of workflow configuration definitions and a set of instructions for configuring APIs in a network. The set of workflow configuration definitions stored in the memory (204) defines the structure and format of requests and responses for each API, including a request schema and a response schema. These schemas establish a
10 structured format for requests and responses, define endpoints, mappings, and automate the creation of a complete workflow. Configuring APIs in a network involves various steps to ensure they are secure, efficient, and properly integrated. The set of instructions may include various steps such as regarding defining API specifications, authentication, and authorization of the received request,
15 establishing a secure communication, rate limiting and throttling, error handling, and API versioning. The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may comprise any non-transitory
20 storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0074] The receiving unit (212) receives the request that includes one or
more attributes. These attributes correspond to multiple APIs that are linked with 25 the plurality of network nodes. The receiving unit (212) may serve as an interfacing unit configured to receive the request from the user.
[0075] The FMS (108) also includes one or more interfaces (206) for
facilitating communication within the system and providing communication
pathways for components such as processing engines (208) and a database (210).
30 The interfaces (206) may support various input/output devices and storage devices.
20

[0076] In an embodiment, the processing engine(s) (208) may be
implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) (208). In examples described herein, such combinations of 5 hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (208) may comprise a processing resource (for example, one or more processors), to execute such
10 instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (208). In such examples, the system may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may
15 be separate but accessible to the system and the processing resource. In other examples, the processing engine(s) (208) may be implemented by electronic circuitry.
[0077] Further, the processing engine(s) (208) may include one or more
engine(s). The one or more engine(s) may include, but not limited to, a data 20 ingestion engine, an input/output engine, and a notification engine. The processing engine(s) (208) may configure or cater any changes in the southbound APIs, by simply changing the configuration from a fulfilment management system user interface.
[0078] The block diagram (200) of the FMS (108) shown in FIG. 2 is
25 exemplary, and in other embodiments, the FMS (108) may include fewer, different, or additional components arranged in various configurations. Some components may perform functions described as being performed by other components.
[0079] FIG. 3 illustrates an exemplary flow diagram implementing a
method (300) for configuring and executing workflows using the FMS (108).
21

[0080] Referring to FIG. 3, the method (300) starts with the FMS (108)
receiving the request containing a superset of one or more attributes required by the southbound APIs.
[0081] In step (302), upon receiving the request, the FMS (108) finds a free
5 number inventory. The free number inventory consists of a pool specifically designated for allocating numbers to requests. The system systematically checks each number in the inventory to determine its availability for immediate allocation. Upon identifying a free number that meets the requirement of the request, the FMS (108) fetches it from the pool. Step (302) ensures that the allocated number is both 10 available and suitable for the intended purpose as specified in the request.
[0082] In step (304), the FMS (108) updates the number status inventory
based on the request. This step involves marking the numbers identified in step (302) as allocated or reserved, ensuring they are not assigned to other requests. Step (304) involves marking the specific numbers identified in step (304) as either
15 allocated or reserved. By employing the step (304), the FMS ensures that these numbers are not mistakenly assigned to other requests or operations within the system. This update is crucial for maintaining accurate inventory records and preventing potential conflicts that could arise from concurrent allocation attempts. Once marked, the allocated or reserved status serves as a safeguard, effectively
20 securing the identified numbers for exclusive use in fulfilling the current request initiated in step (302).
[0083] In step (306), the FMS (108) creates a provisioning Policy Control
Function (PCF) for all the states of the workflow. The PCF is responsible for managing and enforcing policies related to the provisioning process. This step sets 25 up the necessary policies for each stage of the workflow. The PCF is configured to govern and enforce policies that pertain to the provisioning process. Step (306) involves establishing comprehensive policies and rules that dictate how each stage of the provisioning workflow should be executed and monitored. These policies are designed to ensure consistency, reliability, and adherence to operational standards
22

throughout the lifecycle of the provisioning process. By setting up the PCF, the FMS (108) enhances its capability to systematically manage resources, enforce regulatory requirements, and maintain operational efficiency across all phases of provisioning, from initial allocation to final deployment and beyond.
5 [0084] In step (308), the FMS (108) creates a request/response schema, a
set of one or more attributes, endpoints, and mappings with all the network nodes involved in the workflow. The request/response schema defines the structure and format of the data exchanged between the FMS (108) and the network nodes. The one or more attributes specify the data elements required for each API request and
10 response. The endpoints indicate the network nodes associated with each API and where the requests should be sent. The mappings define how data from the incoming request should be transformed and included in each API request. This step essentially builds the complete workflow by linking all the states automatically, based on the defined schemas, one or more attributes, endpoints, and
15 mappings.
[0085] FIG. 4 illustrates an exemplary block diagram (400) representing an
implementation of the FMS (108), in accordance with an embodiment of the present disclosure.
[0086] In one embodiment, as illustrated in FIG. 4, the FMS (108) may be
20 communicatively coupled to a receiving unit (402) and various network nodes (404-1, 404-2, 404-3, 404-4, 404-5) through a network (106). The receiving unit may be a Northbound Interface (NBI). The FMS (108) may comprise one or more processors (202) and a memory (204) coupled to the processors (202). The memory (204) may store a set of workflow configuration definitions and instructions that, 25 when executed by the processors (202), cause the FMS (108) to perform a series of operations.
[0087] The FMS (108) may receive from the receiving unit (402), a request
containing one or more attributes corresponding to a plurality of APIs associated with the network nodes. In an example, the one or more attributes may include API
23

endpoint (specific URL or path of an API), parameters (input parameters required for the API operation), headers (Information like authentication tokens, content type), and body (data payload sent with the request). Based on the workflow configuration definitions, the FMS (108) is configured to determine a workflow 5 corresponding to the request. the workflow comprises a sequence of API calls. In one example, the set of stored workflow configuration definitions includes predefined configurations or templates that define the sequence of steps or actions (workflow) to be executed. Upon receiving the set of stored workflow configuration definitions, the one or more processors are configured to determine the workflow
10 corresponding to the request by matching the incoming request with the set of stored workflow configuration definitions. When the request is received, the system needs to identify or select the appropriate workflow configuration from the stored definitions. This determination could be based on parameters or attributes within the request, such as the type of operation requested, specific identifiers, or
15 conditions associated with the workflow. Once the appropriate workflow configuration is identified, it outlines a series of steps or actions that need to be executed. These steps typically involve making API calls to different services, systems, or endpoints to perform specific tasks or operations. For each API call in the sequence, the FMS (108) may generate a new request by deriving values for one
20 or more attributes of the API from the one or more attributes in the received request, using mappings specified in the workflow configuration definitions. Before initiating each API call, the new request is generated by identifying the parameters (one or more attributes) necessary for the request. These one or more attributes are extracted from the request that initiated the workflow execution. To derive these
25 values, the FMS (108) performs predefined mappings or rules outlined in the set of workflow configuration definitions. This process ensures that the API calls are equipped with the specific data required to execute the intended actions accurately. The FMS (108) may also perform a set of attribute transformations specified in the workflow configuration definitions. The set of attribute transformations includes
30 various operations applied to attributes (data fields or parameters) within the request processed by the FMS. These transformations may include operations such as
24

matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement. The FMS enhances its functionality by dynamically manipulating data through various transformations. These operations, defined in workflow configurations, enable the FMS to process and manage data effectively as part of 5 its broader tasks within network management or operational workflows.
[0088] After generating the new request and performing the necessary
transformations, the FMS (108) may send the new request to a corresponding network node and receive a response from the node. Upon determining the necessary attributes and parameters for each API call as per the workflow
10 configuration, the FMS constructs the new request. The FMS then identifies a specific network node corresponding to the API call within the workflow and establishes a network connection (usually over HTTP or HTTPS) to the identified node using its IP address, hostname, and endpoint URL. Once the request is sent to the network node, the node processes the request based on the API endpoint and
15 received parameters and then formulates a response. Upon receiving the response from the network node, the FMS may parse and interpret the response data. The FMS then performs actions based on the response content, such as logging the result, updating the internal state, triggering further workflow steps, or notifying stakeholders. This process may be repeated for each API call in the sequence. Upon
20 completion of all API calls, the FMS (108) may update an order status based on the responses received from the network nodes and provide a consolidated response to the receiving unit (402). In an aspect, each network node processes the request and sends the response to the FMS. These responses usually contain information or status updates related to the operations performed by the network nodes. The FMS
25 evaluates these responses upon receiving responses from all network nodes involved in the workflow. Based on the content of the responses, such as success indicators, data updates, or error messages, the FMS updates the status of the order being processed. After updating the order status, the FMS consolidates all relevant information and generates a response. This consolidated response may include the
30 overall status of the workflow execution (success or failure), details of any changes
25

or updates made to the order status, and any additional information or data relevant to the processing of the request.
[0089] The set of workflow configuration definitions stored in the memory
(204) of the FMS (108) may play a crucial role in enabling the dynamic 5 configuration and management of APIs. These definitions may comprise various elements, such as request and response schemas for each API, a set of one or more attributes defining data elements required for each API request and response, endpoints indicating the network nodes associated with each API, mappings between one or more attributes in the received request and one or more attributes 10 of each API, the sequence of API calls, and the set of attribute transformations to be performed. In an example, the one or more attributes may include API endpoint (specific URL or path of an API), parameters (input parameters required for the API operation), headers (Information like authentication tokens, content type), and body (data payload sent with the request).
15 [0090] The workflow configuration definitions in the FMS (108) comprise
several key components that enable the efficient configuration and execution of API workflows. Each workflow configuration definition includes a request schema and a response schema for each API in the workflow. For example, a request schema may define the structure and format of an API request as {"customerID": "string",
20 "orderID": "string", "productID": "string" }, while a response schema may define the structure and format of an API response as { "status": "string", "message": "string", "data": { "orderDetails": { ... } } }. The workflow configuration definition also includes a set of attributes for each API, defining the data elements required for each API request and response. For instance, the attributes for an "Order
25 Placement" API may include "customerID", "productID", "quantity", and "shippingAddress". Additionally, the workflow configuration definition specifies the endpoints for each API, indicating the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) associated with each API and where each API request should be sent. An example endpoint could be "https://api.example.com/orders" for an "Order
30 Placement" API. The mappings between the one or more attributes in the received
26

request from the receiving unit (212) and attributes of each API in the workflow are also defined, specifying how data from the received request should be transformed and included in each API request. For example, the "customerID" attribute in the received request may be mapped to the "user_id" attribute in the "Order Placement" 5 API request. The workflow configuration definition also includes the sequence of API calls, defining the order in which the API requests should be sent to the network nodes (404-1, 404-2, 404-3, 404-4, 404-5). For instance, the sequence may specify that the "Order Placement" API should be called first, followed by the "Payment Processing" API, and then the "Order Fulfilment" API. Finally, the workflow
10 configuration definition includes the set of attribute transformations to be performed, defining how data from the received request should be modified before being included in each API request. An example transformation could be converting the date format from "MM-DD-YYYY" in the received request to "YYYY-MM-DD" in the API request. In an aspect, the set of attribute transformations specified
15 in the set of stored workflow configuration definitions includes one or more of matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement. For example, the matching transformation includes identifying and selecting attributes that meet specific criteria or patterns. For another example, the concatenation transformation includes combining multiple attributes or strings
20 into a single entity. Further, the extracting substrings transformation includes retrieving specific segments of data from within attributes or strings. In an example, the dynamic concatenation transformation includes Forming concatenated results based on dynamic conditions or variables. In an example, the removal transformation includes Eliminating specified attributes or parts of attributes from
25 the dataset. In an example, the replacement transformation includes Substituting existing attribute values with new ones according to predefined rules or conditions.
[0091] The request and response schemas may define the structure and
format of the data exchanged between the FMS (108) and the network nodes. The
one or more attributes may specify the data elements required for each API request
30 and response, while the endpoints may indicate where each API request should be
27

sent. The mappings may define how data from the received request should be transformed and included in each API request, and the sequence of API calls may determine the order in which the requests are sent to the network nodes.
[0092] One of the key features of the FMS (108) may be its ability to handle
5 updates to the mappings specified in the workflow configuration definitions. Via a user interface, an administrator may modify the mappings for a specific API. Subsequently, for new requests from the receiving unit (402), the FMS (108) may generate requests for the specific API using the updated mappings. This functionality may provide significant flexibility in accommodating changes to API 10 requirements without necessitating extensive code modifications or system downtime.
[0093] The FMS (108) may further enhance the efficiency of network
operations by automating the creation of workflows based on the information contained in the workflow configuration definitions. By linking the API calls 15 according to the request schemas, response schemas, one or more attributes, and endpoints specified in the definitions, the FMS (108) may generate complete workflows that can be executed seamlessly.
[0094] The network nodes (404-1, 404-2, 404-3, 404-4, 404-5) associated
with the APIs may encompass a wide range of network functions, such as a Policy
20 Control Function (PCF), a Policy and Charging Rules Function (PCRF), a User Data Function (UDF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Slice Selection Function (NSSF), an Over-The-Air (OTA) server, and a Business Telephony Application Server (BTAS). The PCF is responsible for managing and enforcing policies related to
25 network resources and services. It ensures that policies regarding Quality of Service (QoS), traffic prioritization, and other network parameters are implemented and adhered to across the network. The FMS (108) may interact with these nodes to configure and manage the APIs necessary for various network services. The PCRF manages policy control and charging. It determines which services a subscriber can
28

access, and under what conditions, while also handling charging rules for those services. The UDF stores and manages user-related data within the network, such as subscriber profiles, authentication credentials, and service entitlements. The AMF is responsible for managing the mobility of devices within the 5G network. 5 The AMF handles functions such as device registration, authentication, session management, and mobility management to ensure seamless connectivity as devices move between different network areas. The SMF oversees the establishment, management, and termination of sessions between devices and the network. The SMF handles session-related policies, IP address allocation, and traffic routing,
10 ensuring efficient data delivery and management. The NSSF plays a crucial role in 5G networks by selecting and managing network slices based on service requirements and network conditions. The NSSF determines which network slices (virtual networks tailored to specific needs) should be allocated to meet the performance and quality demands of services. The OTA server facilitates the
15 remote management and provisioning of mobile devices and their software applications. The OTA server enables operators to deploy updates, configurations, and settings to devices without requiring physical access, ensuring devices are up-to-date and secure. The BTAS provides telephony services within business environments, offering features such as call routing, voicemail, conferencing, and
20 integration with enterprise communication systems.
[0095] In the process of updating the order status based on the responses
received from the network nodes, the FMS (108) may perform additional tasks, such as finding a free number in an inventory and updating the inventory to reflect the status of the free number. This functionality may be particularly relevant in 25 scenarios where the APIs involve the allocation or management of numbering resources.
[0096] The FMS (108) may provide several advantages over traditional
approaches to API configuration and management. By centralizing the set of
workflow configuration definitions and providing a user-friendly interface for
30 updating mappings, the FMS (108) may reduce the complexity and manual effort
29

involved in accommodating changes to API requirements. This may lead to faster adaptation to new business needs, improved agility, and reduced service disruptions.
[0097] Moreover, the automated generation of workflows based on the
5 configuration definitions may streamline the integration of services across multiple network nodes. By abstracting the complexities of API interactions and providing a unified platform for managing workflows, the FMS (108) may enhance the efficiency and scalability of network operations. This may ultimately result in improved service quality, reduced operational costs, and faster time-to-market for 10 new services.
[0098] The FMS (108) may also promote consistency and standardization
in API configuration and management across the network. By enforcing a common set of workflows, schemas, and transformations, the FMS (108) may reduce the likelihood of errors and inconsistencies that may arise from manual configuration 15 processes. This may contribute to enhanced network stability, security, and reliability.
[0099] Another potential benefit of the FMS (108) may be its extensibility
to support a wide range of network functions and services. As new network nodes and APIs are introduced, the FMS (108) may be easily adapted to incorporate them 20 into existing workflows or create new workflows as needed. This flexibility may enable network operators to quickly embrace emerging technologies and services without requiring significant changes to their underlying management infrastructure.
[00100] In an embodiment illustrated in FIG. 4, the FMS (108) may receive
25 workflow details from a database and start the execution of the workflow for any order. Upon receiving a request from the receiving unit, the FMS (108) may generate a new request and send it to all the relevant network nodes according to the end user requirements. The workflow may be considered complete after processing each state.
30

[00101] Furthermore, the FMS (108) may enable network operators to
optimize their resource utilization by allowing them to reuse and repurpose existing API components across different workflows. By defining a library of reusable API building blocks and enabling their composition through the workflow configuration 5 definitions, the FMS (108) may promote code reuse, reduce development efforts, and improve the overall efficiency of network operations.
[00102] The FMS (108) may also facilitate the monitoring and
troubleshooting of API workflows. By providing a centralized platform for managing and tracking the execution of workflows, the FMS (108) may enable 10 network operators to quickly identify and resolve issues that may arise during the provisioning or modification of services. This may lead to faster problem resolution, reduced downtime, and improved service quality.
[00103] Moreover, the FMS (108) may provide valuable insights and
analytics into the performance and usage of APIs across the network. By collecting 15 and analyzing data on API invocations, response times, error rates, and other relevant metrics, the FMS (108) may help network operators identify bottlenecks, optimize resource allocation, and make data-driven decisions to improve the overall efficiency and effectiveness of their network operations.
[00104] FIG. 5 illustrates another exemplary flow chart (500) implementing
20 a method for configuring the APIs in the network.
[00105] In step 502, the FMS (108) stores a set of workflow configuration
definitions in the memory (204). The memory (204) is coupled to one or more processors (202), which execute instructions to perform various operations. The memory (204) is responsible for storing data, including the set of workflow 25 configuration definitions and a set of instructions for configuring APIs in a network. The set of workflow configuration definitions stored in the memory (204) defines the structure and format of requests and responses for each API, including a request schema and a response schema. These schemas establish a structured format for requests and responses, define endpoints, mappings, and automate the creation of a
31

complete workflow. The FMS (108) may create a request/response schema, a set of attributes, endpoints, mappings with all the network nodes (404-1, 404-2, 404-3, 404-4, 404-5), and create a complete workflow by linking all the API calls automatically. The FMS (108) supports multiple types of mapping to derive values 5 for the one or more attributes from the request and send the derived values to the interface. This includes attribute transformations such as matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement. The FMS (108)'s flexibility allows it to cater to any changes in the APIs by simply changing the configuration from the FMS user interface.
10 [00106] In step 504, the FMS (108) receives the request from a Northbound
Interface (also referred to as receiving unit (402)) containing one or more attributes corresponding to a plurality of APIs associated with network nodes (404-1, 404-2, 404-3, 404-4, 404-5). In an example, the one or more attributes may include API endpoint (specific URL or path of an API), parameters (input parameters required
15 for the API operation), headers (Information like authentication tokens, content type), and body (data payload sent with the request). This step initiates the API configuration process. The FMS (108) is designed to handle this request by executing a sequence of API calls and providing a final response upon completion. The FMS (108) takes a single request containing a superset of all attributes of all
20 the APIs and executes the sequence of API calls. The FMS (108) may receive workflow details from a database (210) and start execution of the workflow for any order. Upon receiving the request from the receiving unit (402), the FMS (108) generates a new request and sends it to all network nodes (404-1, 404-2, 404-3, 404-4, 404-5) subsequently as per end user requirements. The workflow is completed
25 after processing each API call, ensuring that the FMS (108) can handle changes in the APIs flexibly.
[00107] In step 504, the FMS (108) receives an update to the mappings
specified in the set of workflow configuration definitions for a specific API via a
user interface of the FMS (108). This step allows the FMS (108) to adapt to changes
30 in the APIs by enabling configuration changes through the user interface without
32

the need for new releases or code changes. The mappings define how data from the received request should be transformed and included in each API request, ensuring that the FMS (108) can derive values for one or more attributes from the request and send these values to the interface using various types of mappings. The user 5 may log in to the FMS user interface, select the required workflow and its state upon receiving the request from the receiving unit (402), and perform attribute transformations such as match, concatenation, substring, dynamic concatenation, remove, replace, etc., based on the end user requirements.
[00108] In step 506, the FMS (108) determines a workflow based on the
10 workflow configuration definitions, where the workflow comprises a sequence of API calls. This step establishes the order and process of API interactions necessary for fulfilling the request. The set of workflow configuration definitions comprise a request schema and a response schema for each API in the workflow, defining the structure and format of requests and responses. The FMS (108) creates the
15 workflow by linking the API calls based on the request schemas, response schemas, one or more attributes, and endpoints specified in the workflow configuration definitions. The FMS (108) supports multiple workflow patterns, including sequential, parallel, conditional, and loop, allowing it to cater to various processing requirements and adapt to different scenarios. Upon receiving the set of stored
20 workflow configuration definitions, the one or more processors are configured to determine the workflow corresponding to the request by matching the incoming request with the set of stored workflow configuration definitions. When the request is received, the system needs to identify or select the appropriate workflow configuration from the stored definitions. This determination could be based on
25 parameters or attributes within the request, such as the type of operation requested, specific identifiers, or conditions associated with the workflow. Once the appropriate workflow configuration is identified, it outlines a series of steps or actions that need to be executed. These steps typically involve making API calls to different services, systems, or endpoints to perform specific tasks or operations.
33

[00109] In step 506, the set of workflow configuration definitions further
comprise a set of the one or more attributes for each API in the workflow, defining the data elements required for each API request and response. The endpoints for each API indicate the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) associated 5 with each API and specify where each API request should be sent. The mappings between one or more attributes in the received request from the receiving unit (402) and one or more attributes of each API define how data from the received request should be transformed and included in each API request. The sequence of API calls defines the order in which the API requests should be sent to the network nodes 10 (404-1, 404-2, 404-3, 404-4, 404-5). The attribute transformations define how data from the received request should be modified before being included in each API request.
[00110] In sub-step 506, the FMS (108) creates the workflow by linking the
API calls based on the request schemas, response schemas, one or more attributes, 15 and endpoints specified in the workflow configuration definitions. This process establishes a structured format for requests and responses, defines endpoints, mappings, and automates the creation of a complete workflow. The FMS (108) may include an operation and management module (602), a load balancer (604), a workflow manager (606), a dynamic activator (608), databases (610-1, 610-2, 610-20 3), a user interface (612), a dynamic routing manager (614), and a command line interface (616). The workflow manager (606) streamlines and standardizes different processes as workflows. The FMS (108) supports sequential, parallel, conditional, and loop workflow patterns, increasing flexibility to cater to any changes in the APIs.
25 [00111] In step 508, the FMS (108) generates a new request for each API call
in the sequence by deriving values for one or more attributes of the API from the one or more attributes in the received request using mappings specified in the workflow configuration definitions. The FMS (108) is designed to handle a sequence of API calls and manage multiple API requests in a structured order. The
30 mappings define how data from the received request should be transformed and
34

included in each API request. The FMS (108) supports attribute transformations such as matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement to ensure that the data is correctly formatted and prepared for each specific API call. The FMS (108) can fetch data from the response of one 5 network node (e.g., 404-1), split the data if necessary, and store it for use in subsequent API calls to other network nodes (e.g., 404-2).
[00112] In step 510, the FMS (108) performs a set of attribute
transformations specified in the workflow configuration definitions. This step ensures that the data from the received request is appropriately modified before
10 being included in each API request. The attribute transformations include operations such as matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement. The FMS (108) takes a single request containing a superset of all one or more attributes of all the APIs and executes a sequence of API calls, providing a final response after the completion of single or
15 all API calls. The set of workflow configuration definitions define the structure and format of requests and responses for each API, establish the one or more attributes required for each API request and response, and specify the endpoints indicating where each API request should be sent.
[00113] In step 510, the attribute transformations are performed as specified
20 in the set of workflow configuration definitions to modify the data from the received request before including it in each API request. The FMS (108)'s ability to perform these attribute transformations and mappings is enhanced by its support for sequential, parallel, conditional, and loop workflow patterns. This flexibility allows the FMS (108) to cater to various end-user requirements and adapt to changing 25 network conditions dynamically. For example, the FMS (108) may fetch data from the response of network node 1 (404-1), split the data, and store it if the end-user requirements change and network node 2 (404-2) requires data from network node 1 (404-1). The FMS (108) can then send the stored data to network node 2 (404-2), ensuring seamless communication and data flow between different network nodes.
35

[00114] In step 512, the FMS (108) sends the new request to a corresponding
network node (404-1, 404-2, 404-3, 404-4, or 404-5). The FMS (108) is designed to configure API requests in a network, adapting to changes in APIs by simply changing the configuration from the FMS user interface. The FMS (108) takes a 5 single request containing a superset of one or more attributes of all the APIs and executes a sequence of API calls, providing a final response after the completion of single/all API calls. The load balancer (604) may distribute the load evenly between network nodes to improve application performance and may redirect client requests to a geographically closer network node to reduce latency. The dynamic routing 10 manager allows network nodes to dynamically adjust to changing network conditions, ensuring efficient and redundant routing continues despite any changes.
[00115] In step 512, the network nodes (404-1, 404-2, 404-3, 404-4, 404-5)
to which the FMS (108) sends the new requests may include one or more of the following: a Policy Control Function (PCF), a Policy and Charging Rules Function
15 (PCRF), a User Data Function (UDF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Slice Selection Function (NSSF), an Over-The-Air (OTA) server, and a Business Telephony Application Server (BTAS). The FMS (108)'s ability to send the new request to a corresponding network node is a step in the workflow, ensuring that the
20 derived values for one or more attributes are communicated effectively to the appropriate network nodes, thereby facilitating the seamless execution of the API calls and the overall workflow. In an aspect, upon determining the necessary attributes and parameters for each API call as per the workflow configuration, the FMS constructs the new request. The FMS then identifies a specific network node
25 corresponding to the API call within the workflow and establishes a network connection (usually over HTTP or HTTPS) to the identified node using its IP address, hostname, and endpoint URL.
[00116] In step 514, the FMS (108) receives a response from the
corresponding network node (404-1, 404-2, 404-3, 404-4, or 404-5). This step
30 marks the completion of the API call sequence initiated by the FMS (108). The
36

FMS (108), which is designed to configure API requests in a network, processes the response to ensure that the requested operations have been successfully executed by the network node. Once the request is sent to the network node, the node processes the request based on the API endpoint and received parameters and 5 then formulates a response. Upon receiving the response from the network node, the FMS may parse and interpret the response data. The FMS then performs actions based on the response content, such as logging the result, updating the internal state, triggering further workflow steps, or notifying stakeholders.
[00117] In step 516, the FMS (108) updates an order status based on the
10 responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5. In
an aspect, each network node processes the request and sends the response to the
FMS. These responses usually contain information or status updates related to the
operations performed by the network nodes. The FMS evaluates these responses
upon receiving responses from all network nodes involved in the workflow. Based
15 on the content of the responses, such as success indicators, data updates, or error
messages, the FMS updates the status of the order being processed. After updating
the order status, the FMS consolidates all relevant information and generates a
response. This consolidated response may include the overall status of the workflow
execution (success or failure), details of any changes or updates made to the order
20 status, and any additional information or data relevant to the processing of the
request.
[00118] In step 518, the FMS (108) provides a response to the receiving unit.
The response is based on the updated order status and the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5). In an aspect, each network
25 node processes the request and sends the response to the FMS. These responses usually contain information or status updates related to the operations performed by the network nodes. The FMS evaluates these responses upon receiving responses from all network nodes involved in the workflow. Based on the content of the responses, such as success indicators, data updates, or error messages, the FMS
30 updates the status of the order being processed. After updating the order status, the
37

FMS consolidates all relevant information and generates a response. This consolidated response may include the overall status of the workflow execution (success or failure), details of any changes or updates made to the order status, and any additional information or data relevant to the processing of the request.
5 [00119] In another embodiment, the present disclosure relates to a user
equipment (104) communicatively coupled to a Fulfilment Management System (FMS) (108) through a network (106). The FMS (108) comprises one or more processors (202) and a memory (204) coupled to the processors (202). The memory (204) stores a set of workflow configuration definitions and instructions that, when
10 executed by the processors (202), cause the FMS (108) to perform the steps of a method (500) for configuring APIs in the network. The method involves storing a set of workflow configuration definitions in the memory (204) and receiving a request from a receiving unit (212). The receiving unit may be a Northbound Interface (NBI). The request may contain one or more attributes corresponding to a
15 plurality of APIs associated with network nodes (404-1, 404-2, 404-3, 404-4, 404-5), determining a workflow based on the workflow configuration definitions, where the workflow comprises a sequence of API calls, and for each API call in the sequence, generating a new request by deriving values for one or more attributes of the API from the one or more attributes in the received request using mappings
20 specified in the workflow configuration definitions, performing a set of attribute transformations, sending the new request to a corresponding network node, and receiving a response from the corresponding network node. The method further includes updating an order status based on the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) and providing a response to the receiving
25 unit (402) based on the updated order status and the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5).
[00120] FIG. 6 illustrates another exemplary architecture (600) of the FMS
(108), in accordance with an embodiment of the present disclosure. FIG. 6 showcases the various components and modules that work together to enable the 30 dynamic configuration and management of the APIs in the network.
38

[00121] At the core of the FMS (108) lies the workflow manager (606), a
critical component responsible for streamlining and standardizing different processes as workflows. The workflow manager (606) may play a pivotal role in defining, executing, and monitoring the API workflows based on the set of 5 workflow configuration definitions stored in the FMS (108). It may orchestrate the interaction between different modules and databases to ensure the smooth execution of API requests and responses.
[00122] To support the workflow manager (606) and enhance the overall
performance and scalability of the FMS (108), the architecture (600) includes a load 10 balancer (604). The load balancer (604) may distribute the incoming API requests evenly across multiple network nodes, ensuring optimal resource utilization and improved application performance. By redirecting client requests to geographically closer network nodes, the load balancer (604) may also help reduce latency and improve the responsiveness of the system.
15 [00123] The FMS (108) may also incorporate an operation and management
module (602), which may handle various critical functions related to network management. This module may be responsible for tasks such as network inventory management, addressing provisioning issues, monitoring network availability, and handling fault management. By centralizing these functions within the FMS (108),
20 the operation and management module (602) may provide a comprehensive view of the network's health and performance, enabling proactive issue resolution and ensuring the smooth operation of API-driven services.
[00124] To enable the dynamic activation and configuration of APIs, the
FMS (108) may include a dynamic activator (608). This component may work 25 closely with the workflow manager (606) to instantiate and configure the necessary API endpoints and resources based on the workflow configuration definitions. The dynamic activator (608) may also handle the allocation and management of numbering resources, such as finding free numbers in an inventory and updating the inventory status based on API responses.
39

[00125] The FMS (108) may rely on a set of databases to store and manage
various types of data related to the API workflows and network nodes. The architecture (600) depicts three specific databases: a graph database (610-1), a distributed data lake (610-2), and a cache data store (610-3). The graph database 5 (610-1) may be used to store and query complex relationships between API endpoints, one or more attributes, and transformations, enabling efficient traversal and analysis of the API workflow graphs. The distributed data lake (610-2) may serve as a scalable and flexible repository for storing large volumes of structured and unstructured data generated by the API workflows and network nodes. The 10 cache data store (610-3) may be employed to store frequently accessed data in memory, reducing the latency of API requests and improving overall system performance.
[00126] To facilitate user interaction and control over the FMS (108), the
architecture (600) includes both a user interface (612) and a command line interface
15 (616). The user interface (612) may provide a graphical and intuitive means for users to configure API workflows, update mappings, monitor system performance, and perform various administrative tasks. It may offer a user-friendly environment for defining workflow configuration definitions, setting up API endpoints, and managing the overall operation of the FMS (108). On the other hand, the command
20 line interface (616) may cater to more advanced users who prefer to interact with the system using textual commands and scripts. It may provide a powerful and flexible way to automate repetitive tasks, perform bulk operations, and integrate the FMS (108) with other tools and systems.
[00127] In addition to these components, the FMS (108) may incorporate a
25 dynamic routing manager (614) to enable intelligent and adaptive routing of API requests across the network. The dynamic routing manager (614) may continuously monitor the network conditions, such as node availability, performance metrics, and congestion levels, and dynamically adjust the routing paths to ensure optimal performance and reliability. By leveraging advanced algorithms and real-time 30 network telemetry, the dynamic routing manager (614) may enable the FMS (108)
40

to automatically adapt to changing network conditions and maintain efficient and redundant routing even in the face of failures or disruptions.
[00128] The interaction and collaboration among these various components
of the FMS (108) may enable a highly flexible, scalable, and resilient platform for 5 configuring and managing APIs in a network. The modular architecture (600) allows for the easy addition, removal, or modification of components as the needs of the network evolve, ensuring that the FMS (108) can keep pace with the dynamic nature of modern network environments.
[00129] For example, as new types of network nodes or APIs are introduced,
10 the FMS (108) may easily incorporate them into the workflow manager (606) and dynamic activator (608), enabling seamless integration and management of these new entities. Similarly, if the volume of data generated by the API workflows grows significantly, the distributed data lake (610-2) may be scaled out to accommodate the increased storage requirements without impacting the overall performance of 15 the system.
[00130] The user interface (612) and command line interface (616) may also
play a crucial role in empowering network operators and administrators to effectively manage and control the FMS (108). By providing intuitive and flexible means of interacting with the system, these interfaces may enable users to quickly 20 adapt to changing requirements, troubleshoot issues, and optimize the performance of the API workflows.
[00131] Moreover, the operation and management module (602) and
dynamic routing manager (614) may work together to ensure the overall health, reliability, and efficiency of the network. By continuously monitoring the network 25 conditions and automatically adapting the routing paths, these components may help minimize the impact of failures, congestion, or other issues on the API workflows, ensuring that the network remains responsive and available even under adverse conditions.
41

[00132] In another embodiment, the architecture (600) may comprise a
message broker queuing engine (620) may be a middleware component that facilitates asynchronous communication between different parts of a system using a message-oriented approach. It acts as an intermediary between the message 5 producers (senders) and message consumers (receivers), allowing them to communicate without being directly connected or aware of each other's existence.
[00133] In the FMS (108) architecture, the message broker queuing engine
(620) may be introduced to decouple the various components and modules, such as the workflow manager (606), dynamic activator (608), and network nodes (404-1, 10 404-2, 404-3, 404-4, 404-5). Instead of directly sending API requests and responses between these components, the message broker queuing engine may act as a central hub for managing the flow of messages.
[00134] The architecture (600) of the FMS (108) presented in FIG. 6
showcases a comprehensive and modular platform for configuring and managing
15 APIs in a network. By leveraging the power of a workflow manager (606), load balancer (604), dynamic activator (608), databases (610-1, 610-2, 610-3), user interface (612), dynamic routing manager (614), and command line interface (616), the FMS (108) may provide a highly flexible, scalable, and resilient solution for orchestrating API-driven services across complex network environments. As the
20 demands on networks continue to grow and evolve, the FMS (108) may serve as a critical tool for network operators and administrators, enabling them to efficiently manage and optimize the delivery of API-based services to their customers.
[00135] Now referring to FIG. 7 illustrates an example flowchart of the
method, in accordance with an embodiment of the present disclosure.
25 [00136] FIG. 7 illustrates another exemplary flow chart (700) implementing
a method for configuring APIs using the FMS (108), in accordance with an embodiment of the present disclosure.
42

[00137] In the step (702) the user logging in to the FMS via a user interface.
Upon receiving the request from the Northbound Interface (receiving unit) (402), the method includes selecting (704) a required workflow and its state.
[00138] The method then proceeds to perform (706) operations such as
5 match, concatenation, substring, dynamic concatenation, remove, replace, etc., based on the end user requirements. For example, if the end user requirements change and the network node 2 (404-2) requires data from the network node 1 (404-1), the method may include fetching data from the response of network node 1 (404-1), splitting the data, and storing the same for network node 2 (404-2).
10 [00139] After performing the necessary operations and transformations, the
method includes using (708) the stored one or more attributes and sending them to the corresponding network node, in this case, network node 2 (404-2).
[00140] The method concludes (710) after sending the data to the required
network node and fulfilling the end user requirements.
15 [00141] The flow chart (700) provides a visual representation of the steps
involved in configuring APIs using the FMS (108). The user interface of the FMS (108) allows users to select the appropriate workflow and perform various data transformations based on the specific requirements of each network node (404-1, 404-2, 404-3, 404-4, 404-5). This flexibility enables the FMS (108) to adapt to
20 changing end user requirements and ensure that the necessary data is sent to the corresponding network nodes for processing.
[00142] The FMS (108) may also provide the capability to handle changes in
end user requirements dynamically. For instance, if the requirements change and a particular network node (e.g., network node 2) requires data that exists in the one 25 or more attributes of another network node (e.g., network node 1), a user may log in to the FMS user interface and update the request mapping for network node 2 by splitting the attribute of network node 1 and storing it for network node 2. This process may allow the workflow to be updated by modifying the workflow
43

configuration without requiring any code changes. After the changes are made, all subsequent order executions may follow the latest workflow.
[00143] The ability to dynamically update workflows based on changing end
user requirements may provide significant advantages in terms of flexibility and 5 responsiveness. Network operators may be able to quickly adapt to new demands and service requests without going through lengthy development and deployment cycles. This may lead to improved customer satisfaction, as services can be provisioned and modified more rapidly in response to user needs.
[00144] FIG. 8 illustrates an exemplary block diagram (800) of the system,
10 in accordance with an embodiment of the present disclosure.
[00145] Referring to FIG. 8, in one exemplary embodiment the FMS (108)
receives a request from a receiving unit (402), which may be a northbound interface (receiving unit) or any other component responsible for sending requests to the FMS (108). In an example, the received request includes various attributes such as 15 “layer”, and “super core”. The received request refers to configuring an API with a "layer" named "Metro Super core."
[00146] Upon receiving the request, the FMS (108) processes the received
request. The FMS (108) then determines the appropriate network nodes (404-1, 404-2) to which the request should be sent based on the information contained in
20 the request. The FMS (108) generates new requests specific to each network node (404-1, 404-2) by deriving the necessary one or more attributes and values from the original request. The FMS (108) sends the generated requests to the corresponding network nodes (404-1, 404-2) for processing. Each network node (404-1, 404-2) receives the request, performs the necessary operations, and sends a response back
25 to the FMS (108).
[00147] The FMS (108) collects the responses from the network nodes (404-
1, 404-2) and processes them to update the order status and generate a final
44

response. The FMS (108) then sends the final response back to the receiving unit (402), completing the request processing cycle.
[00148] The block diagram (800) illustrates how the FMS (108) acts as a
central entity for managing and orchestrating the communication between the 5 receiving unit (402) and the network nodes (404-1, 404-2). By processing the incoming request, generating node-specific requests, and aggregating the responses, the FMS (108) enables efficient and coordinated interaction between the different components of the network.
[00149] In an aspect, the FMS receives a request from the receiving unit
10 (402). The FMS processes the request to determine which specific network elements (nodes) need to be involved. For example, Node (404-1) represents the Core Network controller responsible for policy enforcement and network management, while Node (404-2) represents a specific Radio Access Network (RAN) node responsible for managing radio resources in a particular geographic 15 area.
[00150] The FMS generates API requests tailored for each identified network
node. For Node (404-1), the generated API includes attributes such as traffic data, QoS policy, and priority levels, enabling the node (404-1) to adjust network policies, allocate additional bandwidth, and prioritize traffic types based on current 20 demand. Similarly, for the node (404-2), the generated API includes attributes like coverage area, radio resources, and signal strength, enabling the node (404-2) to optimize radio resources, adjust antenna configurations, and enhance coverage in affected areas.
[00151] The FMS uses HTTP (Hypertext Transfer Protocol) requests to send
25 the configured API requests to the respective endpoints of the nodes (404-1, 404-2). Each network node (404-1, 404-2) receives its API request, processes the data, and executes necessary operations. The FMS then awaits responses the nodes, which confirm the successful execution of requested operations. Subsequently, the
45

FMS consolidates these responses, updates the network status, and prepares a final response summarizing the actions taken.
[00152] FIG. 9 illustrates a computer system (900) in which or with which
the embodiments of the present disclosure may be implemented.
5 [00153] As shown in FIG. 9, the computer system (900) may include an
external storage device (910), a bus (920), a main memory (930), a read-only memory (940), a mass storage device (950), a communication port(s) (960), and a processor (990). A person skilled in the art will appreciate that the computer system (900) may include more than one processor and communication ports. The
10 processor (990) may include various modules associated with embodiments of the present disclosure. The communication port(s) (960) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication ports(s) (960) may be chosen
15 depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (900) connects.
[00154] In an embodiment, the main memory (930) may be Random Access
Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (940) may be any static storage device(s) e.g., but not
20 limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor (990). The mass storage device (950) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced
25 Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces).
[00155] In an embodiment, the bus (920) may communicatively couple the
processor(s) (990) with the other memory, storage, and communication blocks. The
46

bus (920) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (990) 5 to the computer system (900).
[00156] In another embodiment, operator, and administrative interfaces, e.g.,
a display, keyboard, and cursor control device may also be coupled to the bus (920) to support direct operator interaction with the computer system (900). Other operator and administrative interfaces can be provided through network 10 connections connected through the communication port(s) (960). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (900) limit the scope of the present disclosure.
[00157] The present disclosure provides technical advancement related to
15 transitioning requests to multiple southbound requests. This advancement addresses the limitations of manual configuration changes. The present disclosure also meets the immediate need for changing the configuration using the user interface of the FMS, without requiring new releases, downtime, or code-level changes. The present disclosure saves development and integration efforts. Furthermore, the 20 present disclosure provides a cost-effective solution by not requiring building codes for individual interfaces and offering quick connectivity.
[00158] The method and system of the present disclosure may be
implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any 25 combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs
47

including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
5 [00159] While considerable emphasis has been placed herein on the preferred
embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the 10 disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the disclosure and not as limitation.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00160] The present disclosure provides technical advancement related to a
15 Fulfilment Management System (FMS) and a method for configuring application programming interfaces (APIs) in a network.
[00161] The present disclosure provides technical advancement related to the
FMS and the method that caters to any changes in APIs, by simply changing the configuration from an FMS user interface.
20 [00162] The present disclosure provides technical advancement related to the
FMS and the method that takes a single request containing a superset of all attributes of all the APIs and executes a sequence of API calls and provides a final response after completion of single/all APIs.
[00163] The present disclosure provides technical advancement related to the
25 FMS and the method that increases flexibility to cater to any changes in the APIs.
48

[00164] The present disclosure provides technical advancement related to the
FMS and the method that supports multiple types of mapping in order to derive attribute values from the request and send the derived values to the interface.
[00165] The present disclosure provides technical advancement related to the
5 FMS and the method that supports sequential, parallel, conditional, and loop workflow patterns.
49

We Claim:
1. A fulfilment management system (FMS) (108) for configuring application programming interfaces (APIs) in a network, the FMS (108) comprising:
one or more processors (202); and
a memory (204) coupled to the one or more processors (202), the memory (204) is configured to store a set of workflow configuration definitions and a set of instructions that, when executed by the one or more processors (202), cause the one or more processors (202) to configure the APIs by:
receiving, by a receiving unit (212), a request containing one or more attributes corresponding to a plurality of APIs associated with network nodes (404-1, 404-2, 404-3, 404-4, 404-5);
determining, based on the set of stored workflow configuration definitions, a workflow corresponding to the request, the workflow comprising a sequence of API calls;
for each API call in the sequence:
generating a new request by deriving one or more values for the one or more attributes corresponding to each API call using mappings specified in the set of stored workflow configuration definitions;
performing a set of attribute transformations stored in the set of stored workflow configuration definitions;
sending the new request to a corresponding network node; and

receiving a response from the corresponding network node;
updating an order status based on the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5); and
providing, to the receiving unit (212), a response based on the updated order status and the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5).
2. The FMS (108) of claim 1, wherein the set of stored instructions, when
executed by the one or more processors (202), further cause the FMS (108)
to:
receive, via a user interface, an update to the mappings specified in the set of stored workflow configuration definitions for a specific API; and
for subsequent requests from the receiving unit (212), generate new requests for the specific API using the updated mappings specified in the set of stored workflow configuration definitions.
3. The FMS (108) of claim 1, wherein each workflow configuration definition
comprises:
a request schema and a response schema for each API in the workflow, the request schema defining a structure and format of requests for each API, and the response schema defining a structure and format of responses for each API;
a set of attributes for each API in the workflow, the set of attributes defining data elements required for each API request and response;

end points for each API in the workflow, the end points indicating the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) associated with each API, wherein the end points specify where each API request should be sent;
the mappings between attributes in the received request from the receiving unit (212) and attributes of each API in the workflow, the mappings defining how data from the received request should be transformed and included in each API request;
the sequence of API calls, the sequence defining an order in which the API requests should be sent to the network nodes (404-1, 404-2, 404-3, 404-4, 404-5); and
the set of attribute transformations to be performed, the attribute transformations defining how data from the received request should be modified before being included in each API request.
4. The FMS (108) of claim 1, wherein the set of stored instructions, when executed by the one or more processors (202), further cause the FMS (108) to create the workflow by linking the API calls based on the request schemas, the response schemas, the attributes, and the end points specified in the workflow configuration definitions.
5. The FMS (108) of claim 1, wherein the set of attribute transformations specified in the set of stored workflow configuration definitions includes one or more of matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement.
6. The FMS (108) of claim 1, wherein the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) include one or more of a Policy Control Function (PCF), a Policy and Charging Rules Function (PCRF), a User Data Function (UDF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Slice Selection Function (NSSF),

an Over-The-Air (OTA) server, and a Business Telephony Application Server (BTAS).
7. The FMS (108) of claim 1, wherein updating the order status based on the
responses received from the network nodes (404-1, 404-2, 404-3, 404-4,
404-5) includes:
finding a free number in an inventory based on the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5), wherein the free number is a number that is not currently assigned to any user or service; and
updating the inventory to reflect the status of the free number.
8. A method (500) for configuring application programming interfaces (APIs)
in a network, the method comprising:
storing (502), in a memory (204), a set of workflow configuration definitions and a set of instructions;
receiving (504), by a receiving unit (212), a request containing one or more attributes corresponding to a plurality of APIs associated with network nodes (404-1, 404-2, 404-3, 404-4, 404-5);
determining (506), by one or more processors (202), based on the set of stored workflow configuration definitions, a workflow corresponding to the request, the workflow comprising a sequence of API calls;
for each API call in the sequence:
generating (508), by the one or more processors (202), a new request by deriving values for one or more attributes corresponding to each API call using mappings specified in the set of stored workflow configuration definitions,

performing (510), by the one or more processors (202), a set of attribute transformations stored in the set of stored workflow configuration definitions,
sending (512), by the one or more processors (202), the new request to a corresponding network node, and
receiving (514), by the one or more processors (202), a response from the corresponding network node;
updating (516), by the one or more processors (202), an order status based on the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5); and
providing (518), by the one or more processors (202) to the receiving unit (212), a response based on the updated order status and the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5).
9. The method (500) of claim 8, further comprising:
receiving, via a user interface, an update to the mappings specified in the set of stored workflow configuration definitions for a specific API; and
for subsequent requests from the receiving unit (212), generating, by the one or more processors (202), new requests for the specific API using the updated mappings specified in the workflow configuration definitions.
10. The method (500) of claim 8, wherein each workflow configuration
definitions further comprises:
a request schema and a response schema for each API in the workflow, the request schema defining a structure and format of requests

for each API, and the response schema defining a structure and format of responses for each API;
a set of attributes for each API in the workflow, the set of attributes defining data elements required for each API request and response;
end points for each API in the workflow, the end points indicating the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) associated with each API, wherein the end points specify where each API request should be sent;
the mappings between attributes in the received request from the receiving unit (212) and attributes of each API in the workflow, the mappings defining how data from the received request should be transformed and included in each API request;
the sequence of API calls, the sequence defining an order in which the API requests should be sent to the network nodes (404-1, 404-2, 404-3, 404-4, 404-5); and
the set of attribute transformations to be performed, the attribute transformations defining how data from the received request should be modified before being included in each API request.
11. The method (500) of claim 8, further comprising creating, by the one or more processors (202), the workflow by linking the API calls based on the request schemas, the response schemas, the attributes, and the end points specified in the workflow configuration definitions.
12. The method (500) of claim 8, wherein the set of attribute transformations specified in the workflow configuration definitions includes one or more of matching, concatenation, extracting substrings, dynamic concatenation, removal, and replacement.

13. The method (500) of claim 8, wherein the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) include one or more of a Policy Control Function (PCF), a Policy and Charging Rules Function (PCRF), a User Data Function (UDF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Network Slice Selection Function (NSSF), an Over-The-Air (OTA) server, and a Business Telephony Application Server (BTAS).
14. The method (500) of claim 8, wherein updating the order status based on the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5) includes:
finding a free number in an inventory based on the responses received from the network nodes (404-1, 404-2, 404-3, 404-4, 404-5), wherein the free number is a number that is not currently assigned to any user or service; and
updating the inventory to reflect the status of the free number.
15. A user equipment (104) communicatively coupled to a fulfilment
management system (FMS) (108) through a network (106), wherein the
FMS (108), comprising:
one or more processors (202); and
a memory (204) coupled to the one or more processors (202), the memory (204) is configured to store a set of workflow configuration definitions and a set of instructions that, when executed by the one or more processors (202), cause the FMS (108) to perform steps of a method (500) as claimed in claim 8.