The NetWeaver web service wizard uses Remote Function Calls (RFC) to create web services. If the function module interface changes, then the web service must be regenerated.
In principle, function calls have been superseded by ABAP classes, because they are funtionally equivalent to static methods. I am sure it is only a matter of time before static methods can be remote enabled, and the web service wizard references them as end-points too. When this happens, RFCs will be truly redundant.
In the mean time, developers should future-proof custom services by building any logic into classes and only using remote function calls as a facade to enable external communication.
This approach will be used for the ZOA Community Project, which is all about creating a light but powerful framework for SAP integration. The logic for different business objects and methods will be built in classes. Remote function calls will be created as facades to instantiate and call the relevant methods on those classes.
There are a number of benefits with this approach, compared to building the logic directly into the RFCs:
- Decoupling between RFC interfaces and underlying classes, so either can be customised independently
- Ability to create multiple interfaces to the same service without redundancy – e.g. ZOA can have generalised interfaces (as used in BAPI_ALM_ORDER_MAINTAIN) and explicit interfaces (as used in BAPI_PO_CHANGE)
- Support for remote enabled static method calls if these are implemented in future
- Minimise feature-specific DDIC objects in the classes themselves – so the classes can be dynamic and defined DDIC structures can stay in the function modules and interfaces, making it easier and safer to maintain
In summary, if you are building any kind of interface, including user interfaces in web dynpro and workflow in WF, the interface logic should be decoupled from the business logic by encapsulating all business logic in its own ABAP classes.