Reliable message transfer

Various embodiments of systems and methods for reliable message transfer are described herein. In a sender adapter, at least one message is divided into a plurality of message chunks based on a predetermined chunk size. A chunk key is assigned to each of the message chunk to correspond to each message. Further, a chunk sequence key is generated for each of the message chunks to identify a sequence of the message chunks. The plurality of message chunks including the corresponding chunk key and the chunk sequence key is transmitted to a receiver adapter. At the receiver adapter, the plurality of message chunks including the corresponding chunk key and the chunk sequence key are received. Further, the message chunks are grouped based on the corresponding chunk key and each message is reconstructed from the message chunks based on the corresponding chunk sequence key.

FIELD

Embodiments generally relate to computer systems and more particularly to methods and systems for reliable message transfer.

BACKGROUND

In an enterprise, communication system plays a vital role for transferring data from one point to another. Enterprise, which involves typical business processes span across different business systems. Also, some processes even span across the boundaries of the enterprise to communicate to a third party system. These processes include exchange of electronic documents. In order to establish such inter and intra enterprise business processes, infrastructure is provided for a messaging system, which includes a set of techniques for exchange of electronic documents among multiple threads in one or more processes. For example, NetWeaver Process Integration (PI) of SAP® provides such an infrastructure. However, the current infrastructure has one or more limitations as described below.

Currently, reliable message transfer is limited to an available memory heap size when processed. If a message having a message size that exceeds the memory heap size is being transferred, the messaging system will throw an error and the message transmission will not be achieved. Therefore, the message heap size must be as big as the maximum message size during processing of the message, which is resource intensive. For example, for every single message, an upper limit of the message size has to be defined for transferring each message. Also, reliability in such message transfer may not be guaranteed. In other words, if the transfer breaks down, the process of transferring has to be commenced from the beginning.

Therefore, a technique for overcoming the above mentioned limitations by providing reliable transfer of messages without having a size limit would be desirable.

SUMMARY

Various embodiments of systems and methods for reliable message transfer by processing messages without having a size limit are described herein. In a sender adapter, at least one message is divided into a plurality of message chunks based on a predetermined chunk size. A chunk key is assigned to the plurality of message chunks which correspond to each message. Further, a chunk sequence key is generated for each of the plurality of message chunks to identify a sequence of the plurality of message chunks in each message based on the assigned chunk key. The plurality of message chunks including the corresponding chunk key and the chunk sequence key are transmitted to a receiver adapter. In one embodiment, each of the plurality of message chunks comprises an electronic envelope including a header and a body. The header of the electronic envelope is dynamically configured to comprise a sender ID, a receiver ID, a time stamp, the chunk key, the chunk sequence key, the chunk size and a chunk mode, and the body of the electronic envelope comprises a part of payload data of the at least one message based on the predetermined chunk size.

At the receiver adapter, the plurality of message chunks including the corresponding chunk key and the chunk sequence key are received. Further, the plurality of message chunks are grouped based on the corresponding chunk key and the message is reconstructed from the plurality of message chunks based on the corresponding chunk sequence key.

These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.

DETAILED DESCRIPTION

Embodiments of techniques for reliable message transfer by processing messages without having a size limit are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

FIG. 1is a flow diagram100illustrating a method of processing at least one message by a sender adapter, according to an embodiment. At step110, at least one message is divided into a plurality of message chunks based on a predetermined chunk size. In one embodiment, large size messages or messages without size limits can be transferred by dividing the message into the plurality of message chunks. In these embodiments, the messages can be transmitted without changing the heap size parameters or overloading the heap of memory of the sender adapter. In one exemplary embodiment, a message can include an electronic document of a business application without message size limit in form of an extensible markup language (XML), a non-XML, a web service description language (WSDL), a semi or unstructured document, a simple object access protocol (SOAP) and the like. In one embodiment, the predetermined chunk size is configured based on the processing capability of the sender adapter.

At step120, a chunk key is assigned to the plurality of message chunks to correspond to each message. For example, the message chunks associated with a message are assigned with a common chunk key. In other words, the chunk key is used to identify the message from which the message chunks are generated. At step130, a chunk sequence key is generated for each of the plurality of message chunks to identify a sequence of the plurality of message chunks in each message based on the assigned chunk key. For example, if a message is divided into five message chunks, then the chunk sequence key is generated for each of the five message chunks, which helps to reconstruct the message at a receiver adapter.

At step140, the plurality of message chunks including the corresponding chunk key and the chunk sequence key are transmitted to the receiver adapter. In an embodiment, each message chunk includes an electronic envelope. The electronic envelope includes a header and a body. The header of the electronic envelope is dynamically configured to include a sender ID, a receiver ID, a time stamp, the chunk key, the chunk sequence key, the chunk size and a chunk mode, and the body of the electronic envelope includes a part of payload data of the message based on the predetermined chunk size. In one embodiment, the chunk mode includes an end mode to identify a last chunk message of the plurality of chunk messages and an active mode to identify other chunk messages of the plurality of chunk messages. The structure of the electronic envelope is described in greater detail inFIG. 3.

FIG. 2is a flow diagram200illustrating a method of reconstructing the at least one message ofFIG. 1in a receiver adapter, according to an embodiment. At step210, the plurality of message chunks including the corresponding chunk key and the chunk sequence key are received by the receiver adapter. At step220, the plurality of message chunks are grouped based on the corresponding chunk key. In one exemplary embodiment, a temporary file is created in the receiver adapter to store the grouped plurality of message chunks. At step230, the at least one message ofFIG. 1is reconstructed from the grouped plurality of message chunks based on the corresponding chunk sequence key. The method as described inFIGS. 1 and 2are described in greater detail with an exemplary system inFIG. 3.

FIG. 3is an exemplary architecture of a system300for reliable message transfer, according to an embodiment. In one exemplary implementation, the system diagram300shows a schematic architecture of an advanced adapter engine (AAE)305. The AAE305includes a sender adapter335coupled to one or more senders (e.g., senders310and350) to transfer messages (e.g., messages315,320and325) to a dedicated receiver (e.g., receiver330). The AAE305further includes a receiver adapter345to receive the transferred messages through a messaging system340. The messaging system340manages the messages database persistency and schedule of the message processing worker threads. In other words, the messaging system340communicatively couples the sender adapter335and the receiver adapter345via a network. Further, the receiver adapter345is coupled to one or more receivers (e.g., receiver330) to deliver the messages (e.g., messages315,320and325), which are transferred from the sender adapter335. In one exemplary embodiment, the sender (e.g., senders310and350) and the receiver (e.g., receiver330) refers to a computer, a third party system, external application, application storage, other mechanism or actors capable of sending and receiving the messages.

In operation, one or more messages (e.g.,315,320and325) are transferred from the one or more senders (e.g., messages315and320are transferred from the sender310, and message325is transferred from the sender350) to deliver to the dedicated receiver (e.g., receiver330) through AAE305. In one embodiment, the sender adapter335divides each message (e.g., message315,320and325) into a plurality of message chunks (e.g., message315is divided into message chunks315A,315B and315C, message320is divided into message chunks320A,320B and320C, and message325is divided into message chunks325A,325B and325C). The messaging system340is protocol agnostic, therefore each message chunk (e.g., message chunks315A to315C,320A to320C, and325A to325C) includes an electronic envelope consisting of a header and a body. In one embodiment, the header is dynamically configured to include a chunk key, a chunk sequence key, a chunk mode, and a chunk size. The dynamic configuration of the header is described in greater detail inFIG. 4. In one exemplary embodiment, the plurality of message chunks is persisted within the messaging system340. Thus, the message chunks can be read successfully to the messaging system340even if the receiver adapter345is not available.

Further in operation at the receiver adapter345, the plurality of message chunks (e.g., message chunks315A to315C,320A to320C, and325A to325C) are grouped according to the associated chunk key. In one exemplary embodiment, a temporary file is created to store the plurality of message chunks corresponding to each message based on the associated chunk key (e.g., message chunks315A to315B are grouped together; message chunks320A to320C are grouped together; and message chunks325A to325C are grouped together). Further, the grouped plurality of message chunks are arranged in a sequence as per the associated chunk sequence key to reconstruct each message (e.g., messages315,320and325) as transmitted from the senders (e.g., senders310and350). In one embodiment, when the connectivity between the sender adapter335and the receiver adapter345is temporarily lost, no message chunks are lost or duplicated. The message chunks which are not transmitted will be transferred to the receiver adapter345, than transmitting the whole message as in conventional system when the connection is established. Thus, reliability of message transfer is achieved. Also, occurrence of errors is optimized as only message chunks are transferred.

FIG. 4illustrates a protocol structure400of a message chunk, according to an embodiment. In one embodiment, the message chunk is represented as an electronic envelope, including a header410and a body420. In one embodiment, the header410is dynamically configured to include a sender ID430, a receiver ID440, a time stamp450, a chunk key460, a chunk sequence key470, a chunk mode480, and a chunk size490. The sender ID430provides information of a source of a message or a sender. The receiver ID440provides information of a destination where the message is to be transferred or a receiver. The time stamp450includes time at which the message is transferred.

In one embodiment, the chunk key460provides information of the message from which each of the plurality of message chunks are generated. The chunk key460helps to group the plurality of message chunks at a receiver adapter. For example, the chunk key for each message chunk associated with a particular message includes a common alphanumeric code. In one embodiment, the chunk sequence key470provides information to identify a sequence of the plurality of message chunks in each message. The chunk sequence key470helps to reconstruct the message from the plurality of message chunks in a correct sequence. The chunk mode480includes an end mode to identify a last chunk message of the plurality of chunk messages and an active mode to identify other chunk messages of the plurality of chunk messages. In other words, the last chunk message includes chunk mode480as ‘end’ and the other chunk messages include chunk mode480as ‘active’, which helps the receiver adapter to know the end of the plurality of chunk messages. In one embodiment, the chunk size490depicts the size of the message payload as in the body420of the electronic envelope. In general, the message protocol is enhanced with parameters that allow dividing messages at the sender adapter and reconstructing the same messages at the receiver adapter. In one embodiment, the dynamically configured parameters are defined on top of a current message protocol. Thus, monitoring and runtime infrastructure of a conventional infrastructure is completely utilized. An example of the header410is described in greater detail inFIG. 5A to 5C.

FIGS. 5A to 5Cillustrate exemplary headers (e.g.,500A,500B, and500C) of a plurality of message chunks of a message, according to an embodiment. A message which has to be transferred to a dedicated receiver is divided into the plurality of message chunks at a sender adapter. The header of the plurality of message chunks is dynamically configured to include a chunk sequence key, a chunk size, a chunk mode, and a chunk key.FIG. 5Ais an exemplary header500A of a first message chunk of the plurality of message chunks,FIG. 5Bis an exemplary header500B of a last but one message chunk of the plurality of message chunks, andFIG. 5Cis an exemplary header500C of a last message chunk of the plurality of message chunks. In one embodiment, a chunk start key or a chunk sequence key (e.g.,510A ofFIG. 5A,510B ofFIG. 5B, and510C ofFIG. 5C) for each message chunk is defined, wherein each chunk sequence key is assigned an alphanumerical value to identify the sequence of the plurality of message chunks of each message. For example, the numerical value ‘0’ denotes that the message chunk is the first message chunk of the plurality of message chunks as in510A ofFIG. 5A. The numerical values ‘498073600’ and ‘503316480’ denote the order in which the message chunks has to be placed during reconstruction of the message at the receiver adapter as in510B and510C ofFIGS. 5B and 5Crespectively.

In one embodiment, a chunk size (e.g.,520A ofFIG. 5A,520B ofFIG. 5B, and520C ofFIG. 5C) provides a size of the payload of each chunk message of the message. For example, the chunk size520A ‘5242880’ is the payload size of the first message chunk as inFIG. 5A. The chunk size520B ‘5242880’ is the payload size of the last but one message chunk as inFIG. 5B. Further, the chunk size ‘4715564’ is the payload size of the last message chunk as inFIG. 5C. In general, each message chunk includes the message payload of same chunk size as configured in the sender adapter (e.g.,520A and520B) except for the last message chunk, which includes the message payload of the chunk size as configured or less than the configured chunk size (e.g.,520C).

In one embodiment, the chunk mode (e.g.,530A ofFIG. 5A,530B ofFIG. 5B, and530C ofFIG. 5C) is defined, wherein the chunk mode provides information whether a message chunk is the last message chunk of the plurality of message chunks of the message. For example, the chunk modes530A and530B depicts as ‘active’, indicating the message chunk is not the last message chunk of the plurality of message chunks. Further, the chunk mode530C depicts as ‘end’, indicating the message chunk as the last message chunk of the plurality of message chunks.

In one embodiment, a chunk key (e.g.,540A ofFIG. 5A,540B ofFIG. 5B, and540C ofFIG. 5C) is defined, wherein the chunk key is assigned an alphanumerical value. The numerical value ‘235233266’ denotes that the message chunk belongs to a particular message. Since the plurality of message chunks as depicted (only headers) inFIGS. 5A to 5Cbelongs to the same message, all chunk keys (e.g.,510A ofFIG. 5A,510B ofFIG. 5B, and510C ofFIG. 5C) are assigned a common unique number.

FIG. 6is a block diagram of an exemplary computer system600. The computer system600includes a processor605that executes software instructions or code stored on a computer readable storage medium655to perform the above-illustrated methods of the invention. The computer system600includes a media reader640to read the instructions from the computer readable storage medium655and store the instructions in storage610or in random access memory (RAM)615. The storage610provides a large space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM615. The processor605reads instructions from the RAM615and performs actions as instructed. According to one embodiment of the invention, the computer system600further includes an output device625(e.g., a display) to provide at least some of the results of the execution as output including, but not limited to, visual information to users and an input device630to provide a user or another device with means for entering data and/or otherwise interact with the computer system600. Each of these output devices625and input devices630could be joined by one or more additional peripherals to further expand the capabilities of the computer system600. A network communicator635may be provided to connect the computer system600to a network650and in turn to other devices connected to the network650including other clients, servers, data stores, and interfaces, for instance. The modules of the computer system600are interconnected via a bus645. Computer system600includes a data source interface620to access data source660. The data source660can be accessed via one or more abstraction layers implemented in hardware or software. For example, the data source660may be accessed by network650. In some embodiments the data source660may be accessed via an abstraction layer, such as, a semantic layer.

In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details to avoid obscuring aspects of the invention.

Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.

The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.