Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
CO-EXISTENCE FRAMEWORK FOR APPLICATION MIGRATION

Applicant
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India

Preamble to the description:

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The disclosure herein generally relates to the field of co-existence framework, and, more particularly, to a method and system for a co-existence framework for an application migration.

BACKGROUND
[002] In the rapidly evolving landscape of banking solutions, the concept of co-existence has gained prominence. Co-existence refers to the integration of new technologies and functionalities with existing legacy systems, allowing banks to modernize their operations while maintaining compatibility and minimizing disruptions. Traditionally, banks have relied on legacy systems that have been customized and tailored to their specific requirements over the years. These systems, though effective, often lack the capabilities to meet the changing demands of customers and the market. As a result, banks have sought to incorporate modern solutions such as digital banking platforms, mobile applications, and advanced analytics.
[003] Legacy systems can be highly complex, with interdependencies and customizations that are difficult to untangle. Integrating them with new technologies requires careful planning and execution to ensure seamless communication and data exchange. Coexistence involves the integration of data from multiple systems, which may have different data structures and formats. Ensuring data consistency and accuracy across systems poses a significant challenge and requires robust data integration strategies. Banks operate in a heavily regulated environment and ensuring the security and compliance of coexisting systems is paramount. Maintaining consistent security measures and adhering to regulatory standards across both legacy and new systems requires comprehensive risk management strategies. Coexistence can impact the user experience if not implemented thoughtfully. Seamless integration and consistent user interfaces are crucial to ensure a smooth transition for customers and employees, minimizing disruption and facilitating adoption of new functionalities. Hardly, any attempts are identified that address the technical problem of seamless integration etc.
SUMMARY
[004] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a method for a co-existence (Co-Ex) framework for an application migration is provided. The processor-implemented method includes receiving, via an input/output interface, at least one transaction request initiated by a user, wherein the at least one transaction request is in a predefined format and determining, via one or more hardware processors, one or more legs present in the received transaction request using a resolver of the Co-Ex framework, wherein the resolver provides a host number associated to each of the one or more legs present in the received transaction request.
[005] Further, the processor-implemented method comprises generating, via the one or more hardware processors, a sequence of one or more services using the resolver based on the host number associated to each of one or more legs present in the received transaction request, invoking, via the one or more hardware processors, one or more hosts using a service invoker of the Co-Ex framework based on the each of the one or more legs in the received transaction request, wherein the one or more hosts is a (1) RESTful or (2) a byte stream TCP/IP socket communication and transforming, via the one or more hardware processors, the received transaction request into a format of invoked one or more hosts using a request transformer of the Co-Ex framework, wherein type and specification of the transformation are configured with the one or more host services in service.xml file.
[006] Furthermore, the processor-implemented method comprises sending, via the one or more hardware processors, the transformed transaction request with the respective host of the one or more hosts using the service invoker, wherein the respective host sends a response back to the service invoker to convert into a Co-Ex format using a response transformer, executing iteratively, via the one or more hardware processors, the generated sequence of the one or more services with the respective host of the one or more hosts using the service invoker and analyzing, via the one or more hardware processors, the response from the respective one or more hosts using a compensator of the Co-Ex framework to identify one or more successful and one or more failed services, wherein the compensator stops current execution of the service if the response from the respective host is fail. Finally, the processor-implemented method comprises initiating, via the one or more hardware processors, a compensation for the one or more failed services by the compensator, wherein the execution of the one or more failed services is passed to the resolver for invocation of a correction services and aggregating, via the one or more hardware processors, response of the identified one or more successful and one or more failed services from each of the one or more hosts in a single response to share with the user to complete the transaction request using the Co-Ex framework.
[007] In another aspect, a system for a co-existence (Co-Ex) framework for an application migration is provided. The system comprises a memory storing a plurality of instructions and one or more Input/Output (I/O) interfaces to receive at least one transaction request initiated by a user, wherein the at least one transaction request is in a predefined format. Further, the system comprises one or more hardware processors coupled to the memory via the one or more I/O interfaces, wherein the one or more hardware processors are configured by the instructions to . Further, the one or more hardware processors are configured to determine one or more legs present in the received transaction request using a resolver of the Co-Ex framework, wherein the resolver provides a host number associated to each of the one or more legs present in the received transaction request. Furthermore, the one or more hardware processors are configured to generate a sequence of one or more services using the resolver based on the host number associated to each of one or more legs present in the received transaction request.
[008] Further, the one or more hardware processors are configured to generate a sequence of one or more services using the resolver based on the host number associated to each of one or more legs present in the received transaction request. Further, the one or more hardware processors are configured to invoke one or more hosts using a service invoker of the Co-Ex framework based on the each of the one or more legs in the received transaction request, wherein the one or more hosts is a (1) RESTful or (2) a byte stream TCP/IP socket communication. Furthermore, the one or more hardware processors are configured to transform the received transaction request into a format of invoked one or more hosts using a request transformer of the Co-Ex framework, wherein type and specification of the transformation are configured with the one or more host services in service.xml file. The transformed transaction request is sent with the respective host of the one or more hosts using the service invoker, wherein the respective host sends a response back to the service invoker to convert into a Co-Ex format using a response transformer.
[009] Further, the one or more hardware processors are configured to execute iteratively the generated sequence of the one or more services with the respective host of the one or more hosts using the service invoker. The response from the respective one or more hosts are analyzed using a compensator of the Co-Ex framework to identify one or more successful and one or more failed services, wherein the compensator stops current execution of the service if the response from the respective host is fail. Finally, the one or more hardware processors are configured to initiate a compensation for the one or more failed services by the compensator, wherein the execution of the one or more failed services is passed to the resolver for invocation of a correction services and aggregate response of the identified one or more successful and one or more failed services from each of the one or more hosts in a single response to share with the user to complete the transaction request using the Co-Ex framework.
[010] In yet another aspect, there are provided one or more non-transitory machine-readable information storage mediums comprising one or more instructions, which when executed by one or more hardware processors causes a method for a co-existence (Co-Ex) framework for application migration is provided. The processor-implemented method includes receiving, via an input/output interface, at least one transaction request initiated by a user, wherein the at least one transaction request is in a predefined format and determining, via one or more hardware processors, one or more legs present in the received transaction request using a resolver of the Co-Ex framework, wherein the resolver provides a host number associated to each of the one or more legs present in the received transaction request.
[011] Further, the processor-implemented method comprises generating, via the one or more hardware processors, a sequence of one or more services using the resolver based on the host number associated to each of one or more legs present in the received transaction request , invoking, via the one or more hardware processors, one or more hosts using a service invoker of the Co-Ex framework based on the each of the one or more legs in the received transaction request , wherein the one or more hosts is a (1) RESTful or (2) a byte stream TCP/IP socket communication and transforming, via the one or more hardware processors, the received transaction request into a format of invoked one or more hosts using a request transformer of the Co-Ex framework, wherein type and specification of the transformation are configured with the one or more host services in service.xml file.
[012] Furthermore, the processor-implemented method comprises sending, via the one or more hardware processors, the transformed transaction request with the respective host of the one or more hosts using the service invoker, wherein the respective host sends a response back to the service invoker to convert into a Co-Ex format using a response transformer, executing iteratively, via the one or more hardware processors, the generated sequence of the one or more services with the respective host of the one or more hosts using the service invoker and analyzing, via the one or more hardware processors, the response from the respective one or more hosts using a compensator of the Co-Ex framework to identify one or more successful and one or more failed services, wherein the compensator stops current execution of the service if the response from the respective host is fail. Finally, the processor-implemented method comprises initiating, via the one or more hardware processors, a compensation for the one or more failed services by the compensator, wherein the execution of the one or more failed services is passed to the resolver for invocation of a correction services and aggregating, via the one or more hardware processors, response of the identified one or more successful and one or more failed services from each of the one or more hosts in a single response to share with the user to complete the transaction request using the Co-Ex framework.
[013] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[014] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[015] FIG. 1 illustrates an exemplary system for a co-existence framework for an application migration, according to some embodiments of the present disclosure.
[016] FIG. 2 is a functional block diagram to illustrate a co-existence framework for an application migration, according to some embodiments of the present disclosure.
[017] FIG. 3 is a block diagram to illustrate a co-existence framework for an application migration, according to some embodiments of the present disclosure.
[018] FIG. 4A and 4B (collectively referred as FIG. 4) is an exemplary flow diagram illustrating a processor-implemented method for a co-existence framework for an application migration, according to some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[019] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
[020] Co-Existence (Co-Ex) can be termed as a pillar in a digital transformation, during the period of movement from an old core to a new core in banking domain by mitigating the bank from the risks of a big bang transformation with no impact to the end customer experience. The Co-Ex minimizes disruptions to day to day operations and allowing for ongoing evaluation and adjustment of processes. The Co-Ex maintains a stable environment for users and gradually integrates new system with legacy system and reducing the risk of data loss or corruption. Further, the Co-Ex allows for physical implementation and tests new systems to reduce the risk of data loss. In another words, the Co-Ex provides availability of parallel systems for a period of time, providing a backup and fallback option to improve agility and responsiveness to changing user needs and preferences.
[021] Embodiments herein provide a method and system for a Co-Existence (Co-Ex) framework for an application migration. The Co-Ex framework is designed with capabilities of route, translate, orchestrate, compensate, and aggregate response of a transaction request initiated by a user. Further, the Co-Ex framework is designed to offer a seamless user experience as part of digital transformation. With the configurable framework in place, the system involves no development at the time of implementation.
[022] The Co-Ex framework acts as an intermediatory layer during digital transformation from legacy core (i.e., MF Cobol) to modern core (Micro Services Architecture based core solution) with capability to route, translate the request/response as per source/destination, orchestrate with one to one mapping, one to many mapping, compensate/auto-retry for data consistency and aggregate to generate single response. The product is designed to mitigate the bank from the risks of big bang transformation with no impact to the end customer experience
[023] The Co-Ex framework mitigates a bank from the risks of big bang transformation. The transformation process is made seamlessly with no impact to the end user experience. The Co-Ex achieves a high degree of agility and reduced turn-around time in product and service fallout. It is capable of routing the transaction request based on parameters like line of business, account number, branch code, channel/source supporting variety of roll-out strategies.
[024] Referring now to the drawings, and more particularly to FIG. 1 through FIG. 4B, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[025] FIG. 1 illustrates a block diagram of a system 100 for a co-existence framework for an application migration, in accordance with an example embodiment. Although the present disclosure is explained considering that the system 100 is implemented on a server, it may be understood that the system 100 may comprise one or more computing devices 102, such as a laptop computer, a desktop computer, a notebook, a workstation, a cloud-based computing environment and the like. It will be understood that the system 100 may be accessed through one or more input/output interfaces 104-1, 104-2... 104-N, collectively referred to as I/O interface 104. Examples of the I/O interface 104 may include, but are not limited to, a user interface, a portable computer, a personal digital assistant, a handheld device, a smartphone, a tablet computer, a workstation, and the like. The I/O interface 104 are communicatively coupled to the system 100 through a network 106.
[026] In an embodiment, the network 106 may be a wireless or a wired network, or a combination thereof. In an example, the network 106 can be implemented as a computer network, as one of the different types of networks, such as virtual private network (VPN), intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), and Wireless Application Protocol (WAP), to communicate with each other. Further, the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices. The network devices within the network 106 may interact with the system 100 through communication links.
[027] The system 100 supports various connectivity options such as BLUETOOTH®, USB, ZigBee, and other cellular services. The network environment enables connection of various components of the system 100 using any communication link including Internet, WAN, MAN, and so on. In an exemplary embodiment, the system 100 is implemented to operate as a stand-alone device. In another embodiment, the system 100 may be implemented to work as a loosely coupled device to a smart computing environment. Further, the system 100 comprises at least one memory 110 with a plurality of instructions, one or more databases 112, and one or more hardware processors 108 which are communicatively coupled with the at least one memory to execute a plurality of modules 114 therein. The plurality of modules 114, for example, includes a configurable routing module 302, a configurable translation module 304, a configurable orchestration module 306, an automated and configurable compensation module 308, an automated retry module 310, and an aggregation module 312. The components and functionalities of the system 100 are described further in detail.
[028] FIG. 2 is a functional block diagram 200 illustrating a co-existence (Co-Ex) framework for an application migration implemented by the system 100 of FIG. 1 through the exemplary block diagram 300 of FIG. 3. A user interface sends a transaction request to the Co-Ex framework to mitigate risk of big bang transformation. A configurable routing module 302 of the Co-Ex framework is designed to route the single leg/multi-leg transaction request to respective cores. The request and response messages are translated using configurable translation module 304 based on the target and source system with one to one mapping, concatenation, split, math functions, default, and list capabilities.
[029] Further, the configurable orchestration module 306 of the Co-Ex framework is designed with a host agnostic feature for the multi-leg transaction request where main transaction request involves transaction execution in multiple cores using a database/REST/SOAP/SOCKET adaptors. The automated and configurable compensation module 308 of the Co-Ex framework is configured to reverse the failed multi-leg financial transaction requests to the respective cores. The automated and configurable compensation module 308 ensures consistency of orchestrated transaction requests. An automated retry module 310 of the Co-Ex framework is designed to re-fire the multi-leg non-financial transaction requests to the respective cores. An asynchronous retry mechanism of non-financial transaction requests such as customer create/amend in case of failure to ensure financial consistency across cores. Finally, the aggregation module 312 of the Co-Ex framework is designed to aggregate response message legs (single/multiple core) on endpoint request configuration basis in one response only to share with the user.
[030] FIG. 4A and 4B (collectively referred as FIG. 4) is a flow diagram illustrating a processor-implemented method 400 for a co-existence (Co-Ex) framework for an application migration implemented by the system 100 of FIG. 1. Functions of the components of the system 100 are now explained with reference to FIG. 2 through steps of flow diagram in FIG. 4, according to some embodiments of the present disclosure.
[031] Initially, at step 402 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to receive, via an input/output interface, at least one transaction request initiated by a user.
[032] At the next step 404 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to determine one or more legs present in the received transaction request using a resolver of the Co-Ex framework. The at least one transaction request include a single leg or a multi-leg transaction request. The resolver provides a host number associated to each of the one or more legs present in the received transaction request. The resolver plays an essential role to decide which host system the transaction request to be forwarded to for each leg of the transaction request. A host resolution is done using a database table, wherein entries for each user, account and transaction requests exists along with the host value. The resolver maps the incoming transaction request to each column and fetches the record corresponding to the attributes specified in the request body. The host value present in this record is the host to which the transaction request to be forwarded.
[033] In an illustration, wherein for each Co-Ex endpoint, an entry is made as:
=
wherein DECIDER_SPECS consists of specs for each leg separated by a semicolon (;) as
;;
here, since there are 3 semicolon (;) separated values, this Co-Ex endpoint is a 3-legged transaction request. SPECS_FOR_LEG_N consists of comma (,) separated key-value pairs where-in the key is the resolver database table column name and value are either, request attribute which holds value for that column or default value for that column when prefixed with hash (#).
[034] At the next step 406 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to generate a sequence of one or more services using the resolver based on the host number associated to each of one or more legs present in the received transaction request.
[035] At the next step 408 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to invoke one or more hosts using a service invoker of the Co-Ex framework based on the each of the one or more legs in the received transaction request. The one or more hosts is a (1) RESTful or (2) a byte stream TCP/IP socket communication.
[036] The at least one transaction request is in a JSON format to the Co-Ex framework endpoint, which is mapped one to one for every transaction request. Depending on the endpoint hit, corresponding service instance to be invoked by the Co-Ex framework. Further, the service instances invoked decides which resolver to be used for a target resolution based on the decider specification and calls it repetitively based on how many flows (legs) are defined in the resolver specification. Based on the decider specification attribute, the resolver calls a configured database or API and fetches the target host (CBS/GBP/other) which needs to be hit.
[037] At the next step 410 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to transform the received transaction request into a format of invoked one or more hosts using a request transformer of the Co-Ex framework. The type and specification of the transformation are configured with the one or more host services in service.xml file. The request transformer transforms the structure of the JSON data by using a JSON file for the specification with capabilities like list manipulation, math functions, concatenation scenarios, split scenario, and default value configuration scenario.
[038] At the next step 412 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to orchestrate the transformed transaction request with the respective host of the one or more hosts using the service invoker. The respective host sends a response back to the service invoker to convert into a Co-Ex format using a response transformer.
[039] At the next step 414 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to execute iteratively the generated sequence of the one or more services with the respective host of the one or more hosts using the service invoker.
[040] At the next step 416 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to analyze the response from the respective one or more hosts using a compensator of the Co-Ex framework to identify one or more successful and one or more failed services, wherein the compensator stops current execution of the service if the response from the respective host is fail.
[041] During execution of the multi-legged Co-Ex transaction request, if a financial host service fails, the compensator implicitly try to fire compensating services for previously executed financial host services before sending any response to user interface. To fulfill this, every financial multi-legged Co-Ex transaction request needs to have following pre-requisites:
1. Compensating services for required financial host services to be configured in BOA_URI_TXN_BPM_PROCESS_MPNG Table;
2. Journal Number in the response of successful financial host services.
[042] At the next step 418 of the method 400, the one or more hardware processors 108 are configured by the programmed instructions to initiate a compensation for the one or more failed services by the compensator, wherein the execution of the one or more failed services is passed to the resolver for invocation of a correction services. The correction services include a retry and a reversal transaction request.
[043] As part of the compensation process, if the retry/reversal transaction request is successful, the response is clubbed and retuned to an aggregator to generate a single response. But in case the retry/reversal transaction request fails, an entry is made in the compensator table indicating the retry/reversal transaction request failure. These entries are further tracked by the system outside the Co-Ex framework, which may further trigger asynchronous retry/reversal transaction requests by involving Co-Ex APIs.
[044] Finally, at the last step 420 of the processor-implemented method 400, the one or more hardware processors 108 are configured by the programmed instructions to aggregating, via the one or more hardware processors, response of the identified one or more successful and one or more failed services from each of the one or more hosts in a single response to share with the user to complete the transaction request using the Co-Ex framework. The compensator logs the transaction request and response in a compensator database for the one or more correction services. Wherein, if the one or more correction services is successful, the response is clubbed and retuned to an aggregator to generate a single response. Wherein if the one or more correction services fails, an entry is made in a compensator table indicating the correction failure.
[045] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[046] The embodiments of present disclosure herein address unresolved problem of complexity of legacy systems, and integration of data from multiple systems for co-existence (Co-Ex) of new technologies and functionalities with the existing systems. Embodiments herein provide a method and system for a Co-Existence (Co-Ex) framework for application migration. The Co-Ex framework is designed with capabilities of route, translate, orchestrate, compensate, and aggregate response of a transaction request initiated by a user. Further, the Co-Ex framework is designed to offer a seamless user experience as part of digital transformation. With the configurable framework in place, the system involves no development at the time of implementation.
[047] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g., any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g., hardware means like e.g., an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means, and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g., using a plurality of CPUs.
[048] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[049] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[050] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[051] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.
, Claims:WE CLAIM:

1. A processor-implemented method (400), comprising:
receiving (402), via an input/output interface, at least one transaction request initiated by a user, wherein the at least one transaction request is in a predefined format;
determining (404), via one or more hardware processors, one or more legs present in the received transaction request using a resolver of a Co-Existence (Co-Ex) framework, wherein the resolver provides a host number associated to each of the one or more legs present in the received transaction request;
generating (406), via the one or more hardware processors, a sequence of one or more services using the resolver based on the host number associated to each of one or more legs present in the received transaction request;
invoking (408), via the one or more hardware processors, one or more hosts using a service invoker of the Co-Ex framework based on the each of the one or more legs in the received transaction request;
transforming (410), via the one or more hardware processors, the predefined format of the received transaction request into a format of invoked one or more hosts using a request transformer of the Co-Ex framework;
orchestrating (412), via the one or more hardware processors, the transformed transaction request with the respective host of the one or more hosts using the service invoker, wherein the respective host sends a response back to the service invoker to convert into a Co-Ex format using a response transformer;
executing (414) iteratively, via the one or more hardware processors, the generated sequence of the one or more services with the respective host of the one or more hosts using the service invoker;
analyzing (416), via the one or more hardware processors, the response from the respective one or more hosts using a compensator of the Co-Ex framework to identify one or more successful and one or more failed services, wherein the compensator stops current execution of the service if the response from the respective host is a failure;
initiating (418), via the one or more hardware processors, a compensation for the one or more failed services by the compensator, wherein the execution of the one or more failed services is passed to the resolver for invocation of one or more correction services; and
aggregating (420), via the one or more hardware processors, the response of the identified one or more successful and one or more failed services from each of the one or more hosts in a single response to share with the user to complete the transaction request using the Co-Ex framework.
2. The processors-implemented method (400) as claimed in claim 1, wherein the one or more hosts is a (1) RESTful or (2) a byte stream Transmission Control Protocol/Internet Protocol (TCP/IP) socket communication.
3. The processors-implemented method (400) as claimed in claim 1, wherein a type and specification of the transformation are configured with the one or more host services in service.xml file.
4. The processors-implemented method (400) as claimed in claim 1, wherein the compensator logs the transaction request and response in a compensator database for the one or more correction services.
5. The processors-implemented method (400) as claimed in claim 4, wherein if the one or more correction services is successful, the response is clubbed and retuned to an aggregator to generate a single response.
6. The processors-implemented method (400) as claimed in claim 4, wherein if the one or more correction services fails, an entry is made in a compensator table indicating the correction failure.
7. A system (100) comprising:
an input/output interface (104), to receive at least one transaction request initiated by a user, wherein the at least one transaction request is in a predefined format;
a memory (110) in communication with the one or more hardware processors (108), wherein the one or more hardware processors are configured to execute programmed instructions stored in the memory (110) to:
determine one or more legs present in the received transaction request using a resolver of a Co-Existence (Co-Ex) framework, wherein the resolver provides a host number associated to each of the one or more legs present in the received transaction request;
generate a sequence of one or more services using the resolver based on the host number associated to each of one or more legs present in the received transaction request;
invoke one or more hosts using a service invoker of the Co-Ex framework based on the each of the one or more legs in the received transaction request;
transform the format of the received transaction request into a format of invoked one or more hosts using a request transformer of the Co-Ex framework;
orchestrate the transformed transaction request with the respective host of the one or more hosts using the service invoker, wherein the respective host sends a response back to the service invoker to convert into a Co-Ex format using a response transformer;
execute iteratively the generated sequence of the one or more services with the respective host of the one or more hosts using the service invoker;
analyze the response from the respective one or more hosts using a compensator of the Co-Ex framework to identify one or more successful and one or more failed services, wherein the compensator stops current execution of the service if the response from the respective host is a failure;
initiate a compensation for each of the one or more failed services by the compensator, wherein the execution of the one or more failed services is passed to the resolver for invocation of one or more correction services; and
aggregate response of the identified one or more successful and one or more failed services from each of the one or more hosts in a single response to share with the user to complete the transaction request using the Co-Ex framework.
8. The system (100) as claimed in claim 7, wherein the one or more hosts is a (1) RESTful or (2) a byte stream Transmission Control Protocol/Internet Protocol (TCP/IP) socket communication.
9. The system (100) as claimed in claim 7, wherein type and specification of the transformation are configured with the one or more host services in a service.xml file.
10. The system (100) as claimed in claim 7, wherein the compensator logs the transaction request and response in a compensator database for the one or more correction services.
11. The system (100) as claimed in claim 10, wherein if the one or more correction services is successful, the response is clubbed and retuned to an aggregator to generate a single response.
12. The system (100) as claimed in claim 10, wherein if the one or more correction services fails, an entry is made in a compensator table indicating the correction failure.

Dated this 24th Day of August 2023
Tata Consultancy Services Limited
By their Agent & Attorney

(Adheesh Nargolkar)
of Khaitan & Co
Reg No IN-PA-1086