US20100205475A1

US20100205475A1 - Meta-data driven, service-oriented architecture (soa)-enabled, application independent interface gateway

Info

Publication number: US20100205475A1
Application number: US12/636,441
Authority: US
Inventors: Fariborz Ebrahimi; Walid Hassan; Sumit Singh; Indu Mohan Babu Nori
Original assignee: Verizon Patent and Licensing Inc
Current assignee: Verizon Patent and Licensing Inc
Priority date: 2009-02-11
Filing date: 2009-12-11
Publication date: 2010-08-12
Also published as: US8156159B2; US20100205189A1

Abstract

An interface gateway may receive a request including a first interface identifier. The interface gateway is associated with a group of interfaces, where each interface is associated with metadata that defines the interface. The metadata may include an interface identifier, information identifying services to be executed for the interface and an order in which the identified services are to be executed, and information identifying servers on which the identified services are implemented. The interface gateway may also identify, for the received request, one interface, of the group of interfaces, for processing the request based on the first interface identifier. The interface gateway may further process the received request using the one interface. When processing the received request, the interface gateway may execute the identified services on the identified servers according to the order, where the executing causes data, associated with the received request, to be converted from a source format to a target format.

Description

RELATED APPLICATION

This application claims priority to U.S. Provisional Patent Application No. 61/151,728, filed Feb. 11, 2009, the entire disclosure of which is incorporated by reference herein.

BACKGROUND

A large enterprise may include a variety of data stores (e.g., operations support, enterprise resource planning (ERP), data warehouse (DW), enterprise performance management (EPM) applications, etc.), devices, and/or systems. However, the large enterprise may have difficulty providing end-to-end integration (e.g., communication integration, process integration between applications, etc.) between these data stores and/or devices given the diversity of the infrastructure. While there have been efforts to provide communication integration (e.g., an adapter framework) and process integration between specific applications (e.g., an Application Integration Architecture (AIA) framework), these solutions do not provide an infrastructure to integrate a heterogeneous system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary overview of a service integration platform;

FIG. 2 is a diagram of an exemplary environment according to implementations described herein;

FIG. 3 is a diagram of exemplary components of a service integration platform of FIG. 2;

FIG. 4 is a diagram of exemplary components of an interface gateway of FIG. 3;

FIG. 5 is a diagram of exemplary components of a device;

FIG. 6 is a diagram of exemplary functional components of an orchestrator of FIG. 4;

FIG. 7 is a diagram of an exemplary portion of a metadata database of FIG. 4;

FIG. 8 is a diagram of exemplary functional components of a portal of FIG. 3;

FIG. 9 is a flow chart of an exemplary process for configuring an interface at the interface gateway of FIG. 3;

FIGS. 10A-10E are diagrams of exemplary graphical user interfaces that may be provided in connection with the process described with respect to FIG. 9;

FIG. 11 is a flow chart of an exemplary process that may be performed by an interface gateway when operating in a real-time mode;

FIG. 12 is a flow chart of an exemplary process that may be performed by an interface gateway when operating in a batch mode;

FIG. 13 is a flow chart of an exemplary process for monitoring the execution of an interface; and

FIG. 14 is a flow chart of an exemplary process for performing error correction.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.
Systems and methods, described herein, may provide service integration among multiple, heterogeneous systems. In an exemplary implementation, a service integration platform may provide the service integration based on a service-oriented architecture (SOA).
FIG. 1 is a diagram of an exemplary overview 100 of a service integration platform. Assume that data (denoted as data A) is to be transferred from the purchasing department of a business desires to the financial department of the business. The data may include any type of information, such as information that is needed by the financial department, information that a user in the purchasing department desires to send to a user in the financial department, and/or other types of information. Assume further that data A is in a first format and that the financial department requires that the information in data A be provided in a different format, shown as data B.
As described herein, a service integration platform may be provided that acts as a generic interface that can be used to interface various kinds of systems, such as Enterprise Resource Planning (ERP) systems, Business Warehouse systems, Legacy systems, web services, Business-to-Business (B2B) systems, etc. and/or data sources, such as BizFrame, VFrame, flat files, spreadsheets, etc., and/or other types of systems and/or data sources that may exist in a heterogeneous system. As such, the service integration platform may receive data in one type of format and from one type of system, convert the data to another type of format, and transfer the data to another type of system.
Thus, in overview 100, the user in the purchasing department, the user in the financial department, or another user (e.g., an administrator at the business) may configure an interface of the service integration platform to convert data from the purchasing department system to a desired format of the financial department system. Once the interface has been configured at the service integration platform, the user in the purchasing department may transfer data A to the service integration platform. The service integration platform may identify the appropriate interface for converting the information from data A, convert the information to the appropriate format used by the financial department system (to create data B), and transfer data B to the financial department system.
FIG. 2 is a diagram of an exemplary environment 200 according to implementations described herein. As illustrated, environment 200 may include a user device 210, a scheduler 220, and a service integration platform 230 that interconnect via a network 240.
User device 210 may include one or more devices that can transmit a request to process data to service integration platform 230 in a real-time mode. In addition, user device 210 may include one or more devices that allow a user to interact with service integration platform 230. In one implementation, user device 210 may include a desktop computer, a laptop computer, a mainframe computer, a server, a handheld computing device (such as a cellular telephone, a personal digital assistant (PDA), etc.), and/or some other type of computational device. User device 210 may connect to network 240 via a wired and/or wireless connection.
Scheduler 220 may include one or more devices that can transmit a request to process data to service integration platform 230 in a batch mode. In one implementation, scheduler 220 may include a desktop computer, a laptop computer, a mainframe computer, a server, and/or some other type of computational device. Scheduler 220 may connect to network 240 via a wired and/or wireless connection.
Service integration platform 230 may include one or more devices that provide service integration for heterogeneous systems and/or data sources. Service integration platform 230 may include various interfaces that allow for transfer of data between different types of systems. In one implementation, each interface may have a one-to-one correspondence between a first system/data source and a second system/data source so as to provide data conversions between the first system/data source and the second system/data source. In addition, service integration platform 230 may include one or more devices that allow a user to interact with service integration platform 230 to, for example, configure an interface on service integration platform 230, monitor the processing of data at service integration platform 230, perform error correction with respect to data being processed at service integration platform 230, and/or perform other functions. Service integration platform 230 may include, for example, one or more mainframe computers, servers, desktop computers, laptop computers, and/or some other type of computational device.
As indicated above, service integration platform 230 may operate in a real-time mode and a batch mode. In the real-time mode, service integration platform 230 may receive a request to process a single payload of data from a user device, such as user device 210, identify an interface for processing the single payload, and process the single payload using the interface. In the batch mode, service integration platform 230 may receive a request to process a large payload from a scheduler, such as scheduler 220, identify an interface for processing the large payload, and process the large payload using the interface. Additional details regarding the real-time and batch modes are provided below in connection with FIGS. 11 and 12, respectively.
Network 240 may include one or more networks of any type (wired and/or wireless). For example, network 240 may include a local area network (LAN), a wide area network (WAN), a telephone network, such as a Public Switched Telephone Network (PSTN) or a cellular network, a satellite network, an intranet, the Internet, a data network, a private network, or a combination of networks.
Although FIG. 2 illustrates exemplary components of environment 200, in practice, environment 200 may include additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, and/or differently arranged devices and/or networks than those illustrated in FIG. 2. Additionally, or alternatively, one or more devices in FIG. 2 may perform one or more tasks described as being performed by one or more other devices in FIG. 2.
FIG. 3 is a diagram of exemplary components of service integration platform 230. As illustrated, service integration platform 230 may include an interface gateway 310 and a portal 320.
Interface gateway 310 may include one or more devices that act as the heart of service integration platform 230. Interface gateway 310 may provide the interfaces for processing data in real-time and batch modes. Interface gateway 310 may also provide monitoring services and error correction services. Interface gateway 310 may include, for example, one or more mainframe computers, servers, desktop computers, laptop computers, mainframe computers, and/or some other type of computational device.
Portal 320 may include one or more devices that allow a user to interact with interface gateway 310. For example, portal 320 may provide graphical user interfaces to a user device, such as user device 210, that allow a user to configure an interface on interface gateway 310, monitor the processing of data at interface gateway 310, perform error correction with respect to data being processed at interface gateway 310, and/or perform other functions. In addition, portal 320 may authenticate a user prior to providing the graphical user interfaces. In one implementation, the graphical user interfaces may be provided as web pages. Portal 320 may include, for example, one or more mainframe computers, servers, desktop computers, laptop computers, and/or some other type of computational device.
Although FIG. 3 illustrates exemplary components of service integration platform 230, in practice, service integration platform 230 may include additional components, fewer components, different components, and/or differently arranged components than those illustrated in FIG. 3. Additionally, or alternatively, one component in FIG. 3 may perform one or more tasks described as being performed by another component in FIG. 3.
FIG. 4 is a diagram of exemplary components of interface gateway 310. As illustrated, interface gateway 310 may include a security component 405, an Integrated Specific Service (ISS) component 410, an orchestrator component 415, a service adapter component 420, a services component 425, a cache component 430, an application database component 435, a metadata database 440, a transactional database 445, and a real time monitor component 450.
Security component 405 may include one or more devices that authenticate a received request. The authentication may include authenticating the device from which the request is received and/or the user with which the request is associated. For example, security component 405 may receive a real-time request from user device 210 and may, in response to receiving the request, authenticate user device 210. For example, the real-time request may include information identifying user device 210 and security component 405 may use that information to authenticate user device 210. Additionally, or alternatively, security component 405 may send a request for information to user device 210 and may use information returned from that request to authenticate user device 210. Security component 405 may further receive a batch request from scheduler 220 and may, in response to receiving the request, authenticate scheduler 220. For example, the batch request may include information identifying scheduler 220 and security component 405 may use that information to authenticate scheduler 220. Additionally, or alternatively, security component 405 may send a request for information to scheduler 220 and may use information returned from that request to authenticate scheduler 220. Security component 405 may transfer received requests to ISS component 410 in the real-time mode and/or to orchestrator component 415 in the batch mode.
ISS component 410 may include one or more devices to convert received data, in the real-time mode, to a canonical structure. In one implementation, the canonical structure may include a canonical eXtensible Markup Language (XML) structure. Thus, for example, if the incoming data is in the form of an XML document, an Intermediate Document (IDoc), a string, etc., ISS component 410 may convert the incoming data (regardless of the format) to the canonical XML structure. Other types of canonical structures can alternatively be used. ISS component 410 may transfer the data in the canonical structure to orchestrator 415.
In one exemplary implementation, ISS component 410 may include a data router and a group of translators, where each translator translates a different data format to the canonical structure. The data router may receive data, detect the format of the received data, identify, based on the detected format, the appropriate translator for translating the data, and route the data to the identified translator. The translator may then translate the received data to the canonical structure. To facilitate the requesting router's ability to detect the format of received data, in some implementations, users may use different naming conventions for naming the data, where the different naming conventions identify the format of the data. In these implementations, the data router may use the naming convention of incoming data to identify the appropriate translator to which to route the data.
Orchestrator component 415 may include one or more devices that act as the main component of interface gateway 310. Orchestrator component 415 may determine, based on data from metadata database 440, the other components of interface gateway 310 that need to be invoked to complete an interface. In one implementation, orchestrator component 415 may be implemented using Business Process Execution Language (BPEL). Orchestrator 415 may operate in an asynchronous manner in the batch mode and a synchronous and/or asynchronous manner in the real-time mode. Further details regarding orchestrator component 415 are provided below with respect to FIG. 6.
Service adapter component 420 may include one or more devices that act as a service implementation channel to access the services in services component 425. In one implementation, service adapter component 420 may include a group of adapters that allow for different types of services to be invoked. For example, the group of adapters may include one or more Oracle Data Integration (ODI) adapters, SAP adapters, database adapters, legacy adapters, File Transfer Protocol (FTP) adapters, and/or other types of adapters. Service adapter component 420 may enable a service-oriented architecture to exist in interface gateway 310, where new services may be added to services component 425 without affecting the rest of interface gateway 310.
Services component 425 may include one or more devices that provide services for processing data. The services may include process monitoring services, masking engine services, data services (e.g., that allow connectivity to databases), data error handling services, correction and recycling services, notification services, error handling services, Secure File Transfer Protocol (SFTP) services, and/or other types of services. The services may be implemented as ODI services, SAP services, Java Web Services, Unix shell script, and/or other types of services.
Cache component 430 may include one or more devices that may store data. In one implementation, cache component 430 may cache data (e.g., in one or more reference tables) from application database 435 that may be needed by services component 425. In this way, data may be available to services component 425 faster than if the data is retrieved from application database 435.
Application database 435 may include one or more devices that store data that may be accessed by services component 425. As indicated above, cache component 430 may retrieve data, from application database 435, which may be needed by services component 425.
Metadata database 440 may include one or more devices that store metadata that define the interfaces of interface gateway 310. For example, metadata database 440 may store the parameters of each interface with which interface gateway 310 is associated, along with information identifying the rules to be executed for each interface, the servers that need to be called for each interface, the services to be executed for each interface, and/or other information needed for executing an interface. While one metadata database is shown, it will be appreciated that metadata database 440 may consist of multiple databases stored locally at interface gateway 310, or stored at one or more different and possibly remote locations. Additional details regarding metadata database 440 are provided below with respect to FIG. 7.
Transactional database 445 may include one or more devices that store information relating to the processing of data by interface gateway 310. In one implementation, transactional database 445 may store information relating to errors that occurred while processing data by interface gateway 310. For example, transactional database 445 may maintain error tables that store data errors that were captured while processing the data in interface gateway 310. While one transactional database is shown, it will be appreciated that transactional database 445 may consist of multiple databases stored locally at interface gateway 310, or stored at one or more different and possibly remote locations.
Real time monitor component 450 may include one or more devices that may monitor the operation of orchestrator component 415 and/or other components of interface gateway 310. For example, orchestrator component 415 may transmit, in real time, status information to real time monitor component 450. Real time monitor component 450 may receive this status information and, for example, provide the status information to portal 320 to allow a user to track the latest status of the execution of data using the interfaces of interface gateway 310.
Although FIG. 4 illustrates exemplary components of interface gateway 310, in practice, interface gateway 310 may include additional components, fewer components, different components, and/or differently arranged components than those illustrated in FIG. 4. Additionally, or alternatively, one or more components in FIG. 4 may perform one or more tasks described as being performed by one or more other components in FIG. 4.
FIG. 5 is a diagram of exemplary components of a device 500 that may correspond to one or more of the devices or components depicted in FIGS. 2-4. For example, device 500 may correspond to user device 210, scheduler 220, one or more components of interface gateway 310, and/or one or more components of portal 320. As illustrated, device 500 may include a processing system 505, a memory 510, an input component 515, an output component 520, and a communication interface 525.
Processing system 505 may include one or more processors, microprocessors, and/or another type of component that may interpret and execute instructions. In some implementations, processing system 505 may include one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.
Memory 510 may include a random access memory (RAM), a dynamic random access memory (DRAM), a ferroelectric random access memory (FRAM), a read only memory (ROM), a programmable read only memory (PROM), a flash memory, and/or some other type of memory. Memory 510 may additionally, or alternatively, include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.) or some other type of computer-readable medium, along with a corresponding drive. A computer-readable medium may correspond to, for example, a physical memory device or a logical memory device. A logical memory device may include memory space within a single physical memory device or spread across multiple physical memory devices residing on one or more devices.
Input component 515 may permit an operator to input information into device 500. For example, input component 515 may include a keyboard, a button, a switch, a knob, a touchpad, a display, and/or some other type of input component. Output component 520 may permit device 500 to output information to the operator. For example, output component 520 may include a display, light emitting diodes (LEDs), a speaker, and/or some other type of output component.
Communication interface 525 may permit device 500 to communicate with other devices, networks, and/or systems. For example, communication interface 520 may include some type of wireless and/or wired interface.
As described herein, device 500 may perform certain operations in response to processing system 505 executing software instructions contained in a computer-readable medium, such as memory 510. The software instructions may be read into memory 510 from another computer-readable medium or from another device via communication interface 525. The software instructions contained in memory 510 may cause processing system 505 to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
Although FIG. 5 illustrates exemplary components of device 500, in practice, device 500 may include additional components, fewer components, different components, and/or differently arranged components than those illustrated in FIG. 5. Additionally, or alternatively, one or more components in FIG. 5 may perform one or more tasks described as being performed by one or more other components in FIG. 5.
FIG. 6 is a diagram of exemplary functional components of orchestrator component 415. As illustrated in FIG. 6, orchestrator component 415 may include a master component 610, a preprocess component 620, an initialization component 630, a preparation component 640, a process component 650, a completion component 660, and a notification engine 670. The functional components of orchestrator component 415 may be implemented using one or more components of device 500 of FIG. 5.
Master component 610 may include one or more functional components that may be invoked when interface gateway 310 is operating in the real-time mode or the batch mode. Master component 610 may receive information from ISS 410 (in the real-time mode) or security component 405 (in the batch mode), identify an interface, and invoke the appropriate one or ones of preprocessing component 620, initialization component 630, preparation component 640, process component 650, and completion component 660 for executing the identified interface. In this way, master component 610 may control the execution of an interface for processing received data. In one implementation, master component 610 may be implemented using BPEL.
Preprocess component 620 may include one or more functional components that may be invoked when interface gateway 310 is operating in the batch mode. Preprocess component 620 may receive information identifying one or more files to be processed and the location of the one or more files. Preprocess component 620 may use the received information to retrieve the one or more files from the location and store the one or more files in a target location.
Initialization component 630 may include one or more functional components that may be invoked when interface gateway 310 is operating in the real-time mode or the batch mode. Initialization component 630 may initialize an interface that will be used to process data in the real-time mode or the batch mode. For example, initialization component 630 may create the session logs for the processing of real-time or batch data and ensure, in the batch mode, that preprocess component 620 has moved the appropriate files to the target location.
Preparation component 640 may include one or more functional components that may be invoked when interface gateway 310 is operating in the real-time mode or the batch mode. In the real-time mode, preparation component 640 may convert the input data (e.g., from user device 210) to a canonical structure (e.g., a canonical XML structure). In the batch mode, preparation component 640 may convert the input data (e.g., from a retrieved file, a database, etc.) to a canonical structure (e.g., a canonical XML structure). In the real-time and batch modes, preparation component 640 may invoke one or more services, in services component 425, to perform the data conversions.
Process component 650 may include one or more functional components that may be invoked when interface gateway 310 is operating in the real-time mode or the batch mode. Process component 650 may invoke one or more services, in services component 425, to perform data translations, data transformations, etc. For example, process component 650 may invoke one or more services to retrieve the data in the canonical structure and translate/transform the data to the target structure. In addition, process component 650 may perform data edits/validations. Process component 650 may identify any records that fail the edits/validation check for notification and/or error correction purposes.
Completion component 660 may include one or more functional components that may be invoked when interface gateway 310 is operating in the real-time mode or the batch mode. In addition, completion component 660 may be invoked when the interface execution succeeds and when the interface execution fails. For example, if the interface execution succeeds, completion component 660 may push the final data to the appropriate target system and notify master component 610 and notification engine 670 of the successful execution of the interface. In case of a failure, completion component 660 may notify master component 610 and notification engine 670 that the execution of the interface has failed.
Notification engine 670 may include one or more functional components that notify appropriate personnel as to whether the execution of the interface has succeeded or failed. For example, notification engine 670 may receive notifications from completion component 660 and may send notifications to the appropriate personnel in response thereto and based on contact information from, for example, metadata database 440. In one implementation, notification engine 670 may notify users of detected errors in response to data errors being logged in transactional database 445.
Although FIG. 6 illustrates exemplary functional components of orchestrator component 415, in practice, orchestrator component 415 may include additional functional components, fewer functional components, different functional components, and/or differently arranged functional components than those illustrated in FIG. 6. Additionally, or alternatively, one or more functional components in FIG. 6 may perform one or more tasks described as being performed by one or more other functional components in FIG. 6.
FIG. 7 is a diagram of an exemplary portion of metadata database 440. As shown, metadata database 440 may include, among other tables, an interface table 705, a rule master table 710, a rule details table 715, a Rule Server Service (RSS) details table 720, a server parameter table 725, a service parameter table 730, an application master table 735, and a canonical master table 740.
Interface table 705 may be the main table in metadata database 440. Interface table 705 may store details for each interface in interface gateway 310. Each interface may be associated with a unique interface identifier (ID) in interface table 705. This unique interface ID may provide a mapping from interface table 705 to rule master table 710. Interface table 705 may also include information mapping to application master table 735 and canonical master table 740. Interface table 705 may store an appl_id foreign key reference from application master table 735 and a canon_master_id foreign key reference from canonical master table 740.
Rule master table 710 may store information identifying the rules (e.g., business rules) to be used for implementing the interface, associated with the particular interface ID identified in rule master table 710. In one implementation, rule master table 710 may identify the rules to be used by preprocess component 620, initialization component 630, preparation component 640, process component 650, and/or completion component 660, and identify the order in which the rules are to be executed (e.g., a particular sequence or that some of the rules may be executed in parallel) for a particular interface. For example, rule master table 710 may identify, for a particular interface, five rules (or steps) that are to be executed by process component 650 and indicate that these rules (or steps) may be executed in parallel. Among other things, rule master table 710 may specify a particular process type (e.g., a process performed by initialization component 630, a process performed by preparation component 640, a process performed by process component 650, and/or a process performed by completion component 660), a rule type (e.g., translation, transformation, edits/validations, etc.), and a run type (e.g., a regular run or an error run). Each rule, in rule master table 710, may be associated with a rule ID.
Rule details table 715 may be a child table of rule master table 710. Rule details table 715 may store information identifying a list of steps to be performed for a given rule identified in rule master table 710 and information specifying the order that the steps are to be performed. Rule details table 715 may store a rule_id foreign key reference from rule master table 710.
RSS details table 720 may store information that maps a rule to a server and/or a service. Thus, RSS details table 720 may include a rule_det_id foreign key reference from rules detail table 720, a server_id foreign key reference from server parameter table 725, and a service_id foreign key reference from service parameter table 730.
Server parameter table 725 may act as the basic definition table for the different types of servers that may be used. For example, server parameter table 725 may store server-related information (e.g., server name, server port, user details, context information, etc.) that is to be used for invoking different services. Server parameter table 725 may store an appl_id foreign key reference from application master table 735.
Service parameter table 730 may store details (e.g., service names and scenarios) regarding all of the services associated with interface gateway 310. Each service may be associated with a service ID. Service parameter table 730 may store an appl_id foreign key reference from application master table 735.
Application master table 735 may store information identifying the name of an application associated with interface gateway 310 and the corresponding code.
Canonical master table 740 may store the details of the canonical structure and information that may be used to map canonical structures to the different applications associated with interface gateway 310. Canonical master table 740 may store an appl_id foreign key reference from application master table 735.
Although FIG. 7 illustrates exemplary tables of metadata database 440, in practice, metadata database 440 may include additional tables, fewer tables, different tables, and/or differently arranged tables than those illustrated in FIG. 7. Additionally, or alternatively, one or more tables in FIG. 7 may store information described as being stored in one or more other tables in FIG. 7.
FIG. 8 is a diagram of exemplary functional components of portal 320. As illustrated, portal 320 may include a configuration component 810, a monitoring and audit component 820, an error correction component 830, and an administration component 840. The functional components of portal 320 may be implemented using one or more components of device 500 of FIG. 5.
Configuration component 810 may include one or more functional components that allow a user to configure and/or reconfigure an interface at interface gateway 310. For example, configuration component 810 may provide one or more graphical user interfaces, to user device 210, that allow a user to add a new interface to interface gateway 310, to modify an existing interface associated with interface gateway 310, to delete an existing interface associated with interface gateway 310, to create/configure/reconfigure server, service, and canonical details for an interface, and/or to perform other functions relating to interfaces for interface gateway 310. For example, configuration component 810 may provide one or more graphical user interfaces that allow a user to specify, for example, a name for the new interface, provide parameters relating to the new interface (e.g., a description of the new interface, a type of the new interface, a group to be notified of events relating to execution of the new interface, and/or other parameters); identify rules for the interface and the order in which the rules are to be executed; identify, for each rule, a component of orchestrator component 415 (e.g., preprocess component 620, initialization component 630, preparation component 640, process component 650, or completion component 660) with which the rule is associated; identify, for each rule, a server and a service to be executed for the rule; provide details about the servers that will be used for executing the interface; provide details about the services that are to be used for executing the interface; provide details regarding the canonical structure to be used for the interface; and/or provide additional information.
Monitoring and audit component 820 may include one or more functional components that provide a user with end-to-end status information as data is processed by interface gateway 310. For example, monitoring and audit component 820 may receive status information form real time monitor component 450 as data is being processed by interface gateway 310 and provide to a user, via one or more graphical user interfaces, the status of the data as the data is being processed (e.g., information identifying the component in interface gateway 310 that is currently processing the data). Monitoring and audit component 820 may also log data while interface gateway 310 processes the data, and provide the user with an audit report that, for example, provides information identifying each component in interface gateway 310 that has processing the data and, for each component, whether the processing was successful. Additional or other information may also be monitored and provided via monitoring and audit component 820.
Error correction component 830 may include one or more functional components that allow a user to correct errors that occurred during the processing of data by interface gateway 310. Error correction component 830 may, for example, provide information to the user that identifies any errors that occurred during the processing of data at interface gateway 310 (e.g., based on information from transactional database 445) and allow the user to correct the errors. In one implementation, error correction component 830 may include a mass correction feature and a smart fix feature. The mass correction feature may allow the user to correct errors based on defined criteria. The smart fix feature may remember all the errors that have been previously fixed. The user may select the smart fixes to apply on future executions of the same interface. The smart fixes may include a default feature that may cause a value to default to a particular value, a substitution feature that substitutes a selected value with a new value, a truncate feature that may cause a particular field to take a particular value and ignore unwanted characters, and/or other types of features.
Administration component 840 may include one or more functional components that allow a user (e.g., an administrator) to set privileges for accessing portal 320. For example, administration component 840 may provide one or more graphical user interfaces that allow a user to add new users and/or user groups, delete users and/or user groups, assign users to user groups, set access privileges for users and/or user groups, and/or to perform other functions relating to a user's or a user group's access to portal 320. In addition, administration component 840 may include one or more functional components that perform authentication of users attempting to access portal 320. For example, in response to a user accessing portal 320, administration component 840 may provide one or more graphical user interfaces to the user to authenticate the user prior to allowing the user to perform functions via portal 320. When a user has been properly authenticated, administrator component 840 may allow additional graphical user interfaces to be provided to the user based on access privileges associated with the user.
Although FIG. 8 illustrates exemplary functional components of portal 320, in practice, portal 320 may include additional functional components, fewer functional components, different functional components, and/or differently arranged functional components than those illustrated in FIG. 8. Additionally, or alternatively, one or more functional components in FIG. 8 may perform one or more tasks described as being performed by one or more other functional components in FIG. 8.
FIG. 9 is a flow chart of an exemplary process for configuring an interface at interface gateway 310. In one implementation, the processing of FIG. 9 may be performed by portal 320. In another implementation, some or all of the processing described below may be performed by one or more components, including or excluding portal 320.
Process 900 may include authenticating a user (block 910). For example, a user (at user device 210) may access portal 320 (e.g., via network 240). In response, portal 320 (e.g., administration component 840) may authenticate the user by, for example, requesting a user identifier and password from the user, receiving the user identifier and password from the user, and comparing the received user identifier and password to a stored list of user identifiers and passwords. If the received user identifier and password match a user identifier and password in the list of user identifiers and passwords, portal 320 may determine that the user has been properly authenticated and may provide the user with access to portal 320. Alternatively, if the received user identifier and password do not match a user identifier and password in the list of user identifiers and passwords, portal 320 may deny the user access to portal 320. Assume that portal 320 has properly authenticated the user.
Process 900 may further include receiving configuration information for an interface (block 920). For example, portal 320 may receive a request from the user to add a new interface to interface gateway 310 or modify an existing interface associated with interface gateway 310. In response, portal 320 may provide one or more graphical user interfaces to user device 210 to allow the user to define the new interface or modify an identified existing interface. Assume that the user desires to add a new interface to interface gateway 310. Portal 320 may provide one or more graphical user interfaces to user device 210 to allow the user to specify, for example, a name for the new interface, provide parameters relating to the new interface (e.g., a description of the new interface, a type of the new interface, a group to be notified of events relating to execution of the new interface, and/or other parameters); identify rules for the interface and the order in which the rules are to be executed; identify, for each rule, a component of orchestrator component 415 (e.g., preprocess component 620, initialization component 630, preparation component 640, process component 650, or completion component 660) with which the rule is associated; identify, for each rule, a server and a service to be executed for the rule; provide details about the servers that will be used for executing the interface; provide details about the services that are to be used for executing the interface; provide details regarding the canonical structure to be used for the interface; and/or provide additional information. In one implementation, portal 320 may obtain, via one or more graphical user interfaces, information from the user to populate one or more of interface table 705, rule master table 710, rule details table 715, RSS details table 720, server parameter table 725, service parameter table 730, application master table 735, canonical master table 740, and/or other tables in metadata database 440.
Process 900 may additionally include storing the configuration information for the interface (block 930). For example, portal 320 may store the configuration information in the appropriate tables of metadata database 440.
FIGS. 10A-10E are exemplary graphical user interfaces that may be provided to a user in adding a new interface to interface gateway 310. In FIG. 10A, a graphical user interface 1000 may allow a user to provide details regarding the new interface. For example, graphical user interface 1000 may allow the user to specify a name of the new interface, a type of the new interface, and/or other information regarding the new interface. Moreover, graphical user interface 1000 may allow the user to define rules to be associated with the new interface. For example, graphical user interface 1000 may allow the user to specify, for each rule, the name of the rule to be associated with the new interface, the order in which the rule is to be executed in connection with other rules for the new interface, the run type of the new rule (e.g., basic run or error run), the identity of the component of orchestrator component 415 with which the rule is associated (referred to as the “process type” in FIG. 10A), the rule type (e.g., translation, transformation, edits/validations, completion), and the type of service with which the rule is associated (e.g., ODI service, etc.).
In FIG. 10B, a graphical user interface 1010 may allow a user to provide details regarding a rule that has been specified in graphical user interface 1000. For example, graphical user interface 1010 may allow the user to specify details regarding one or more steps to be performed for a particular rule. In FIG. 10B, graphical user interface 1010 may allow the user to specify a name for the step, an order in which the step is to be executed in relation to other identified steps, a rule invocation type (e.g., synchronous, asynchronous, or one way), an identifier of the server at which the step will be performed, an identifier of a service to be performed by the step, and/or other information.
In FIG. 10C, a graphical user interface 1020 may allow a user to provide server parameters. For example, graphical user interface 1020 may allow the user to specify a server (e.g., the name of a server), a server type (e.g., SAP, ODI, etc.), a host name for the server, a port of the server, and/or other information relating to a server used for executing the new interface.
In FIG. 10D, a graphical user interface 1030 may allow a user to provide service parameters. For example, graphical user interface 1030 may allow the user to specify a service (e.g., the name of a service), a service version, a service type (e.g., JAVA, SAP, ODI, etc.), and/or other information relating to service parameters used for executing the new interface (such as call parameters for each service).
In FIG. 10E, a graphical user interface 1040 may allow a user to provide canonical structure details. For example, graphical user interface 1040 may allow the user to specify a canonical structure (e.g., the name of a canonical structure), a description of the canonical structure, and/or other information relating to a canonical structure that may be associated with the new interface. The user may also import an existing canonical structure for use with the new interface.
FIG. 11 is a flow chart of an exemplary process 1100 that may be performed by interface gateway 310 when operating in the real-time mode. In one implementation, the processing of FIG. 11 may be performed by interface gateway 310. In another implementation, some or all of the processing described below may be performed by one or more components, including or excluding interface gateway 310.
Process 1100 may include receiving a real-time data request (block 1105). For example, security component 405 may receive a real-time data request from a user device, such as user device 210. The request may include an interface identifier, a user identifier, a source system, a source file name identifier, and information identifying a run mode. The interface identifier may identify the interface to be used for processing the request. For example, the interface identifier may correspond to an identifier stored in interface table 705 of metadata database 440. The user identifier may identify a user, a company, or some other entity. The source system identifier may identify a system from which the request is received. For example, the source system identifier may correspond to a network address and/or some other type of identifier. The source file name identifier may identify the data to be processed by the interface. In one implementation, the data to be processed may accompany the request in the real-time mode. The run mode may indicate, for example, a basic run mode or an error mode.
Process 1100 may also include authenticating the request (block 1110). For example, security component 405 may use the user identifier, received in the request, to authenticate the user. Additionally, or alternatively, security component 405 may authenticate user device 210 or request information from the user or user device 210 to perform the authentication. If properly authenticated, security component 405 may pass the request to ISS component 410. If not properly authenticated, security component 405 may deny the request.
Process 1100 may additionally include converting data to a canonical structure (block 1115). For example, ISS component 410 may receive the request and accompanying data from security component 405 and may convert the data to a canonical format. In one implementation, ISS component 410 may convert the data into a canonical XML format. ISS component 410 may store the converted data in a shared memory and forward the request to orchestrator component 415.
Process 1100 may include identifying an interface and the orchestrator components for processing the request (block 1120). For example, orchestrator component 415 (e.g., master component 610) may receive the request (including the interface identifier) from ISS component 410. Master component 610 may, using the interface identifier from the request, query interface table 705, of metadata database 440, to determine the orchestrator components (e.g., one or more of process component 650 or completion component 660) to be invoked for the request. In addition, master component 610 may also identify, from the tables of metadata database 440, the rules that will be executed for the request, the servers and services that will be invoked for the request, and/or other information relating to the interface that will process the request.
Process 1100 may further include processing the data using one or more of process component 650 or completion component 660 (block 1125). For example, if interface table 705 indicates that process component 650 is to be invoked, process component 650 may, based on the rules, perform a translation and/or transformation operation. For example, master component 610 may send the interface identifier and the process type to the translation/transformation process. Based on the data from one or more of the tables of metadata database 440, the translation/transformation process may call the following services (from services component 425): a BPEL/Java/SAP service for performing the translation or transformation operation (e.g., a BPEL service may get the canonical XML from the shared memory and call the corresponding service to translate/transform the data); an adapter service; and/or an application service for applications (e.g., PeopleSoft, SAP, etc.); etc. Additionally, or alternatively, process component 650 may perform an edits/validations operation. This operation may include causing any business rules/edits that may be required to be executed. In one implementation, these business rules/edits may exist across multiple applications, such as PeopleSoft, COBOL, ODI, etc. As an example, process component 650 may receive the interface identifier and process type from master component 610 and use this information to access one or more tables in metadata database 440 to obtain the details of the application/module that holds the edits definition and details. Process component 650 may invoke a WSDL service to the corresponding application/module to execute the business rules/edits. Any record that fails the edits/validations operation may be stored in the shared memory for sending a notification to the appropriate user.
If interface table 705 indicates that completion component 660 is to be invoked, completion component 660 may, based on the rules, provide status information to notification engine 670 regarding the success and failure of the interface execution. If the interface execution is successful, completion component 660 may push the data into the appropriate target system and notify (e.g., via a success message) notification engine 670, which may, in turn, notify the appropriate user(s) via electronic mail (e-mail) or in another manner. Completion component 660 may further notify master component 610 of the successful execution of the interface. If, on the other hand, the interface execution fails, completion component 660 may notify (e.g., via a failure message) notification engine 670, which may, in turn, notify the appropriate user(s) via e-mail or in another manner. Completion component 660 may further notify master component 610 of the unsuccessful execution of the interface.
Process 1100 may also include performing real-time monitoring of the execution of the interface (block 1130). In one implementation, while the appropriate interface of interface gateway 310 is being executing to process the data, real-time monitor 450 may track the status of the processing of the data. For example, real-time monitor 450 may track whether the data has been successfully processed by one or more components of orchestrator component 415, whether the data has been unsuccessfully processed by one or more components of orchestrator component 415, whether the data is currently being processed by one or more components of orchestrator component 415, etc.
Process 1100 may include storing the monitored information in transactional database 445 (block 1135). For example, real-time monitor 450 (or another component or components of interface gateway 310) may store the status of data being processed in interface gateway 310 in transactional database 445. In one implementation, real-time monitor 450 (or another component or components of interface gateway 310) may only store error information in transactional database 445. The error information may include information identifying the data that experienced the error, information identifying the component of orchestrator component 415 that was processing the data when the error occurred, information identifying the service that was processing the data when the error occurred, the date/time when the error occurred, and/or other information.
FIG. 12 is a flow chart of an exemplary process 1200 that may be performed by interface gateway 310 when operating in the batch mode. In one implementation, the processing of FIG. 12 may be performed by interface gateway 310. In another implementation, some or all of the processing described below may be performed by one or more components, including or excluding interface gateway 310.
Process 1200 may include receiving a batch data request (block 1205). For example, security component 405 may receive a batch data request from a scheduler, such as scheduler 220. The request may include an interface identifier, a user identifier, a source system, a source file name identifier, and information identifying a run mode. The interface identifier may identify the interface to be used for processing the request. For example, the interface identifier may correspond to an identifier stored in interface table 705 of metadata database 440. The user identifier may identify a user, a company, or some other entity. The source system identifier may identify a scheduler from which the request is received. For example, the source system identifier may correspond to a network address and/or some other type of identifier of scheduler 220. The source file name identifier may identify a name of the data to be processed by the interface. The run mode may indicate, for example, a basic run mode or an error mode.
Process 1200 may also include authenticating the request (block 1210). For example, security component 405 may use the user identifier, received in the request, to authenticate the user. Additionally, or alternatively, security component 405 may authenticate scheduler 220 or request information from scheduler 220 to perform the authentication. If properly authenticated, security component 405 may pass the request to orchestrator component 415. If not properly authenticated, security component 405 may deny the request.
Process 1200 may include identifying an interface and the orchestrator components for processing the request (block 1215). For example, orchestrator component 415 (e.g., master component 610) may receive the request (including the interface identifier) from security component 405. Master component 610 may, using the interface identifier from the request, query interface table 705, of metadata database 440, to determine the orchestrator components (e.g., one or more of preprocess component 620, initialization component 630, preparation component 640, process component 650, or completion component 660) to be invoked for the request. In addition, master component 610 may also identify, from the tables of metadata database 440, the rules that will be executed for the request, the servers and services that will be invoked for the request, and/or other information relating to the interface that will process the request.
Process 1200 may further include processing the data using one or more of preprocess component 620, initialization component 630, preparation component 640, process component 650, or completion component 660 (block 1220). For example, if interface table 705 indicates that preprocess component 620 is to be invoked, preprocess component 620 may, based on the rules, receive the interface identifier and the file name from master component 610. Preprocess component 620 may access metadata database 440 to obtain, for example, information identifying the source device at which the bulk data is located (e.g., an address of the source device), information identifying the target device to which the bulk data is to be transferred (e.g., an address of the target device), and information identifying the location of the bulk data on the source device. Preprocess component 620 may use this information to retrieve the bulk data from the source device and store the bulk data at the target device. In one implementation, preprocess component 620 may invoke an SFTP service to retrieve the bulk data, which may return success or failure as a parameter to master component 610.
If interface table 705 indicates that initialization component 630 is to be invoked, initialization component 630 may, based on the rules, maintain session logs for the processing of the request. Initialization component 630 may also determine the name of the tables of metadata database 440 that are needed for processing the bulk data.
If interface table 705 indicates that preparation component 640 is to be invoked, preparation component 640 may, based on the rules, convert the data (e.g., from the file, a database, etc.) to a canonical XML format. The conversion may be based on information obtained from metadata database 440 and include one or more ODI service calls, one or more adapter calls (such as a database call, an FTP call, etc.), one or more Web Service Definition Language (WSDL) calls, one or more Java calls, and/or other types of calls.
If interface table 705 indicates that process component 650 is to be invoked, process component 650 may, based on the rules, perform a translation and/or transformation operation. For example, master component 610 may send the interface identifier and the process type to the translation/transformation process. Based on the data from one or more of the tables of metadata database 440, the translation/transformation process may call the following services (from services component 425): an ODI/stored procedure service (e.g., the translation/transformation process may call the ODI service (or any service that is implemented in batch mode) to process the data from the canonical table); an adapter service; and/or an application service for applications (e.g., PeopleSoft, SAP, etc.); etc. Additionally, or alternatively, process component 650 may perform an edits/validations operation. This operation may include causing any business rules/edits that may be required to be executed. In one implementation, these business rules/edits may exist across multiple applications, such as PeopleSoft, COBOL, ODI, etc. As an example, process component 650 may receive the interface identifier and process type from master component 610 and use this information to access one or more tables in metadata database 440 to obtain the details of the application/module that holds the edits definition and details. The application/module may access the shared memory to get the data for which the edits are to be performed, execute the edits, and store the data back in the shared memory.
If interface table 705 indicates that completion component 660 is to be invoked, completion component 660 may, based on the rules, provide status information to notification engine 670 regarding the success and failure of the interface execution. If the interface execution is successful, completion component 660 may push the data into the appropriate target system and notify (e.g., via a success message) notification engine 670, which may, in turn, notify the appropriate user(s) via electronic mail (e-mail) or in another manner. Completion component 660 may further notify master component 610 of the successful execution of the interface. If, on the other hand, the interface execution fails, completion component 660 may notify (e.g., via a failure message) notification engine 670, which may, in turn, notify the appropriate user(s) via e-mail or in another manner. Completion component 660 may further notify master component 610 of the unsuccessful execution of the interface.
Process 1200 may also include performing monitoring of the execution of the interface (block 1225). In one implementation, while the appropriate interface of interface gateway 310 is being executing to process the bulk data, real-time monitor 450 may track the status of the processing of the bulk data. For example, real-time monitor 450 may track whether the bulk data has been successfully processed by one or more components of orchestrator component 415, whether the bulk data has been unsuccessfully processed by one or more components of orchestrator component 415, whether the bulk data is currently being processed by one or more components of orchestrator component 415, etc.
Process 1200 may include storing the monitored information in transactional database 445 (block 1230). For example, real-time monitor 450 (or another component or components of interface gateway 310) may store the status of processing of the bulk data in transactional database 445. In one implementation, real-time monitor 450 (or another component or components of interface gateway 310) may only store error information in transactional database 445. The error information may include information identifying the data in the bulk data (e.g., the particular record) that experienced the error, information identifying the component of orchestrator component 415 that was processing the data when the error occurred, information identifying the service that was processing the data when the error occurred, the date/time when the error occurred, and/or other information.
FIG. 13 is a flow chart of an exemplary process for monitoring the execution of an interface. In one implementation, the processing of FIG. 13 may be performed by portal 320. In another implementation, some or all of the processing described below may be performed by one or more components, including or excluding portal 320.
Process 1300 may include authenticating the user (block 1310). For example, a user at user device 210 may access portal 320. Portal 320 (e.g., administration component 840) may authenticate the user by, for example, requesting a user identifier and password from the user, receiving the user identifier and password from the user, and comparing the received user identifier and password to a stored list of user identifiers and passwords. If the received user identifier and password match a user identifier and password in the list of user identifiers and passwords, portal 320 may determine that the user has been properly authenticated and may provide the user with access to portal 320. Alternatively, if the received user identifier and password do not match a user identifier and password in the list of user identifiers and passwords, portal 320 may deny the user access to portal 320. Assume that portal 320 has properly authenticated the user.
Process 1300 may also include receiving a request for process monitoring (block 1320). For example, a user at user device 210 may cause user device 210 to transmit a request to monitor the processing of data by interface gateway 310 to portal 320.
Process 1300 may provide one or more graphical user interfaces to the user that allow the user to monitor the processing of data by interface gateway 310 (block 1330). For example, portal 320 (e.g., monitoring and audit component 820) may provide one or more graphical user interfaces that provide the current status of data that is being processed by interface gateway 310. The current status may include information identifying one or more components of orchestrator component 415 that are currently processing the data and/or other information relating to the current status of the data or past status of the data. The status information may further include error information.
FIG. 14 is a flow chart of an exemplary process for performing error correction. In one implementation, the processing of FIG. 14 may be performed by portal 320. In another implementation, some or all of the processing described below may be performed by one or more components, including or excluding portal 320.
Process 1400 may include authenticating the user (block 1420). For example, a user at user device 210 may access portal 320. Portal 320 (e.g., administration component 840) may authenticate the user by, for example, requesting a user identifier and password from the user, receiving the user identifier and password from the user, and comparing the received user identifier and password to a stored list of user identifiers and passwords. If the received user identifier and password match a user identifier and password in the list of user identifiers and passwords, portal 320 may determine that the user has been properly authenticated and may provide the user with access to portal 320. Alternatively, if the received user identifier and password do not match a user identifier and password in the list of user identifiers and passwords, portal 320 may deny the user access to portal 320. Assume that portal 320 has properly authenticated the user.
Process 1400 may also include receiving a request for performing error correction (block 1420). For example, a user at user device 210 may cause user device 210 to transmit a request to perform error correction to portal 320.
Process 1400 may provide one or more graphical user interfaces to the user to allow the user to perform error correction (block 1430). For example, portal 320 (e.g., error correction component 830) may dynamically connect to transactional database 445 to obtain the data from corresponding tables for that interface and instance. Error correction component 830 may provide one or more graphical user interfaces to the user to allow the user to correct errors that occurred, for example, when interface gateway 310 was operating in a bulk mode. Error correction component 830 may provide a mass correction feature and a smart fix feature. The mass correction feature may cause errors to be corrected that match selected criteria. The smart fix feature may remember all the errors that have been fixed previously and can apply those corrections to future executions of the same interface. The smart fix feature may allow, for example, for default values to be given to any particular column of a record that includes a null value, selected values to be replaced with another value, selected values to be truncated, and/or other operations. Error correction component 830 may further allow the user to generate a report that shows the errors that have occurred when executing a particular instance of an interface, cause the instance of the interface to be re-executed, and/or perform other operations.
Implementations described herein provide a generic (one size fits all) interface gateway that can be used to implement any type of interface for various kinds of systems, such as ERP systems (e.g., SAP, PeopleSoft, etc.), Business Warehouse systems, Legacy systems, web services, business-to-business services, etc. In addition, the generic interface gateway can handle single payload requests, as well as batch request, where the payload is very big. The generic interface gateway may include a metadata-driven orchestration component that acts as the heart of the interface gateway. Users may configure an interface for the interface gateway by configuring the metadata-driven orchestration component to invoke whatever types of services are needed for processing the users' data. The orchestration component may read the metadata for the given interface to be executed and orchestrate the services in the defined order. The orchestration component may also decide whether the services can be triggered in sequential or parallel mode.
In addition, a portal may be provided that allows for end-to-end status monitoring of the execution of an interface. The portal may also allow for dynamic error correction through, for example, a mass correction feature and/or a smart fix feature.
The foregoing description of implementations provides illustration, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Accordingly, modifications to the implementations described herein may be possible.
For example, while series of blocks have been described with regard to FIGS. 9 and 11-14, the order of the blocks may be modified in other embodiments. Further, non-dependent blocks may be performed in parallel.
It will be apparent that embodiments, as described herein, may be implemented in many different forms of software, firmware, and hardware in the embodiments illustrated in the figures. The actual software code or specialized control hardware used to implement embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that software and control hardware may be designed to implement the embodiments based on the description herein.
Further, certain portions, described above, may be implemented as a component that performs one or more functions. A component, as used herein, may include hardware, such as a processor, ASIC, or FPGA, or a combination of hardware and software (e.g., a processor executing software).
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.
No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

Claims

1. A method comprising:

receiving, by an interface gateway, a batch data request, the interface gateway being associated with a plurality of interfaces, each interface, of the plurality of interfaces, providing conversion between a different set of source and target formats, each interface further being associated with a combination of components from a group of components that includes:

a first component to fetch data from a source location and store the fetched data in a particular target location,

a second component to create session logs relating to a processing of data at the interface gateway,

a third component to convert data to a canonical format,

a fourth component to at least one of translate data, transform data, or edit data, and

a fifth component to forward data to a target system and notify one or more users of a successful or unsuccessful processing of data by the interface gateway;

identifying, by the interface gateway and based on receiving the batch data request, one interface, of the plurality of interfaces, with which the batch data request is to be processed; and

processing, by the interface gateway, batch data, associated with the batch data request, using the identified one interface, the processing causing the batch data to be converted to the target format, the processing including invoking the combination of components with which the identified one interface is associated.

2. The method of claim 1, further comprising:

authenticating, prior to identifying the one interface, the batch data request.

3. The method of claim 1, where the batch data request includes an interface identifier that corresponds to the one interface and a file name for the batch data,

where the processing includes invoking the first component, and

where the invoking the first component includes:

receiving, by the first component, the interface identifier and the file name,

using, by the first component, the interface identifier to determine first information identifying a source device where the batch data is stored, second information identifying a target device where the batch data is to be stored, and third information identifying a location, in the target device, where the batch data is to be stored,

retrieving, by the first component, the bulk data from the source device using the first information, and

storing the bulk data at the location in the target device using the second information and the third information.

4. The method of claim 1, where the batch data request includes an interface identifier that corresponds to the one interface,

where the processing includes invoking the third component, and

where the invoking the third component includes:

converting the bulk data to a canonical eXtensible Markup Language (XML) structure, the canonical XML structure being identified using the interface identifier.

5. The method of claim 1, where the batch data request includes an interface identifier that corresponds to the one interface,

where the processing includes invoking the fourth component, and

where the invoking the fourth component includes:

performing at least one of translating the bulk data, transforming the bulk data, or editing the bulk data based on the interface identifier.

6. The method of claim 1, further comprising:

monitoring the processing of the bulk data by the one interface to create monitored data, and

providing the monitored data to a user.

7. The method of claim 1, further comprising:

detecting an error occurring during the processing of the bulk data;

logging the detected error; and

providing information relating to the detected error to a user.

8. The method of claim 7, further comprising:

receiving a signal from the user, and

reprocessing data, in the bulk data that is associated with the error, using the one interface, the reprocessing being performed in response to receiving the signal.

9. The method of claim 1, further comprising:

providing a portal that allows a user to configure the one interface, where the configuring the one interface includes:

receiving first information specifying the combination of components with which the interface is associated,

receiving second information identifying steps to be executed by the combination of components and an order in which the steps are to be executed,

receiving third information identifying services that are to be invoked for executing the identified steps,

receiving fourth information identifying servers on which the identified services are located, and

associating the first information, the second information, the third information, and the fourth information in a database.

10. A system comprising:

an interface gateway that includes:

a memory to store a plurality of tables, the plurality of tables defining different interfaces that are used to process data that are to be transferred between source systems and target systems, the plurality of tables including:

a first table to store parameters relating to an interface of the different interfaces, the parameters including an interface identifier,

a second table to store a plurality of rules that are used to implement the interface, where a first rule, of the plurality of rules, causes received data to be converted to a canonical structure, and where a second rule, of the plurality of rules, causes the canonical structure to be translated or transformed to a target format,

a third table to store information mapping, for at least one rule of the rules stored in the second table, the at least one rule to a server and a service,

a fourth table to store parameters for the server,

a fifth table to store parameters for the service, and

a sixth table to store parameters for the canonical structure; and

an orchestrator component to:

receive a request to process data, where the request includes the interface identifier and where the data is in a source format,

identify the interface using the interface identifier,

process the data using the interface to convert the data to the target format, where the target format is different than the source format, where when processing the data, the orchestrator component is to:

execute the rules, where, when executing the rules, the orchestrator component is to:

execute the first rule to cause the data to be converted to the canonical structure,

execute the second rule to cause the canonical structure to be translated or transformed into the target format, and

execute the at least one rule by invoking the service on the server.

11. The system of claim 10, where the request includes a real-time data request, and

where the orchestrator component receives the real-time data request from a user device.

12. The system of claim 10, where the request includes a batch data request, and

where the orchestrator component receives the batch data request from a scheduler.

13. The system of claim 10, where the interface gateway further includes:

an interface specific service component that connects to an input of the orchestrator component, the interface specific service component to:

convert data, received in connection with a real-time data request, to a canonical eXtensible Markup Language (XML) structure.

14. The system of claim 10, where the interface gateway further includes:

a services component to:

implement one or more services for processing data received at the interface gateway, the one or more services including at least one of a monitoring service, a masking engine service, a data service that allows connectivity to a database, a data error handling service, a correction and recycling service, a notification service, an error handling service, or a Secure File Transfer Protocol (SFTP) service.

15. The system of claim 10, where the interface gateway further includes:

a services component to:

implement a plurality of different types of services for processing data received at the interface gateway, the plurality of services being implemented as at least two of an Oracle Data Integration (ODI) service, a SAP service, a Java Web Service, or a Unix shell script.

16. The system of claim 15, where the interface gateway further includes:

a service adapter component that includes a group of adapters for the different types of services implemented by the services component.

17. The system of claim 10, where the interface gateway further includes:

a transactional database to:

store information relating to errors that occurred while processing the data by the interface gateway.

18. The system of claim 10, further comprising:

a portal to:

provide one or more graphical user interfaces to a user that allow the user to create a new interface for the interface gateway, modify an existing interface associated with the interface gateway, and delete an existing interface associated with the interface gateway.

19. The system of claim 10, where the portal is further to at least one of:

provide one or more graphical user interfaces to the user to allow the user to perform real-time monitoring of a status of data being processed by the interface gateway, or

provide one or more graphical user interfaces to the user to allow the user to perform error correction.

20. A method comprising:

receiving a request at an interface gateway, the request including a first interface identifier, the interface gateway being associated with a plurality of interfaces, each interface, of the plurality of interfaces, being associated with metadata that defines the interface, the metadata including:

an interface identifier,

information identifying services to be executed for the interface and an order in which the identified services are to be executed, and

information identifying servers on which the identified services are implemented;

identifying, by the interface gateway and for the received request, one interface, of the plurality of interfaces, for processing the request based on the first interface identifier; and

processing, by interface gateway and using the one interface, the received request, the processing including:

executing the identified services on the identified servers according to the order, the executing causing data, associated with the received request, to be converted from a source format to a target format.

21. The method of claim 20, where the plurality of interfaces are user-configurable.

22. The method of claim 20, where the request includes a batch data processing request.

23. The method of claim 20, further comprising:

monitoring the processing of the received request to obtain status information; and

providing, via a graphical user interface, the status information to a user associated with the one interface.

24. The method of claim 20, further comprising:

monitoring the processing of the received request to identify errors;

providing, via a graphical user interface, the errors to a user associated with the one interface; and

allowing the user to dynamically correct the identified errors.