A computer-implemented method, computer program product, and computer system are provided to: (i) receive, via a first communication component of a connectivity component, a debug request from an on-premise server; (ii) identify, at the connectivity component, a debug port of an off-premise server based on the received debug port request; and (iii) communicate, via a second communication component of the connectivity component, the debug request to the identified debug port of the off-premise server.

BACKGROUND

The present invention relates generally to debugging, and more particularly to debugging across off-premise and on-premise platforms.

Communication between on-premise and off-premise platforms is required in Software as a Service (SaaS) environments and hybrid integration systems. SaaS is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted by an off-premise platform (such as a shared computing resource or a cloud computing resource accessible via the Internet for example). SaaS is typically accessed by users of an on-premise platform (for example, using a thin client via a web browser). Hybrid integration systems deploy parts of the integration in an off-premise platform and other parts in an on-premise platform.

On-premise platforms are well-established and considered to provide a good level of security because data is stored and handled internally, e.g., within an internal private network. Off-premise platforms (such as cloud computing resources) are a relatively recent and evolving concept. Generally, reference to off-premise resources or platforms is taken to refer to a concept for enabling ubiquitous, convenient, and on-demand access via Internet to shared pools of configurable off-premise (e.g. remotely located) computing resources such as networks, applications, servers, storages, applications, functionalities, and the like. Conversely, reference to on-premise resources or platforms is taken to refer to a concept of local or private computing resources such as networks, servers, storage devices, application, etc. that are situated locally or within/behind a virtual boundary (often behind a firewall).

Debugging and fault analysis of such systems hosted across on-premise and off-premise platforms can be difficult and complex, for example, because there can be several parts to one integration flow that reside both off-premise (e.g. in cloud computing resources) and on-premise. Debugging separate parts across on-premise and off-premise platforms may require a user to set up access between several systems. Some of these systems may be available on the public Internet, and may need to be secured, and others may be available on private networks, and may not be accessible to all.

SUMMARY

According to an aspect of the present invention, there is a computer-implemented method, computer program product, and computer system for managing debugging across off-premise and on-premise servers. The method comprises receiving, via a first communication component of a connectivity component, a debug request from an on-premise server. The method also comprises identifying, at the connectivity component, a debug port of an off-premise server based on the received debug port request. The method further comprises communicating, via a second communication component of the connectivity component, the debug request to the identified debug port of the off-premise server.

DETAILED DESCRIPTION

Embodiments of the present invention seek to provide a connectivity component for managing debugging between off-premise and on-premise servers, thus enabling several dislocated components of a system to be debugging via one local component for example.

Embodiments of the present invention also seek to provide a computer-implemented method of managing debugging across off-premise and on-premise servers. Embodiments of the present invention further seek to provide a computer program product including computer program code for implementing the proposed concepts when executed on a processor. Embodiments of the present invention yet further seek to provide a system adapted to execute this computer program code.

According to an embodiment of the present invention, there is provided a connectivity component adapted to manage debugging across off-premise and on-premise servers. The connectivity component comprises a first communication component adapted to receive a debug request from an on-premise server. The connectivity component also comprises a routing component adapted to identify a debug port of an off-premise server based on the received debug port request. A second communication component of the connectivity component is adapted to communicate the debug request to the identified debug port of the off-premise server.

Proposed is a concept of communicating debug requests between off-premise and on-premise sites/resources. This may allow a debug port of an off-premise (e.g. cloud) server to be exposed via a connectivity component, thus enabling the debug port to be connected to via an on-site (e.g. local) server. A cloud-based service may then be debugged using a local integration server in the same as for any other local application.

For example, proposed embodiments may provide a concept that facilitates the exposure of debug ports of all integration servers in a hybrid cloud integration system (including those of remote servers running in the cloud) via an on-premise (e.g. local) integration server. The on-premise integration server may thus gain access to a set of debug ports that an on-premise graphical debugger application can then connect to and be used to debug all integration servers in the hybrid system.

The proposed approach for exposing the remote (i.e. off-premise) debug ports is to employ a port forwarding capability of a connectivity component. Such a connectivity component may dynamically configure itself based on severs starting and stopping, for example.

Embodiments may provide a user with the impression that he/she is his/her local (i.e. on-premise) integration server, although he/she will in fact be debugging all enabled servers (including off-premise servers). This may allow for debugging integrations that consist of flows in more than one integration server and that are not collocated.

Thus, proposed embodiments may enable a user to connect to local integration server of a hybrid integration system yet enable the user to debug the entire hybrid integration system (including off-premise integration servers of the hybrid integration system).

Such embodiments may be facilitated by providing a connectivity component with a port-forwarding capability. Use of connectivity component in this manner may require minimal user setup and may also be secure. Further, such a connectivity component may be implemented in conjunction with pre-existing switch technology that facilitate reverse proxying and dynamic registering concepts.

A connectivity component, such as a switch component, is thus proposed which may manage debugging communication between the off-premise and on-premise systems by receiving a debug request from an on-premise server and then communicating the request to an off-premise server based on identified debug port data. Such debug port data may be identified by the connectivity component using a data store which is adapted to store debug port data associated with off-premise servers.

Proposed embodiments may avoid exposure of debug ports to public networks and may thus prevent or hinder the sensitive, confidential or valuable information from being compromised via a public network. For instance, connection from the off-premise server to the connectivity component and to the on-premise server may be secured (e.g. using HTTPS) to prevent other applications from being able to access the end systems.

Proposed concepts may allow local (i.e. on-premise) debugging of applications/systems which are configured to run either in the off-premise (e.g. cloud) environment, or the on-premise environment. For example, the applications/system may be separated such that the ones which require access to on-premise systems of record run in the on-premise servers, and ones that would benefit from off-loading their computationally intensive processing run in the off-premise infrastructure. A connectivity component, such as a switch component, is thus proposed which may manage debugging communication between the off-premise and on-premise systems by receiving a debug request from an on-premise server and then communicating the request to an off-premise server based on identified debug port(s). Such debug port(s) may be identified by the connectivity component using a data store which is adapted to store debug port data associated with off-premise applications.

Proposed concepts may facilitate mapping of debug ports between an off-premise system (e.g. SaaS environment) and an on-premise system. Also, proposed embodiments may avoid the exposure of debug ports and private or sensitive debugging information at the off-premise platform (e.g. via a public network).

In some environments, the first communication component of the connectivity component may be adapted to establish a secure tunnel for receiving the debug request. Similarly, the second communication component may be adapted to establish a secure tunnel for communicating the debug request. For example, a mutually authenticated TLS tunnel connection may be to transfer data between the two environments. Secure debugging communications between off-premise and on-premise platforms may therefore be provided.

By way of example, the debug request may comprise at least one of: an application name; a server identification; a server address; an application version identifier; permission information; entry point data, and/or checksum information. Such information may then be used to match a debug request to an off-premise server.

In an embodiment, the connectivity component may further comprise a registration module adapted to receive debug port data from at least one of: an application of an off-premise server; an application of an on-premise server; an off-premise server module; and/or an on-premise server module. The registration module may then be adapted to store received debug port data in a data store. Embodiments may therefore employ the concept of registering information about accessing or making use of off-premise debug ports with the connectivity component so that the connectivity component can identify how to handle (e.g. where to communicate) a debug request. By using such a registration concept, a data store of debug port data may be dynamically updated or maintained to reflect changes in available applications or severs.

For example, the registration module may be adapted to remove debug port data from the data store in response to at least one of: an application; a server; and/or a debug port becoming inaccessible (e.g. being disconnected, terminated, or powered-down). Proposed concepts may therefore be thought of as providing a dynamically updated store of debug port information representing off-premise debug ports that may be accessible, and how the debug ports are accessible (e.g. port identification, server location/address, supported applications, etc.). Embodiments may therefore provide a connectivity component which can adapt to implementation specifics and cater for changes in off-premise servers, thereby providing a high degree of flexibility and adaptability.

In an embodiment, the off-premise server may comprise a cloud sever, and the debug request may be provided by a debugging service of the on-premise server. Embodiments may therefore be employed in a hybrid system or SaaS environment for the provision of cloud-based services over the internet for example.

In embodiments, the second communication component may be adapted to receive a response to the debug request from the off-premise server. Also, the first communication component may be adapted to communicate the received response to the on-premise server. In this way, a response to a debug request may be communicated back to the on-premise originator of the debug request.

By way of further description and example, the debug request may be sent over the port forwarded connection (via the connectivity component) to the off-premise server and that connection may then remain open while an application of the off-premise server is being debugged. In this way, the port-forwarded connection enables data to be sent in both directions without the connection being closed (until debugging is finished). For instance, exemplary process steps implemented by an embodiment comprise: (i) establish a connection to the off-premise server via the connectivity component using port forwarding and dynamically-registered debug port data (e.g. off-premise server detail); (ii) communicate the debug request to the identified debug port of the off-premise server to set break points over the connection; and (iii) the off-premise server then sends data back to the debugger, over the same, long lived, connection, when break points are hit.

Proposed connectivity components may therefore provide for the management of debugging communication between off-premise and on-premise platforms so that requests and responses are appropriately delivered whilst avoiding exposure via one or more public networks.

Embodiments may be employed in a switch module. For example, there may be provided a switch module comprising a connectivity component according to a proposed embodiment. Also, embodiments may be implemented in a server device. Such a server device may be a cloud-based server resource accessible via the Internet.

According to another aspect, there is provided a computer-implemented method of managing debugging across off-premise and on-premise servers. The method comprises receiving, via a first communication component of a connectivity component, a debug request from an on-premise server. The method also comprises identifying, at the connectivity component, a debug port of an off-premise server based on the received debug port request. The method further comprises communicating, via a second communication component of the connectivity component, the debug request to the identified debug port of the off-premise server.

According to another embodiment of the present invention, there is provided a computer program product for managing debugging across off-premise and on-premise servers, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processing unit to cause the processing unit to perform a method according to one or more proposed embodiments when executed on at least one processor of a data processing system.

According to yet another aspect, there is provided a processing system comprising at least one processor and the computer program product according to one or more embodiments, wherein the at least one processor is adapted to execute the computer program code of said computer program product.

The processing system may be adapted to act as a switching or connectivity component between an on-premise server and an off-premise server. The processing system may be adapted to implement a part of an off-premise platform, such as a cloud-based system or server. Thus, there may be proposed a system which evaluates a debug request and determines where to communicate the request based on stored data associated with applications. Taking such an approach may enable dynamic and secure debugging access between on-premise and off-premise platforms, thus enabling debug ports of an off-premise server to be accessible via an on-premise server.

It should be understood that the Figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the FIGS. to indicate the same or similar parts.

In the context of the present application, where embodiments of the present invention constitute a method, it should be understood that such a method is a process for execution by a computer, i.e. is a computer-implementable method. The various steps of the method therefore reflect various parts of a computer program, e.g. various parts of one or more algorithms.

Also, in the context of the present application, a (processing) system may be a single device or a collection of distributed devices that are adapted to execute one or more embodiments of the methods of the present invention. For instance, a system may be a personal computer (PC), a server or a collection of PCs and/or servers connected via a network such as a local area network, the Internet and so on to cooperatively execute at least one embodiment of the methods of the present invention.

An “application” may be understood as being a processing resource, routine, set of instructions, data system, or processing construct which may be provided in a structured or ordered manner. Thus, when employed for integration between off-premise and on-premise resources (such as may be done in cloud-based provision of software to a user of an on-premise resource, or as part of a SaaS environment), one or more of the instructions, routines or processes of an application may be accessed by an external system, thus requiring communication between the off-premise and on-premise resources.

Embodiments of the present invention propose concepts for establishing and/or managing debugging communication between off-premise and on-premise platforms, wherein the data processing applications may be split or separated into applications which can be implemented in the off-premise environment or in the on-premise environment, and wherein the applications may invoke each other and exchange data via a connectivity component (e.g. a switching module). A connectivity component may thus be implemented to receive a debug request and forward such a request to the appropriate destination (e.g. debug port), wherein the appropriate debug port is determined based on the debug request and/or a data store comprising information about debug ports of off-premise servers. The connectivity component may thus enable a port-forwarded connection to be established with an off-premise server, and the connection may then remain open while an application of the off-premise server is being debugged.

Embodiments may therefore propose a concept of port forwarding from an off-premise server to an on-premise server, via a connectivity component. In this way, all debug ports for all integration servers in a user's system (including remote servers running in the cloud) may be exposed (i.e. accessible) via an on-premise (i.e. local) integration server.

Illustrative embodiments may therefore provide concepts for establishing a port-forwarded connection between off-premise resources and on-premise resources and for securely communicating debugging information between the off-premise resources and on-premise resources via said connection. Secure and dynamic distributed debugging of off-premise resources via an on-premise resource may therefore be provided by proposed embodiments. Modifications and additional steps to a traditional SaaS implementation may also be proposed which may enhance the value and utility of the proposed concepts.

Illustrative embodiments may be utilized in many different types of distributed processing environments. In order to provide a context for the description of elements and functionality of the illustrative embodiments, the figures are provided hereafter as an example environment in which aspects of the illustrative embodiments may be implemented. It should be appreciated that the figures are only exemplary and not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the present invention may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the present invention. Moreover, the system may take the form of any of a number of different processing devices including client computing devices, server computing devices, a tablet computer, laptop computer, telephone or other communication devices, personal digital assistants (PDAs), or the like. In some illustrative examples, an off-premise device and an on-premise device may comprise a portable computing device that is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data, for example. Thus, the system may essentially be any known or later-developed processing system without architectural limitation.

A proposed concept may enhance a hybrid cloud system by providing a component or method that exposes the debug ports for all servers (including remote servers running in the cloud) via a local (i.e. on premise) server.

Embodiments may enable an on-premise server to expose a set of debug ports that a graphical debugger can connect to and then debug all servers in the hybrid cloud system.

Such proposals can extend or improve the debugging capabilities, security and/or efficiency of hybrid cloud system.

To aid understanding of the proposed concept(s), a conventional approach to debugging a hybrid cloud system, in accordance with an embodiment of the present invention, will now be described with reference toFIG. 1. Here, a hybrid cloud system comprises off-premise resources70in the cloud72which are accessible to on-premise resources73via an Internet communication link74.

The off-premise resources70comprise an off-premise server75. The off-premise server75is a cloud-based server75and comprises an integration engine77(running one or more integration parts77A), a server module/agent78, and network ports79(exposed by the off-premise server75). Here, it is noted the network ports79will be exposed to the public internet and so any communications via these ports79may need to be secured (e.g. using HTTPS).

The off-premise resources70also comprise a switching component (i.e. connectivity component)80adapted to manage communication between the off-premise server75and the on-premise resources73. The switching/connectivity component80allows agents to connect from servers and send and receive requests from other integrations.

The on-premise resources73may comprise on-premises systems or private clouds.

The on-premise resources comprise an on-premise server90. The on-premise server is a local server90that is run and maintained by a user directly. Here, it is noted that the local server90can also be run in its own private cloud. The on-premise server90comprises an integration engine92(running one or more integration parts92A), a secure server module/agent94, and network ports95(exposed by the on-premise server90). The integration engine92is configured to run part of an integration. It can call other integrations within the local server90or it can call integrations running in remote servers like the off-premise server75(using the secure server module/agent94).

The network ports95exposed by the local server90include: HTTP/TCPIP server ports for calling integrations; a HTTP server port for administration; and a JVM debug port for debugging integrations in the integration engine. These ports can be secured with TLS and mutual authentication certificates.

The on-premise resources73also comprise a graphical debugger97. The graphical debugger97connects to JVM debug ports exposed from a server when debugging is enabled. Thus, to debug an integration in the off-premise server75, the JVM port79of the cloud-based server75must be exposed so that the debugger97has access to it. This requires both location details and security information (such as certificates).

In this conventional hybrid cloud system, debugging is exposed to all servers by exposing the JVM debug port on all servers so they are directly accessible to the graphical debugger97. Thus, the graphical debugger97accesses the JVM debug port of the off-premise server75and the on-premise server90as indicated by the arrows labeled “A”. This is difficult because it requires securing the off-premise ports79using mutual authentication and so requires a complex setup in order to keep debugging communications secure. It also quickly becomes unmanageable once the system is expanded to include numerous servers both off-premise70(e.g. in the cloud72) and on-premise73.

Proposed concepts address such problems by taking a different approach to debugging and leveraging secure connectivity that is available to allow integrations to call each other independently of where they are located. To aid understanding of the such proposed concepts, an exemplary embodiment for managing debugging across off-premise and on-premise several will now be described with reference toFIG. 2.

FIG. 2shows a modified version of the system ofFIG. 1, wherein there are some fundamental changes. In particular, the network ports component in the off-premise server75is no longer required in order to expose the off-premise server75to the graphical debugger97. Instead, it is proposed to implement a port forwarding capability in the switching/connectivity component80in order to expose a debug port via the on-premise server90. In this way, the graphical debugger97can establish and maintain a forwarded connection to the on-premise server90, thus effectively enabling the debugging of all servers in the system at the same time. For example, integrations can be moved between servers or from on-premises to off-premise (e.g. the cloud72) or vice versa with no changes needed to the debugger. The graphical debugger97will still connect to the local, on-premise server90, yet will be able to debug all other servers in debug mode. This may include tracing the flow of a message from one integration to the next, even when they are in separate locations.

Referring now toFIG. 2, the connectivity component80is shown in more detail.

The connectivity component80comprises: a data store140; a routing component150; a first communication component160; and a second communication component170. The data store140comprises a debug port data store adapted to store debug port data associated with debug ports that are provided by the off-premise resources70. By way of example, the debug port data may comprise information relating to port identifiers, port protocols, server identifications, server addresses, application version identifiers, permission information, authentication information, and checksum information. The debug port data may be provided to the data store140by servers or applications when they are made available by the off-premise resources70. For this purpose, the switching component80comprises a registration module175that is adapted to receive debug port data from at least one of: an application of an off-premise server; an application of an on-premise server; an off-premise server module; and an on-premise server module. The registration module175may be adapted to store received debug port data in the data store140, thus enabling the concept of registering information with the connectivity component80so that it may identify how to handle (e.g. where to communicate) a debug request. Also, the registration module175may be adapted to remove information from the data store140in response to an application, a server, a debug port and/or an application becoming inaccessible (e.g. being disconnected, terminated, or powered-down). A registering server or application may therefore register information to identify an application that it provides. This registered information can then be used to match a debug request for an application to a debug port of a server running the required application (e.g. integration).

Put another way, the data store140may be adapted to be dynamically updated or maintained in order to reflect changes in available applications or resources.

The data store140may therefore be thought of as providing a dynamically updated store of debug port information representing debug port that may be accessible. In this way, the connectivity component80may adapt to implementation specifics and cater for changes in available resources (e.g. applications, services and/or debug ports), for example for the registration/deregistration of debug port data to/from the data store140.

The first communication component160is adapted to receive a debug request from the on-premise server90(via the agent94). For this purpose, the first communication component160is adapted to establish a secure tunnel for receiving the debug request.

A debug request is a request to access or invoke a debug port provided by the off-premise resources70. By way of example, a debug request of this embodiment comprises an identification portion and a payload portion. The identification portion includes information relating to the identification of an application (such as an application name for example) or server (such as a server identifier or address for example). The payload portion comprises a data payload (such as a file location information (e.g. directory or path), a debug operation or instruction (e.g. read, write, delete, append, purge, edit, etc.) and data for use in/by the application or server for example).

Upon receiving a debug request, the first communication component160passes the received request to the routing component150. The routing component150is adapted to process the received request in conjunction with data stored in the data store140in order to identify a requested debug port of an off-premise server. By way of example, the routing component150is adapted to analyze the identification portion of the received debug request to identify the requested application or server (for example, based on an identifier included in the identification portion). Further, based on the identified requested application/server, the routing component150is then adapted to query the data store140to identify debug port data that is associated with the identified requested application/server.

The routing component150passes the received debug request to the second communication component170along with the identified debug port data associated with the identified requested application/server. The second communication component170is adapted to communicate the received debug request to the off-premise resources70based on the identified debug port data associated with the identified requested application/server. For this purpose, the second communication component170is adapted to establish a secure tunnel for communicating the debug request. For example, the second communication component170may establish a mutually authenticated TLS tunnel connection between the connectivity component80and the off-premise agent78.

In this way, the debug request is communicated over a port-forwarded connection to the off-premise server75. The connection is then maintained and used to communicate information between the off-premise server75and the graphical debugger97while an application of the off-premise server75is being debugged.

Thus, from the description above, the connectivity component80may be thought of as having first and second secure components for establishing tunnels with off-premise and on-premise server modules, respectively. The connectivity component80may also be thought of as including a registration component that is adapted to register and store (in a data store of the connectivity component80) debug port data (e.g., port identifiers, server IDs, server addresses, application version identifiers, supported applications, permitted applications, permission information, non-sensitive or public authentication information and checksum information) associated with applications or servers. Applications or servers may therefore register information with the connectivity component80when they connect and/or when a configuration changes. Such information may also be deregistered (e.g. removed or deleted from the data store) when an application, server or debug port becomes inaccessible (e.g. is disconnected, powered down or otherwise unavailable). Received calls (e.g. requests) to debug an off-premise resource may thus be analyzed by the connectivity component80and be used to query the dynamically maintained data store to identify debug port data indicative of where to communicate the debug event.

By way of example, and with reference toFIG. 3, an example of an on-premise graphical debugger97debugging integrations92A of the on-premise server90and integrations77A of the off-premise server75ofFIG. 1will now be described.

As indicated by the arrows labeled “B”, the graphical debugger97of the first server75communicates with the integration engine of the on-premise server90. The graphical debugger also communicates, via agent94of the on-premise server90and via the connectivity component80with the integration engine of the off-premise server75. This communication is established using: a first secure tunnel between the agent94of the on-premise server90and the first communication component160of the connectivity component80; and a second secure tunnel between the second communication component170of the connectivity component80and the agent78of the off-premise server75.

Here, the connectivity component80determines a debug port based on the received debug port request from the graphical debugger97. Based on the determined debug, the second communication component170communicates the debug request to the identified debug port of the off-premise server75.

Further, embodiments may also be adapted to enable the communication of a response to the debug request from the off-premise server75. By way of illustration, in the example depicted inFIG. 3, the second communication component170may be adapted to receive a response to the communicated debug request from the off-premise server. The routing component150may then determine the intended destination of the response (e.g. based on analysis of the response and/or stored data relating to previously communicated debug requests) and then pass the response to the first communication component160for communication to the originator of the debug request (via the on-premise server). In this way, a response to a debug request/call may be communicated back to the graphical debugger97that originated the debug request/call. Proposed embodiments may therefore provide for the management of debugging communication between off-premise and on-premise platforms so that debug requests and responses are securely delivered via a connectivity component (thus avoiding exposure via a public network for example). Put another way, the connectivity component80enables a port-forwarded connection to be established between the off-premise server75and the on-premise server90. The connection can then remain open while an application of the off-premise server75is being debugged.

Referring now toFIG. 4, there is depicted a flow diagram of a method300for managing debugging across off-premise and on-premise servers according to an embodiment. The method300ofFIG. 4is described as being implemented with a connectivity component (e.g. switching module) according to a proposed embodiment.

The method300begins with the step310within which a debug request is received by the connectivity component from an on-premise server. Here, the application request is received via a (previously) established secure tunnel. Also, the application request of this example may comprise a request to debug an application which comprises a header or identification portion and a payload portion. The header/identification portion may include information relating to the identification of the requested application (such as an application name for example), and the payload portion may comprise a data payload (such as data for use in debugging the application for example). The debug request may therefore comprise information relating to the application, an event (e.g. read, write, delete, append, purge, edit, etc.) to be completed by the application, an account or user requesting the event, data to be processed by the application, and/or and entry point in the application that the request would be made to. Inclusion of entry point data (such as path identification information, for example) in an application request may enable specification of an entry point in application that the debug request is made to. For example, an application called “application1” could have two entry points called “entry1” and “entry2”. The application request may then include the application name and the entry point within the application, such as “application1/path1” for example. If no entry point information is employed, a default entry point (e.g. start of application code) may be used.

Next, in step320, the received debug request is processed in conjunction with data stored in a data store of the connectivity component in order to determine a requested application. For example, the connectivity component analyzes the identification portion of the received application request to identify the requested application (for example, based on an application name included in the identification portion). The method then proceeds to step330, wherein, based on the identified requested application, the connectivity component queries the data store to identify debug port data that is associated with the identified requested application. In other words, based on the identified requested application, the connectivity component searches the data store to find a debug port for the requested application and then extracts debug port data that is stored in the data entry/record for the requested application.

In step340, the connectivity component then communicates the debug request to an off-premise resource based on the identified debug port data. For this purpose, an established secure tunnel is used to communicate the debug request to a component of the off-premise resource (via the debug port).

In step350, the debug request is received by the component of the off-premise resource.

Thus, from the above description of the method ofFIG. 4, it will be appreciated that a method of receiving a debug request and then communicating (e.g. forwarding) the modified request to an appropriate debug port. It should also be appreciated that the debug request, may or may not require a response to be provided (for example, back to the originator of the request).

Purely by way of further example, a possible approach to implementing the proposed concept(s) in a hybrid cloud system may comprise the following steps: (i) go to all integration servers wanted to be in debug mode and turn on (i.e. activate or enable) debugging; (ii) download a configuration file from the connectivity component and run a command that sets up a local (i.e. on-premise) integration server to expose all debug ports of the remote (i.e. off-premise) servers; and (iii) start the debugger pointing at all the local (i.e. on-premise) debug ports.

Modifications to this above approach may become even more streamlined with the graphical debugger automatically pulling down the configuration file and doing the setup phase for a user followed by automatically connecting to all local ports.

Embodiments described above have only included two integration servers: one off-premise and one on-premise. However, it will be appreciated that the proposed concept may be scaled to multiple integration servers both off-premise and on-premise. Also, the integration servers of the on-premise systems do not even have to be on the same network.

Proposed embodiments, such as those presented above with reference to their figures, may provide the benefit of enabling a debugging user to step through an off-premise resource (via an on-premise integration) as if it is running locally (i.e. in the on-premise resource(s) of the user). The user experience may thus be that he/she is debugging a local integration server although they are in fact debugging all enabled servers. This may allow for debugging integrations that comprise flows in more than one integration server and that are not collocated.

Further, proposed embodiments may also reduce an amount of private or sensitive debugging information (such as authentication information or security credentials) that passes between application in off-premise and on-premise platforms via a public network.

As will be apparent from the above description, an off-premise resource may be provided by a cloud-computing system. Also, a connectivity component or method for managing debugging communication between off-premise and on-premise platforms may be provided or implemented in a hybrid cloud-computing system.

With reference to the following description made with regard to a cloud computing system, it is understood in advance that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed. The following description of a cloud computing system and environment is made purely for the purposes of explanation and understanding.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provide computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service's provider.

Service Models are as follows:

Deployment Models are as follows:

Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds). A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes.