The following sections describe some points to remember when you write a remote function module.

For normal (non-remote) function modules, if a parameter is not defined like an ABAP Dictionary field, it takes the data type of the actual parameter used at run-time.

A remote function module, however, does not have this information available. As a result, all parameter fields for a remote function module must be defined as reference fields, that is, like ABAP Dictionary fields. (This includes IMPORTING, EXPORTING, and TABLES parameters.)

For character structures or fields, the caller's parameters need not be as long as expected by the called program. When incoming parameters are shorter, RFC simply pads them with blanks. This means that the ABAP Dictionary definition of character parameters need not be exactly the same on the calling and called sides. (However, the caller's parameters may not be longer than expected on the called side).

• Transactional calls cannot return parameter values. As a result, the interface for these functions should not specify any EXPORT parameters.
• Functions that run transactionally may not perform call-backs: the caller's context does not necessarily still exist when the call-back is relayed back to the original system.

You can raise exceptions in a remote function just as you would in a locally called function.

Since the system raises COMMUNICATION_FAILURE and SYSTEM_FAILURE internally, there is no reason for you to raise them in your program. The MESSAGE keyword is only meaningful in relation to these system exceptions, so you need not program them into your function.

A remote function can call other remote functions, just like an ordinary function module.

In particular, it can use the call-back feature to call function modules running in the system of the original caller.