If you have done any serious BAPI programming, you are aware that BAPIs
mostly use the internal representation of codes. One of the more
famous examples is units of measurement: A SAPGUI user logged on in English
will type PC (piece) as a unit while the BAPIs use the internal (German)
representation ST. Another example is customer numbers. A customer number
can contain letters, but if it consists of digits only, it is internally
stored with leading zeroes. The user wants to neither see nor have to
enter these leading zeroes.
SAPGUI automatically performs the necessary
conversions so that its users always see the external representation.
This is possible since for each Domain¹ in the SAP Data Dictionary
a conversion exit can be defined if appropriate. This exit is called
both inbound and outbound. Data originating in the application is converted
from the internal to the external format; data entered by the user is
first validated and then converted from the external to the internal format.
The fact that, in SAPGUI, the conversion
exits are always called automatically has been a source of confusion for
many developers who wanted to try out a BAPI in SAP's Function Builder
(transaction code SE37) in order to learn more about the BAPI's parameters.
If you run the SalesOrder.CreateFromDat1 BAPI inside R/3, for
example, and enter the document (sales order) type as OR (for a standard
order), all works well. If, on the other hand, you use the same code from
outside of SAP, you will receive an error message telling you that you
have used an invalid code.
This is due to the fact that even the
very technical test environment of the Function Builder uses the conversion
exits. But the BAPI itself does not invoke them. Many developers in this
situation end up hard-coding the German equivalent of OR (TA) in their
programs. That may be acceptable for a quick-and-dirty demo program, but
software for production use should avoid hard-coding constants that are
subject to SAP customization. Also, conversions are required for many
other parameters, and it would definitely be better to have a generic
Fortunately, there are special BAPIs available
in SAP (since 4.0) that allow us to invoke the required conversion exits.
These BAPIs are methods of object type BapiService. There is one BAPI
for the conversion from external to internal (DataConversionExt2Int)
and one for the conversion from internal to external (DataConversionInt2Ext).
Improved versions (the names of which end with "1") have been added in
recent releases. The conversion BAPIs call the same conversion exits used
Conversion Exits Considered Harmful
In this article I want to draw your attention to a potential problem
when using the conversion BAPIs: It is possible that calling a conversion
exit with "bad" data can cause the connection to R/3 to be terminated.
I encountered this issue when developing
a component that encapsulates (amongst other areas) access to the conversion
BAPIs. To be able to test my component with different SAP releases without
having to write specific test code, I made the component self-testing,
i.e., I wrote a method that tries out every conversion exit referenced
by any BAPI parameter in a particular release. Then, to make sure that
the component would work properly if the client program tried to convert
inappropriate data (e.g., a unit of measurement not defined in SAP), I
called each conversion exit with data that should never work.
Running this self-test method for the
first time, I got more error messages than I had expected. Only the first
few exits seemed to be called correctly, everything after that failed.
When I investigated the reason for this behavior, I found that some conversion
exits, when passed data they did not like, tried to write an "A" (as in
"Abort") message to SAPGUI. This is, of course, inappropriate behavior
inside a BAPI, since a BAPI-enabled application usually does not have
SAPGUI enabled. The RFC layer reacts by terminating the session with R/3,
which explains why further calls after the first failed conversion did
The conversion exits should not be blamed
for this. After all, they were written to be part of SAPGUI and expect
to be called only with valid data, since SAPGUI calls the validation first
and only invokes the exit when the entered data has passed the validation.
What should happen is that the conversion BAPIs try to catch the error
messages by the conversion exits and convert them into normal return codes.
SAP to the Rescue
I informed SAP about the problem and sent them the list of all "dangerous"
conversion exits used in BAPI parameters in the various releases (see
Figure 1). SAP reacted quickly by improving the conversion BAPIs
(see OSS Note 215418). If you are using the conversion BAPIs in your own
applications, it is highly recommended that you update the conversion
BAPIs by applying the support packages listed in the OSS Note (applicable
to releases 4.0B through 4.6C). Otherwise, you may experience intermittent
application problems that could be hard to fix, unless you already have
heard about the issue and the user remembers exactly what data was entered
into the application.
Conversion Exit Name
Used Since Release
||"Dangerous" Conversion Exits Used in BAPI