The CRfcServerApp Class encapsulates the initialization, running and termination of an RFC server application. (Running consists of listening for requests from R/3 and dispatching them to corresponding functions). An application built with the framework provided by the class library must have exactly one object of the CRfcServerApp class. We refer to this as the "application object."

The application object keeps a pointer list of objects of classes derived from CRfcServerFunc, which we refer to as "server function objects". These server function objects, in turn, are known as the user server functions. User server functions are user-defined, application-specific functions to be called from R/3. The user implements these functions as CRfcServerFunc classes (see How the CRfcServerFunc Class Works) and registers them with the CRfcServerApp object during runtime.

The application object’s Run member function contains the main loop for server applications. In the loop, as a regular process for server programs, it keeps listening for incoming requests from R/3. Upon getting a request, the Run member function calls the C API to look for a matching function in the server function list. Run then locates the server function object by calling its ReceiveData, Process(), and ReturnCall member functions one after the other and asks the C API to dispatch processing to the server function object. After each request is processed, Run goes back to the listening mode, ready for the next request until the other end indicates intent for termination.

When you design and implement the derived classes of CRfcServerFunc, you are freed from the need to concern yourself with retrieving data sent from R/3 and with sending data back after processing. Instead, you can concentrate on the function processing logic: Once inside the Process method, all data sent by R/3 is already stored in the appropriate parameter objects in C++ format, so functional data processing can start right away. When you exit the Process method, all appropriate data is automatically sent back to R/3. All this automation is done by the application object.

The application object’s OnIdle member function can be overridden by the user who wishes to do some optional side work between requests. OnIdle is called in the main loop of Run while Run waits for requests. If you do not intend to override OnIdle, you can use the CRfcServerApp class without modification.