Claims:1. A method for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem, the method comprising a processor implemented steps of executing in parallel:
transforming an external simple object access protocol (SOAP) web service to a different SOAP web service or a representational state transfer (RESTful) web service by:
a. mapping a source system to a target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing a web services description language (WSDL) file into a data exchange layer (DXL), to perform a value or a custom-logic web service transformation; and
b. generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more web application archive (WAR) files on an application server;
transforming an external RESTful web service to a different SOAP / REST web service by:
a. mapping the source system to the target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing the WSDL file into the DXL, to perform the value or the custom-logic web service transformation; and
b. generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more WAR files on the application server.
importing, using a RESTful web service, an external database data into the DXL for extracting the external database data into one or more input files by:
a. connecting and establishing, using a database adapter, the DXL with the external database for retrieving one or more procedural language structural query language (PL/SQL) code objects from an external database schema and input and output payload data structure details of the RESTful web service to be generated by the DXL; and
b. performing, using the input and output payload data structure details and the one or more PL/SQL code objects, a mapping of the source system to the target system using one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information and the input and output payload data structures and web service transformation details, information on the DXL generated code and package for deployment of one or more WAR files on an application server; and
performing, using the external database data extracted, a transformation of one or more files of different format for creating an automated interface transformation workbench between the source system and the target system by:
a. importing and exporting, using structural details of the one or more input files and a file adapter of the DXL, data from the one or more input files to one or more output files and vice versa; and
b. performing, using the input and output payload data structure details from the one or more of input and output files, a mapping of the source system to the target system using the one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information, the input and output payload data structures and web service transformation details, details on the DXL generated code and package for deployment of the one or more WAR files on an application server.

2. The method of claim 1, wherein the step of transforming the external SOAP web service to a different SOAP web service or RESTful web service comprises generating, using a DXL proxy RESTful web service, details on a hypertext transfer protocol uniform resource locator (HTTP URL) of a generated proxy RESTful web service and a javascript object notation/extensible markup language (JSON/XML) data structure for deployment of the one or more web application archive (WAR) files on the application server for testing and deployment of one or more web applications.

3. The method of claim 1, wherein the step of performing the transformation of one or more files of different format comprises creating, using the code generated by the DXL, an automated interface transformation between the source system and the target system for replicating or writing data to the one or more output files of the source systems.

4. A system for automated interface transformation between heterogeneous systems in an enterprise ecosystem, the system comprising:
a memory storing instructions;
one or more communication interfaces; and
one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to:
transform an external simple object access protocol (SOAP) web service to a different SOAP web service or a representational state transfer (RESTful) web service by:
a. mapping a source system to a target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing a web services description language (WSDL) file into a data exchange layer (DXL), to perform a value or a custom-logic web service transformation; and
b. generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more web application archive (WAR) files on an application server;
transform in parallel an external RESTful web service to a different SOAP / REST web service by:
a. mapping the source system to the target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing the WSDL file into the DXL, to perform the value or the custom-logic web service transformation; and
b. generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more WAR files on an application server.
import in parallel using a RESTful web service, an external database data into the DXL for extracting the external database data into one or more input files by:
a. connecting and establishing, using a database adapter, the DXL with the external database for retrieving one or more procedural language structural query language (PL/SQL) code objects from an external database schema and input and output payload data structure details of the RESTful web service to be generated by the DXL; and
b. performing, using the input and output payload data structure details and the one or more PL/SQL code objects, a mapping of the source system to the target system using one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information and the input and output payload data structures and web service transformation details, information on the DXL generated code and package for deployment of one or more WAR files on the application server; and
perform in parallel using the external database data extracted, a transformation of one or more files of different format for creating an automated interface transformation workbench between the source system and the target system by:
a. importing and exporting using structural details of the one or more input files and a file adapter of the DXL, data from the one or more input files to one or more output files and vice versa; and
b. performing, using the input and output payload data structure details from the one or more of input and output files, a mapping of the source system to the target system using the one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information, the input and output payload data structures and web service transformation details, details on the DXL generated code and package for deployment of the one or more WAR files on an application server.

5. The system of claim 1, wherein the one or more hardware processors are further configured to transform the external SOAP web service to a different SOAP web service or RESTful web service by generating, using a DXL proxy RESTful web service, details on a hypertext transfer protocol uniform resource locator (HTTP URL) of a generated proxy RESTful web service and a javascript object notation/extensible markup language (JSON/XML) data structure for deployment of the one or more WAR files on the application server for testing and deployment of one or more web applications.

6. The system of claim 1, wherein the one or more hardware processors are further configured to perform the transformation of one or more files of different format by creating, using the code generated by the DXL, an automated interface transformation between the source system and the target system for replicating or writing data to the one or more output files of the source systems.
, 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:
SYSTEMS AND METHODS FOR CREATING AUTOMATED INTERFACE TRANSMISSION BETWEEN HETEROGENEOUS SYSTEMS IN AN ENTERPRISE ECOSYSTEM

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

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The present application generally relates to an enterprise integration platform to facilitate interactions between heterogeneous systems. More particularly, the present application relates to systems and methods for creating automated interface transmission between heterogeneous systems in an enterprise ecosystem.

BACKGROUND
[002] An Enterprise Application Integration (EAI) is a process of integrating data or a function of two application programs. It facilitates sharing of data and processes among two different applications in an enterprise. It aims at modernizing, consolidating and coordinating the computer applications in an enterprise. The EAI may also involve developing a new total view of an enterprise's business and its applications, seeing how existing applications fit into the new model, and then devising ways to efficiently reuse the existing while adding new applications and data. The EAI may be a complicated process, especially when integrating existing legacy applications with new applications or Web services. Some of the prominent requirements for a successful implementation of the EAI inter-alia include adequate connectivity between platforms, flexibility of processes, hardware and software, data transformation logic and a common interface for free communication. Some of the EAI integration challenges include cumbersome and high-maintenance point-to-point integrations that are time consuming as well as difficult to maintain during product version upgrade, real time bi-directional communications and collaborations between different products or systems requires significant manual coding efforts, difficulty in building a standardized, flexible integration and communication layer for all products or systems and unavailability of out-of-box adapters to facilitate integration of very commonly used interfaces. Still further because of wide scope of the EAI, integration efforts typically have far-reaching implications on the business. Once the processing of the most critical business functions is incorporated into an integration solution, the proper functioning of that solution becomes vital to the business. A failing or misbehaving integration solution can cost an organization millions of dollars in lost orders, misrouted payments and disgruntled customers.
[003] The traditional systems and methods have provided for data exchange, configurable interfaces, reduction in coding efforts and message translations but none of them have provided for an integration layer between one or more source (core product implementations) and destination (third party external systems or Online Transaction Channel like portal, mobility etc.) systems for seamless bi-directional communications and collaborations and an integrated platform supporting all Enterprise Architecture Integration (EAI) patterns. Hence there is a need for technology which facilitates transforming between two different file formats, provides for an integrated platform supporting all the EAI patterns, which maintains a single integrated repository for multiple interface processes augmenting traceability and quicker enhancement capabilities, simplifies integrations between one or more systems so as to specify precisely what data and information to receive and provides for a plurality of out-of-box adapters to facilitate integration of very commonly used interfaces such as document generation, email, Short Messaging Service (SMS) gateways etc.
SUMMARY
[004] The following presents a simplified summary of some embodiments of the disclosure in order to provide a basic understanding of the embodiments. This summary is not an extensive overview of the embodiments. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the embodiments. Its sole purpose is to present some embodiments in a simplified form as a prelude to the more detailed description that is presented below.
[005] In an embodiment of the present disclosure, there is provided a method for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem, the method comprising a processor implemented steps of executing in parallel: transforming an external simple object access protocol (SOAP) web service to a different SOAP web service or a representational state transfer (RESTful) web service by: (a) mapping a source system to a target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing a web services description language (WSDL) file into a data exchange layer (DXL), to perform a value or a custom-logic web service transformation; and (b) generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more web application archive (WAR) files on an application server; transforming an external RESTful web service to a different SOAP / REST web service by: (a) mapping the source system to the target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing the WSDL file into the DXL, to perform the value or the custom-logic web service transformation; and (b) generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more WAR files on an application server; importing, using a RESTful web service, data of an external database into the DXL for extracting the imported data of the external database into one or more input files by: (a) connecting and establishing, using a database adapter, the DXL with the external database for retrieving one or more procedural language structural query language (PL/SQL) code objects from a schema of the external database and input and output payload data structure details of the RESTful web service to be generated by the DXL; and (b) performing, using the input and output payload data structure details and the one or more pl sql code objects, a mapping of the source system to the target system using one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information and the input and output payload data structures and web service transformation details, information on the DXL generated code and package for deployment of one or more WAR files on an application server; and performing, using the data extracted of the external database, a transformation of one or more files of different format for creating an automated interface transformation workbench between the source system and the target system by: (a) importing and exporting, using structural details of the one or more input files and a file adapter of the DXL, data from the one or more input files to one or more output files and vice versa; and (b) performing, using the input and output payload data structure details from the one or more of input and output files, a mapping of the source system to the target system using the one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information, the input and output payload data structures and web service transformation details, details on the DXL generated code and package for deployment of the one or more WAR files on an application server; generating, using a DXL proxy RESTful web service, details on a hypertext transfer protocol uniform resource locator (HTTP URL) of a generated proxy RESTful web service and a javascript object notation/extensible markup language (JSON/XML) data structure for deployment of the one or more web application archive (WAR) files on the application server for testing and deployment of one or more web applications for transforming the external SOAP web service to a different SOAP web service or RESTful web service; and creating, using the code generated by the DXL, an automated interface transformation between the source system and the target system for replicating or writing data to the one or more output files of the source systems for performing the transformation of one or more files of different format.
[006] In an embodiment of the present disclosure, there is provided a system for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem, the system comprising a memory storing instructions; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to: transform an external simple object access protocol (SOAP) web service to a different SOAP web service or a representational state transfer (RESTful) web service by: (a) mapping a source system to a target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing a web services description language (WSDL) file into a data exchange layer (DXL), to perform a value or a custom-logic web service transformation; and (b) generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more web application archive (WAR) files on an application server; transform in parallel an external RESTful web service to a different SOAP / REST web service by: (a) mapping the source system to the target system using the SOAP web service input and output payload data structures, wherein the SOAP web service input and output payload data structures are obtained by parsing the WSDL file into the DXL, to perform the value or the custom-logic web service transformation; and (b) generating, based on the source system being mapped to the target system, the SOAP web service input and output payload data structures and web service transformation details, the DXL generated code and package for deployment of one or more WAR files on an application server; import in parallel using a RESTful web service, an external database data into the DXL for extracting the data of the external database into one or more input files by: (a) connecting and establishing, using a database adapter, the DXL with the external database for retrieving one or more procedural language structural query language (PL/SQL) code objects from a schema of the external database and input and output payload data structure details of the RESTful web service to be generated by the DXL; and (b) performing, using the input and output payload data structure details and the one or more PL/SQL code objects, a mapping of the source system to the target system using one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information and the input and output payload data structures and web service transformation details, information on the DXL generated code and package for deployment of one or more WAR files on an application server; and perform in parallel using the data extracted of the external database, a transformation of one or more files of different format for creating an automated interface transformation workbench between the source system and the target system by: (a) importing and exporting using structural details of the one or more input files and a file adapter of the DXL, data from the one or more input files to one or more output files and vice versa; and (b) performing, using the input and output payload data structure details from the one or more of input and output files, a mapping of the source system to the target system using the one or more of DXL layers to perform the value or the custom-logic web service transformation and generating, using the mapping information, the input and output payload data structures and web service transformation details, details on the DXL generated code and package for deployment of the one or more WAR files on an application server; transform the external SOAP web service to a different SOAP web service or RESTful web service by generating, using a DXL proxy RESTful web service, details on a hypertext transfer protocol uniform resource locator (HTTP URL) of a generated proxy RESTful web service and a javascript object notation/extensible markup language (JSON/XML) data structure for deployment of the one or more web application archive (WAR) files on the application server for testing and deployment of one or more web applications; and to perform the transformation of one or more files of different format by creating, using the code generated by the DXL, an automated interface transformation between the source system and the target system for replicating or writing data to the one or more output files of the source systems.
[007] 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
[008] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[009] Fig. 1 illustrates a block diagram of a system for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem according to an embodiment of the present disclosure;
[0010] Fig. 2 is an architecture illustrating the components of a system for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem according to an embodiment of the present disclosure; and
[0011] Fig. 3 is a flowchart illustrating the steps involved for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem according to an embodiment of the present disclosure.

DETAILED DESCRIPTION OF THE EMBODIMENTS
[0012] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0013] The embodiments of the present disclosure provides systems and methods for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem. A Data Exchange Layer (DXL) application is an enterprise integration platform for a message transformation to facilitate interactions between one or more heterogeneous systems. The DXL is an integrated platform supporting all Enterprise Architecture Integration (EAI) patterns and facilitates an interface configuration approach. The DXL application further maintains a single repository of interface processes augmenting traceability and quicker enhancement capabilities. The traditional systems and methods have provided for a data exchange, configurable interfaces, reduction in coding efforts and the transformations but none of them have provided for an integration layer between one or more source (core product implementations) and destination (third party external systems or Online Transaction Channel like portal, mobility etc.) systems for seamless bi-directional communications and collaborations and an integrated platform supporting all the EAI patterns. Hence there is a need for technology which facilitates transforming between two different file formats, simplifies integrations between one or more systems so as to specify precisely what data and information to receive and provides for a plurality of out-of-box adapters to facilitate integration of very commonly used interfaces such as document generation, email, Short Messaging Service (SMS) gateways etc.
[0014] FIG. 1 illustrates an exemplary block diagram of a system (100) for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem according to an embodiment of the present disclosure. In an embodiment, the system (100) includes one or more processors (104), communication interface device(s) or input/output (I/O) interface(s) (106), and one or more data storage devices or memory (102) operatively coupled to the one or more processors (104). The one or more processors (104) that are hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is configured to fetch and execute computer-readable instructions stored in the memory. In an embodiment, the system (100) can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[0015] The I/O interface device(s) (106) can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.
[0016] The memory (102) may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, one or more modules (not shown) of the system (100) can be stored in the memory (102).
[0017] According to an embodiment of the present disclosure, referring to FIG. 2, the architecture of the DXL (210) used for performing implementation of automated interface transformation between heterogeneous systems in an enterprise ecosystem may now be understood in detail. Referring to FIG. 2 again, the architecture of the DXL (210) comprise of a presentation layer (202), a business layer (204), a data access layer (206) and an oracle or external database (208) according to an embodiment of the present disclosure. The presentation layer (202) comprises a HyperText Markup Language (HTML), one or more Cascading Style Sheets (CSS) and one or more Javascript files supporting AngularJS 1.x javascript framework. The presentation layer (202) is responsible for integrating all formats of data into a standard format for effective communication between a plurality of components and other layers of the DXL (210). The presentation layer (202) follows data programming structure schemes developed for different languages and provides the real-time syntax, required for communication between two objects such as layers, systems or networks. The business layer (204) comprises one or more java components for one or more Spring 4.x business objects. The data access layer (206) comprises one or more java components for one or more Spring 4.x data access objects (other than the business layer (204) java components above), a Hibernate 4.x, a plurality of Java Persistence Application Programming Interface (JPA) beans and an entity manager. The data access layer (206) further comprises one or more methods for accessing data of the oracle or external database (208). The data access layer (206) also comprises a plurality of data access objects. All interactions between the presentation layer (202) and the business layer (204) are performed over one or more Java RESTful web services (JAXRS) Jersey implementation (not shown in the figure). All interactions between the business layer (204) and the data access layer (206) are performed using one or more Spring Data Access Objects (DAO). All interactions between the data access layer (206) and the oracle or external database (208) are performed using a Hibernate Java Persistence Application Programming Interface (JPA) Entity Manager, a Java Persistence Query Language (JPQL) and one or more JPA entity relationships.
[0018] FIG. 3 with reference to FIGS. 1 and 2, illustrates an exemplary flow diagram of a method for creating automated interface transformation between heterogeneous systems in an enterprise ecosystem. In an embodiment the system (100) comprises one or more data storage devices of the memory (102) operatively coupled to the one or more hardware processors (104) and is configured to store instructions for execution of steps of the method by the one or more processors (104). The steps of the method of the present disclosure will now be explained with reference to the components of the system (100) as depicted in FIG. 1 and the flow diagram. In the embodiments of the present disclosure, the hardware processors (104) when configured the instructions performs one or more methodologies described herein. In an embodiment of the present disclosure the one or more hardware processors (104) perform parallel execution of the steps of transforming an external simple object access protocol (SOAP) web service to a different SOAP web service or a representational state transfer (RESTful) web service, transforming an external RESTful web service to a different SOAP / RESTful web service, importing using a RESTful web service, the data of an external database (208) into the DXL (210) for extracting the external database data into one or more input files, an extraction of the imported data of the oracle or external database (208) into the one or more files (for example, a .txt, a .csv or a .xml file) accessible using the RESTful web service finally performing, using the data of the external database (208) extracted, a transformation of one or more files of different format for creating an automated interface transformation workbench between the source system and the target system.
[0019] According to an embodiment of the present disclosure, at step [302 (i)], the one or more hardware processors (104) perform a transformation of an external simple object access protocol (SOAP) web service to a different SOAP web service or a representational state transfer (RESTful) web service by uploading and parsing of one or more web services description language (WSDL) files (for example, a BancsEmployeeSearchSoapService.wsdl file) into the DXL (210) for generating an initial set of information on a hypertext transfer protocol uniform resource locator (HTTP URL) of the SOAP web service WSDL files uploaded, the SOAP web service implementation java class name, details of the SOAP web service operations specified in the one or more WSDL files and an input and output payload data structures for the SOAP web service operations. This is preceded by generating a service contract in the Web Services Description Language (WSDL) file by a source system which generates the SOAP web service. The format and details of the BancsEmployeeSearchSoapService file in the .wsdl format may be as below:

Example of the output payload data structure (as output.xsd)

)
[0021] The DXL (210) may then display a mapping screen to the user comprising one or more input and output tabbed sections further comprising of a left and a right panel, where the left panel include details of the source system payload data structure nested object graph and the right panel include details of the target system payload data structure nested object graph (as mentioned in the above examples of the input.xsd and output.xsd). For performing the field mapping between the source system and the target system, the user specifies the field-level mappings between the source system and the target system payload data structure nested object graphs by the one or more hardware processors (104). The value translation may be a simple or a custom-logic based value translation. The Simple value translation refers to value of a field being transferred as-is to the target system without any change. The Custom-logic-based translation refers to changing the value to a different one based on a configured business logic. As an example, the source System interprets CAR_MODEL_DESCRIPTION=’XYZ’ as CODE=’MR’ where as the target system interprets CAR_MODEL_DESCRIPTION=’XYZ’ as CODE=’XY’. In this case, the DXL (210) will execute the custom-logic based value translation to convert CODE=’XY’ as per the source System to a CODE=’XY’ as expected by the target System. This conversion id may be performed automatically during execution time. Based on the field mapping and the value translation details, the DXL (210), by the one or more hardware processors (104), generates a code for the transformed SOAP web service into a standard Java Platform, Enterprise Edition (J2EE) complaint one or more web archive (WAR) files that are deployment ready on an application server platform. For any proxy SOAP web service being generated by the DXL (210), an application of the target system may further deploy, using the one or more hardware processors (104), a generated WAR deployment unit (the WAR deployment unit may be generated by the DXL (210) as a product of code generation for a set of one or more transformation processes) to an application server of preference (the user preference as to in which of the application server the DXL (210) is to be deployed) and retrieve the WSDL contract generated above by the source system.
[0022] For any proxy RESTful web service being generated by the DXL (210), the target application may further deploy, using the one or more hardware processors (104), the generated WAR deployment unit to a servlet container forming a part of the application server of choice (the user preference as to in which of the application server the DXL (210) is to be deployed). The servlet container refers to a corresponding servlet container of the application server where the DXL (210) is to be deployed. For example, the servlet container may be a JBoss, Websphere, Oracle etc. The DXL (210) may then communicate the information on the HTTP URL of the proxy RESTful web service and one or more blank JSON / XML data structures of the input output payload to the proxy RESTful web service. Since the DXL (210) generates a POST (a HTTP POST method) format proxy execution points as transformed web services, hence for transformation into the different RESTful web service, the HTTP URL generated above is in the POST format.
[0023] Finally, the proxy SOAP or RESTful web service generated by the DXL (210) is consumed by the target system that remains totally unaware of the actual SOAP web service generated initially by the source system. A code generated by the DXL (210) handles one or more proxying calls from the target system and automatically calls / invokes the SOAP web service from the source system for performing the transformation of the external simple object access protocol (SOAP) web service to the different SOAP web service or the representational state transfer (RESTful) web service.
[0024] According to an embodiment of the present disclosure, at step [302 (ii)], the one or more hardware processors (104) perform a transformation of an external RESTful web service to a different SOAP or a REST web service by generating for the RESTful web service, using the one or more hardware processors (104), the HTTP end-point URL of the RESTful web service in a pre-defined template format with potential placeholders for the one or more paths and query parameters along with the input and output payload data structures as an arbitrary JSON data. This is preceded by generating of the service contract by the source system which generates the RESTful web services. Example of the pre-defined template format may be http://SERVER:PORT/SampleWebApp/restPrefis/SampleRestService/sampleMethod/{pathParam1}/{pathParam2}/?qParam1=&qParam2=&qParam3=).
[0025] The one or more hardware processors (104) may further capture the user’s preference of transforming the RESTful web service to the different SOAP web service or the RESTful web service by capturing the structural and subscription preferences from the target system and communicating the structural and subscription preferences from the target system to the DXL (210). The one or more hardware processors (104) may then enable the user to upload the input and output payload data structures of the transformed web service in either the one or more eXtensible Markup Language (XML) Schema Definition (XSD file), or as the raw XML data or as the raw JavaScript Object Notation (JSON) data for obtaining the source system details and communicating the details to the DXL (210). Based on the target and source system details and the input and output payload data structures details generated, the DXL (210) perform using the data translation and transformation layer (not shown in the figure), the mapping and populating of data (the data which the source system needs to exchange with the target system in any specific format, for example, the data from any database from the source system) across the one or more Java Nested Object Graphs.
[0026] The DXL (210) may then display the mapping screen to the user comprising the one or more input and output tabbed sections further comprising of the left and the right panel, where the left panel include details on the source system payload data structure nested object graph and the right panel include details on the target system payload data structure nested object graph. For performing the field mapping and the value translation between the source system and the target system, the user specifies the field-level mappings between the source system and the target system payload data structure nested object graphs by the one or more hardware processors (104). The value translation may be the simple or the custom-logic based value translation as explained above. Based on the field mapping and the value translation details, the DXL (210), by the one or more hardware processors (104), generates the code for the transformed RESTful web service into the standard Java Platform, the Enterprise Edition (J2EE) complaint one or more web archive (WAR) files that are deployment ready on an application server platform.
[0027] For any proxy SOAP web service being generated by the DXL (210), an application of the target system may further deploy, using the one or more hardware processors (104), the generated WAR deployment unit to the application server of preference (the user preference as to in which of the application server the DXL (210) is to be deployed) and retrieve the WSDL contract generated above by the source system. For any proxy RESTful web service being generated by the DXL (210), the target application may further deploy, using the one or more hardware processors (104), the generated WAR deployment unit to the corresponding servlet container, for example, the Jboss or Oracle, forming a part of the application server of preference (the user preference as to in which of the application server the DXL (210) is to be deployed). The DXL (210) may then communicate the information on the HTTP URL of the proxy RESTful web service and the one or more blank JSON / XML data structures of the input output payload to the proxy RESTful web service. Since the DXL (210) generates the POST format proxy execution points as transformed web services, hence for transformation into the different RESTful web service, the HTTP URL generated above is in the POST format.
[0028] Finally, the proxy SOAP or RESTful web service generated by the DXL (210) is consumed by the target system that remains totally unaware of the actual SOAP web service generated initially by the source system. The code generated by the DXL (210) handles one or more proxying calls from the target system and automatically calls / invokes the SOAP web service from the source system for performing the transformation of the external simple object access protocol (SOAP) web service to the different SOAP web service or the representational state transfer (RESTful) web service.
[0029] According to an embodiment of the present disclosure, at step [302 (iii)], the one or more hardware processors (104) perform importing, using a RESTful web service, the data of the oracle or external database (208) into the DXL (210) for extracting the data of the oracle or external database (208) into one or more input files (for example, a .JSON file) by connecting and establishing, using a database adapter, the DXL (210) with the oracle or external database (208) for retrieving one or more procedural language structural query language (PL/SQL) code objects from a schema of the oracle or an external database (208) and the input and output payload data structure details of the RESTful web service to be generated by the DXL (210). The DXL (210) connection with the oracle or external database (208) may be further used to carry out a host of operations like a batch file processing. For establishing the connection of the DXL (210) with the oracle or external database (208), configuration details like the database host name, port number, unique or service name, user name, password and a Java Database Connectivity (JDBC) driver class name etc need to be captured and generated while establishing the connection. Once the database adapter is configured with the DXL (210), the DXL (210) provides a test connection functionality to ascertain whether the DXL (210) is able to connect to the oracle or external database (208) using the connection information in the database adapter.
[0030] After the connection with the external database (that is the oracle or external database (208) that the DXL (210) will connect to for exposing a database source code) is successfully tested and ascertained, the DXL (210) further retrieves a plurality of schemas from the oracle or external database (208) and generate the one or more PL/ SQL code objects in a procedure, package and function under the plurality of schemas. The user may then select the one or more PL/SQL code objects for performing operations like batch file processing. Based upon the one or more PL/SQL code objects selected by the user, the DXL (210) may identify, read and generate one or more object signatures and arguments. In case of any collection arguments in the object signatures and arguments, the user needs to specify an internal data representation of the collected arguments. The input output payload data structure details of the proxy RESTful web service will be based upon the one or more PL/SQL code objects signatures and will be generated by the DXL (210).
[0031] The DXL (210) may further perform an identification of one or more input files (the one or more input files containing data in any specific format to be transferred from the source system to the target system) to be generated along with structural details of the one or more input files. The DXL (210) may, using a file adapter, configure a relevant metadata information relating to the one or more input files identified to capture in the file adapter a host of information relating to the one or more input file names, file extensions, an operating system network filer location and the internal data structure. Based on the above details captured in the file adapter, the DXL (210) may further identify the input and output payload data structures details and the one or more PL/SQL objects code of the one or more input files.
[0032] The DXL (210) may then perform using the data translation and transformation layer (not shown in the figure), the mapping and populating of the data (the data in any specific format which the source system will transfer to the target system) across the one or more Java Nested Object Graphs. The DXL (210) may then display the mapping screen to the user comprising the one or more input and output tabbed sections further comprising of the left and the right panel, where the left panel include details on the source system payload data structure nested object graph and the right panel include details on the target system payload data structure nested object graph. For performing the field mapping and the value translation between the source system and the target system, the user specifies the field-level mappings between the source system and the target system payload data structure nested object graphs by the one or more hardware processors (104). The value translation may be the simple or the custom-logic based value translation as explained above. Based on the field mapping and the value translation details, the DXL (210), by the one or more hardware processors (104), generate code for the transformed RESTful web service into the standard Java Platform, Enterprise Edition (J2EE) complaint one or more web archive (WAR) files that are deployment ready on the application server platform. For any proxy RESTful web service being generated by the DXL (210), the target application may further deploy, using the one or more hardware processors (104), the generated WAR deployment unit to the corresponding servlet container forming a part of the application server of the user’s preference. The DXL (210) may then communicate the information on the HTTP URL of the proxy RESTful web service and the one or more blank JSON / XML data structures of the input output payload to the proxy RESTful web service. Since the DXL (210) generates the POST format proxy execution points as transformed web services, hence for the transformation into the different RESTful web service, the HTTP URL generated above is in the POST format.
[0033] Finally, the proxy SOAP or RESTful web service generated by the DXL (210) is consumed by the target system that remains totally unaware of the actual SOAP web service generated initially by the source system. The code generated by the DXL (210) handles one or more proxying calls from the target system and automatically calls / invokes the SOAP web service from the source system for performing the transformation of the external simple object access protocol (SOAP) web service to the different SOAP web service or a representational state transfer (RESTful) web service.
[0034] According to an embodiment of the present disclosure, at step [302 (iv)], the one or more hardware processors (104) perform an extraction of the imported data of the oracle or external database (208) into the one or more files (for example, a .txt, a .csv or a .xml file) accessible using the RESTful web service by connecting and establishing, using a database adapter, the DXL (210) with the oracle or external database (208) for retrieving one or more procedural language structural query language (PL/SQL) code objects from a schema of the oracle or an external database (208) and the input and output payload data structure details of the RESTful web service to be generated by the DXL (210). The DXL (210) connection with the oracle or external database (208) may be further used to carry out a host of operations like a batch file processing. For establishing the connection of the DXL (210) with the oracle or external database 208, configuration details like the database host name, port number, unique or service name, user name, password and a Java Database Connectivity (JDBC) driver class name etc need to be captured and generated while establishing the connection. Once the database adapter is configured with the DXL (210), the DXL (210) provides a test connection functionality to ascertain whether the DXL (210) is able to connect to the oracle or external database (208) using the connection information in the database adapter.
[0035] After the connection with the external database (that is the oracle or external database (208) that the DXL (210) will connect to for exposing a database source code) is successfully tested and ascertained, the DXL (210) further retrieves a plurality of schemas from the oracle or external database (208) and generate the one or more PL/ SQL code objects in a procedure, package and function under the plurality of schemas. The user may then select the one or more PL/SQL code objects for performing operations like batch file processing. Based upon the one or more PL/SQL code objects selected by the user, the DXL (210) may identify, read and generate one or more object signatures and arguments. In case of any collection arguments in the object signatures and arguments, the user needs to specify an internal data representation of the collected arguments. The input output payload data structure details of the proxy RESTful web service will be based upon the one or more PL/SQL code objects signatures and will be generated by the DXL (210).
[0036] The DXL (210) may further perform an identification of one or more input files (the one or more input files containing data in any specific format to be transferred from the source system to the target system) to be generated along with structural details of the one or more input files. The DXL (210) may, using a file adapter, configure a relevant metadata information relating to the one or more input files identified to capture in the file adapter a host of information relating to the one or more input file names, file extensions, an operating system network filer location and the internal data structure. Based on the above details captured in the file adapter, the DXL (210) may further identify the input and output payload data structures details and the one or more PL/SQL objects code of the one or more input files.
[0037] The DXL (210) may then perform using the data translation and transformation layer (not shown in the figure), the mapping and populating of the data (the data in any specific format which the source system will transfer to the target system) across the one or more Java Nested Object Graphs. The DXL (210) may then display the mapping screen to the user comprising the one or more input and output tabbed sections further comprising of the left and the right panel, where the left panel include details on the source system payload data structure nested object graph and the right panel include details on the target system payload data structure nested object graph. For performing the field mapping and the value translation between the source system and the target system, the user specifies the field-level mappings between the source system and the target system payload data structure nested object graphs by the one or more hardware processors (104). The value translation may be the simple or the custom-logic based value translation as explained above. Based on the field mapping and the value translation details, the DXL (210), by the one or more hardware processors (104), generate code for the transformed RESTful web service into the standard Java Platform, Enterprise Edition (J2EE) complaint one or more web archive (WAR) files that are deployment ready on the application server platform. For any proxy RESTful web service being generated by the DXL (210), the target application may further deploy, using the one or more hardware processors (104), the generated WAR deployment unit to the corresponding servlet container forming a part of the application server of the user’s preference. The DXL (210) may then communicate the information on the HTTP URL of the proxy RESTful web service and the one or more blank JSON / XML data structures of the input output payload to the proxy RESTful web service. Since the DXL (210) generates the POST format proxy execution points as transformed web services, hence for the transformation into the different RESTful web service, the HTTP URL generated above is in the POST format.
[0038] Finally, the proxy SOAP or RESTful web service generated by the DXL (210) is consumed by the target system that remains totally unaware of the actual SOAP web service generated initially by the source system. The code generated by the DXL (210) handles one or more proxying calls from the target system and automatically calls / invokes the SOAP web service from the source system for performing the transformation of the external simple object access protocol (SOAP) web service to the different SOAP web service or a representational state transfer (RESTful) web service.
[0039] According to an embodiment of the present disclosure, at step [302 (v)], the one or more hardware processors (104) perform using the imported and extracted data from the oracle or external database (208), a transformation of one or more files (for example, the .txt, the .csv or the .xml file) of different format for creating automated interface transformation between the heterogeneous systems by identifying the one or more input file details such as name, extension, file format and file data and one or more output file details such as name, extension, file format and file data. The identification of the one or more input and output file is performed to obtain a set of information (such as name, extension, file format and file data) relating a plurality files of different formats between which the file transformation is to be performed. The DXL (210) may for performing the one or more input files data import further identify the structural details of the one or more input files. The structural details of the one or more input files are identified by uploading metadata information the one or more input files to be imported into the DXL (210) and saving as the file adapter.
[0040] The DXL (210) may, using the file adapter, configure the relevant metadata information relating to the one or more input files identified to capture in the file adapter a host information relating to the one or more input file names, file extensions, an operating system network filer location and the internal data structure. The DXL (210) may then for performing the data export (of the data imported from the one or more of the imported files) to the one or more output files identified (how it identifies) further identify the structural details of the one or more output files. The DXL (210) may, using the file adapter, configure the relevant metadata information relating to the one or more input files identified to capture in the file adapter a host information relating to the one or more input file names, file extensions, an operating system network filer location and the internal data structure. Based on the one or more input and output files and the structural details identified, the DXL (210) may then perform using the data translation and transformation layer (not shown in the figure), the mapping and populating of the data (the data in any specific format that the source system needs to transfer to the target system) across the one or more Java Nested Object Graphs.
[0041] The DXL (210) may then display the mapping screen to the user comprising the one or more input and output tabbed sections further comprising of the left and a right panel, where the left panel include detail on the source system payload data structure nested object graph and the right panel include detail on the target system payload data structure nested object graph. For performing the field mapping and the value transfer between the source system and the target system, the user specifies the field-level mappings between the source system and the target system payload data structure nested object graphs by the one or more hardware processors (104). The value translation may be the simple or the custom-logic based value translation as explained above. Based on the field mapping and the value translation details, the DXL (210), by the one or more hardware processors (104), generate code for the transformed RESTful web service into a standard Java Platform, Enterprise Edition (J2EE) complaint one or more web archive (WAR) files that are deployment ready on an application server platform. For any proxy RESTful web service being generated by the DXL (210), the target application may further deploy, using the one or more hardware processors (104), the generated WAR deployment unit to the corresponding application servlet container, for example, the websphere, or the JBoss, forming a part of the application server of the user’s preference. The DXL (210) may then communicate the information on the HTTP URL of the proxy RESTful web service and the one or more blank JSON / XML data structures of the input output payload to the proxy RESTful web service. Since the DXL (210) generates a POST format proxy execution points as transformed web services, hence for transformation into the different RESTful web service, the HTTP URL generated above is in the POST format.
[0042] Finally, the proxy SOAP or RESTful web service generated by the DXL (210) is consumed by the target system that remains totally unaware of the actual SOAP web service generated initially by the source system. The code generated by the DXL (210) handles one or more proxying calls from the target system and automatically calls / invokes the SOAP web service from the source system for performing the transformation of the external simple object access protocol (SOAP) web service to the different SOAP web service or the representational state transfer (RESTful) web service.
[0043] According to an embodiment of the present disclosure referring to table 1 below, a comparison of the present disclosure with related traditional systems and methods may be considered.
TABLE 1
Technical Features WSO2 Enterprise Service Bus (ESB) and Service-oriented Architecture (SOA) Mule ESB FuseSource ESB Android Logic Ultra ESB JBoss ESB and SOA platform Data Exchange Layer Application (proposed disclosure)
EAI Support Yes Yes Yes Yes Yes Yes
All ESB features support Yes Yes Yes Yes Yes Yes
A complete SOA platform Yes No No No Yes Yes
SOA Governance Yes No No No No Yes
Web Service generation to expose Database PL/SQL routine No No No No No Generates both SOAP and REST style Web Service from database PL/SQL routine
Type of code generation Generates proprietary code Generates proprietary code Generates proprietary code Generates proprietary code Generates proprietary code Generates Java Bytecode
Security and Identity Management Yes Limited Limited Limited Limited Yes
Performance High Moderate Moderate High Moderate High
Platform independence No No No No No Yes

[0044] While all the traditional systems and methods offer the EAI capability and all the ESB technical features support, however all of them except WSO2 and JBoss do not offer a complete SOA platform. The proposed disclosure provides for a complete SOA platform. The proposed disclosure also complies with SOA governance which is not offered by any of the traditional systems and methods except WSO2. None of the traditional systems and methods provide for the web service generation to expose the database PL/SQL routine while the proposed disclosure is compatible to both the SOAP and the REST style web service from the database PL/SQL routine. All the traditional systems and methods generate one or more proprietary codes while the proposed disclosure is capable of generating a plurality of Java Bytecodes. Further, none of the traditional systems and methods has the platform independence while the proposed disclosure provides for the platform independence while performing a variety of web transformation services. Hence the proposed disclosure provides for a plurality of technical improvements over the traditional systems and methods while retaining high performance.
[0045] 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.
[0046] 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 modules 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.
[0047] 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 modules described herein may be implemented in other modules or combinations of other modules. 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.
[0048] 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 and spirit 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.
[0049] 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, BLU-RAYs, flash drives, disks, and any other known physical storage media.
[0050] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.