in the following description , the well - known sap system offered by sap ag is used as an example of an erp system . however , it is well understood that the present disclosure and the implementation details described in the following can also be applied to other erp or similar data processing systems . in a sap system , a client application has a dependency to one or more sap background processing events . those events with their status information may be queried from external ( non - sap ) applications using an rfc layer and by calling appropriate sap function modules in the sap system . the status information may be gathered using a polling mechanism and returned to the client in synchronous calls from the event history table . the event history table can be accessed or queried through a db layer which is arranged between the sap system and the event history table . inside an erp platform , such as an sap net weaver basis within the well - known ‘ sap r / 3 ’ ( registered trademark by sap ag ) platform , background processing events may be generated on specific situations inside the erp system and may be related to business and non - business activities . such events may be generated automatically by the erp system or triggered by erp users . in particular , those events can be used to connect workflow inside the erp system to external applications . such an sap event , from a technological perspective , may be a flag that is created in the sap system . this flag can be triggered within sap r / 3 by an r / 3 kernel , by a user using the sap r / 3 user interface , or it can be triggered even at the operating system level . the external application may access an event history table of the erp system via a dedicated interface . this interface may allow an rfc to access or query the event history table , but the access may be performed in the mentioned ‘ polling mode ’ which requires a continuous checking of the event history table by the external application to obtain the current state of the event history table . this continuous checking is commonly achieved by sending messages to the event history table asking whether it has anything to communicate or not . the ‘ advanced business application programming ’ ( abap ) language is the report language for the sap r / 3 platform which enables building of mainframe business applications for materials management and financial and management accounting . abap was one of the first programming languages to include the concept of logical databases ( ldbs ), which provides a high level of abstraction from the basic database level , and was originally used by sap developers to develop the sap r / 3 platform . but abap was also intended to be used by users of the sap system to enhance sap applications so that customers can develop custom reports and interfaces with abap programming . in sap r / 3 , all abap programs reside inside a dedicated sap database i . e . they are not stored in separate external files like java or c −+ programs . in that database , abap code exists in two forms , namely a source code that can be viewed and edited with an abap workbench and a “ compiled ” code that is loaded and interpreted by an abap runtime system . abap programs may run on an sap application server , under control of the above - mentioned runtime system , wherein the sap application server is part of an sap kernel . the runtime system is responsible for processing abap statements , controlling the flow logic of screens and responding to events , such as a user pushing a screen button . a key component of the abap runtime system is the database interface , which turns database - independent abap statements (“ open sql ”) into statements understood by the underlying dbms (“ native sql ”). the database interface handles all the communication with the relational database on behalf of abap programs : it also contains extra features such as buffering of frequently accessed data in the local memory of the application server . in addition , the erp platform may comprise a remote function call ( rfc ) which is an application program interface to the mentioned r / 3 applications . a remote function call ( rfc ) is the call of a function module that runs in a system external to the calling program . although it is also possible to call a function module in the same system as an rfc , normally rfcs are used when the caller and the called function module do not run in the same system . in the sap system , these functions are provided by a rfc interface system . the rfc interface system enables function calls between two sap systems , or , between the sap system and the external application . sap customers who wish to write other applications that communicate with r / 3 applications and databases can use the rfc interface to do so . regarding the above mentioned polling mechanism , the external client application may wait for erp events by way of a loop which starts after an entry by the user and may be exited by the user also . the external application may poll the sap event history table periodically using a checkevent ( ) command . between such polling events , the loop is in a sleep ( ) mode . the underlying communication ( interaction ) protocol of the pre - described polling mechanism is now described . the client application may send a query to an rfc client which is implemented , for example , at the external application ( client - side ). the rfc client transmits the query using the known tcp / ip transmission protocol , for example , to an rfc server which is implemented at or near the erp system . the rfc server may then transmit the query to the event history table . having read the event history table , the resulting information is first transmitted to the rfc server and from the rfc server to the rfc client again using tcp / ip transmission protocol . finally , the rfc client provides the resulting information to the client application . fig1 shows an embodiment of the present invention . a client application 100 may start an rfc server 200 to be able to receive callback events from external applications like applications running on the present sap system 101 . following this activity , an sap backend callback mechanism with a callback registry 201 may be initialized . triggered from the client application 100 , the callback registry 201 may verify the event history table 102 to query for existing sap background processing events . if corresponding events are present , the function may stop here and the client can shut down the callback rfc server 200 . if no events are present , the callback registry may invoke an event listener 202 which may create and initialize an sap background processing job 104 with a start condition ‘ after event ’. the callback registry may further assign event data and related parameters to the background processing job 104 . additionally , the callback information being received from the client applications rfc server may be stored in the callback registry table 203 . the job may be released after this activity to listen on sap background processing events . after the initialization on the sap backend is finished , the call returns to the client application . in one embodiment , upon an sap background processing event being raised , the corresponding job 104 starts execution . the job may run an associated abap report in order to read the callback registry 201 and to notify all registered client &# 39 ; s rfc callback servers 200 to listen to the corresponding sap background processing event . this notification wakes the client , which continues its processing without using a polling mechanism . as illustrated in fig2 , in an embodiment , an rfc server is implemented in the client application wherein the rfc server waits on callback notifications from sap . in one embodiment , those notifications are sent by additional code in the sap system whenever a specific sap event was generated or thrown inside sap . to do so , the client application ( which is interested in a specific sap event ) may run a dynamic allocated abap program which registers itself in a new sap table , storing the client &# 39 ; s callback information . after this , a standard sap job may be created for use as a placeholder job . the job may have a start condition ‘ after event ’, waiting on the event to be thrown . additionally , the event history may be taken into account . if no event with the requested id is available in the history table , the client application may wait on the rfc callback . if the event is thrown inside sap , the placeholder job is released , reads the callback registration table and notifies the listeners ( the external clients implementing the rfc server ). now the external client application wakes up and continues its processing . now referring to fig2 , one embodiment of a process flow of the erp system is described . an external client application 15 may be launched to interact with an sap backend system , listening on sap background processing events . it may initialize its main thread 50 and is then ready to receive requests 48 to query for named sap background processing events . once a request 48 arrives , an rfc server start sequence 52 may be executed . this sequence may launch the rfc server 76 and initialize a common shared object in waiting state 54 . once the initialization has finished , the client application 15 may invoke the rfc layer and call on the sap backend system 10 the remote rfc layer 30 ′ to run an abap program 60 . the abap program 60 may register 62 itself in a callback registry , storing the callback information provided by the client application 15 of its rfc server 76 . after registration , the event history table 20 may be queried 74 for the named sap background processing event . if a corresponding event record is available in the event history table 20 , the abap report 60 may return to the client applications main thread 50 . the rfc server 76 may stop and the client application 15 may inform its caller that the event was raised 80 . if no event record is available in the event history table 20 the abap program 60 may create a job 66 with start condition ‘ after event ’ and release the job . the job may get an abap report assigned which is executed when the job runs . the abap report 60 may return to the client application &# 39 ; s main thread 50 and wait until the rfc server 76 is notified from the sap system , such as , for example , through calling the rfc servers 76 callback function 74 . once an sap background processing event is raised 68 in the sap system 10 , the previously released job 66 runs and executes the assigned abap program 64 , which may read 72 the callback registry load the connection data of all registered rfc servers 76 and perform the callback operation 70 via the rfc layer 30 ′ to the client &# 39 ; s rfc layer . the abap program may invoke the rfc server callback routine 74 . the rfc server 76 may notify 78 the client applications 15 common shared object . this informs 80 the caller that the event was raised . client applications can listen on rfc server notifications whenever a specific erp event is raised . external enterprise schedulers ( such as tivoli workload scheduler for applications ), reduce workload and network traffic and allow ad hoc actions based on sap events . the above described process flow illustrated in fig2 can be summarized by the following process steps which are also shown in fig2 : 0 ) check for event 1 ) start rfc server 2 ) wait 3 ) check 4 ) run 5 ) register 6 ) read history 7 ) create job 8 ) release job 9 ) read registry 10 ) callback rfc 10 . 1 ) callback 10 . 2 ) callback 11 ) notify 12 ) event released fig3 illustrates the underlying communication ( interaction ) protocol of the above described methodology according to an embodiment of the present invention . the client application 100 may send a ‘ start ’ command to the rfc server 200 in order to start the server . the rfc server 200 , as a default , waits for incoming rfc calls . next , the client application 100 may send a ‘ query ’ call to the local rfc layer . this query call may be forwarded to the callback registry 201 which may invoke a ‘ query ’ call on the event history 102 . if no event record is found in the event history table , the callback registry may call the event listener 202 to create a placeholder job . the event listener 202 creates and releases a job 104 and returns to the caller . the client application 100 may then go into a wait state by calling the rfc servers ‘ wait ’ method . once a sap event is raised , the job 104 runs its assigned code , which calls the callback registries ‘ read ’ method to load the registered clients callback addresses . each registered client rfc server 200 is notified and the client application 100 continues its processing . embodiments of the present invention can be realized in hardware , software , or a combination of hardware and software . any kind of computer system may be used . a typical combination of hardware and software could be a general - purpose computer system with a computer program that , when loaded and executed , controls the computer system such that it carries out the methods described herein . embodiments of the present invention can also be a computer program product , disposed upon a computer - readable medium , comprising computer program instructions , which comprises all the features enabling the implementation of the methods described herein and which , when loaded in a computer system , is able to carry out these methods . computer program in the present context mean any expression , in any language , code or notation , of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a ) conversion to another language , code or notation ; b ) reproduction in a different material form . it should be understood that the inventive concepts disclosed herein are capable of many modifications . to the extent such modifications fall within the scope of the appended claims and their equivalents , they are intended to be covered by this patent .