Recently, I gave a Web seminar at SearchSAP.com detailing how to use the JCO API to build an outbound RFC server for SAP. Using a JCO server, you connect to external Java-based applications from inside any ABAP application. This technology provides a powerful and flexible means of extending your existing SAP implementation without a lot of costly adapters or long development cycles.
One of the most common questions I received after the seminar was "What the heck is a custom repository and why do I care about it?" This is a fair question and is one of the more confusing aspects of JCO server development.
Anyone familiar with building inbound connections to SAP with JCO knows that you must first retrieve a repository from SAP to get the metadata definition of the BAPI/RFC you wish to call. This repository contains all the structure/parameter definitions for RFC-enabled function modules in SAP. Obviously, for inbound calls, you need to use a repository to get back the function definition, otherwise you would be stuck using the JCO API to define these structures up-front, before even making the initial RFC/BAPI call.
However, building a JCO server is the reverse proposition. Rather than using a function module defined in SAP, you effectively define your own Java-based function module. Although not exactly parallel with SAP function modules, a JCO function relies on the same paradigm used by SAP, e.g. import/export parameters, structures, and tables. As such, you can define your JCO module as a shell RFC in SAP (defining parameters, etc. without any logic in the function), then use the SAP repository to retrieve the function definition on JCO server startup.
This process has two major drawbacks:
1) Repository overhead - Although slight, an SAP repository does occupy a certain amount of memory space when it is retrieved from SAP. When building a J...
To continue reading for free, register below or login
To read more you must become a member of SearchSAP.com
CO server, it is somewhat overkill to pull out the entire set of metadata definitions, when all you really need is a shell RFC interface that you defined in the first place.
2) Division of labor - As a Java developer, you may require more finite control over your JCO defined interfaces. Defining shell RFC interfaces forces you to update SAP anytime your Java function changes, including the appropriate transports, etc. to support these changes.
A custom JCO repository gives you better control over the interface definitions and reduces overhead on your JVM/Java application server. A custom repository contains only those interface(s) that are required by your JCO server. Instead of further explanation, here is an example of a custom repository:
This repository defines a very basic interface with import/export parameters and a structure definition for a table interface.
A custom JCO repository definitely gives you, as a Java developer, more control in the development effort. It can be included within your Javadoc generation in order to better document the development effort and can be updated to reflect the dynamic nature of Java development. Of course, the major disadvantage is that your ABAP developers would need to read the generated Javadocs when calling your JCO server from within SAP. However, I have always found it easier to deploy a development Web server with the appropriate Javadocs available to all developers than force my Java developers to log into SAP every time they needed to check/update and RFC interface definition.
Author Austin Sincock is a freelance Java/SAP consultant who contributes regularly to Web and print journals. He can be reached at austin@opensourceguru.com. Check out his book Enterprise Java for SAP
