Overview of required API methods
The following table should provide a brief overview of which API functions need to be implemented to achieve a certain amount of external functionality.
|
Requirement |
Datahandler |
get_DataObjects |
get_MetaInfo |
get_List |
get_Detail |
modify |
delete |
update_temp_key |
|---|---|---|---|---|---|---|---|---|
|
Display internal tables |
GENERIC_VIEW |
O |
X |
X |
||||
|
Search help function |
GENERIC_VIEW |
O |
X |
X |
||||
|
Functional calls |
GENERIC_FUNCTION |
X |
||||||
|
Trigger function with data storage in the external system |
GENERIC_FUNCTION |
X |
||||||
|
Data modelling externally, data storage in SAP |
GENERIC_STORE |
X |
X |
X |
X |
X |
||
|
Trigger function with data storage in SAP |
DEVELOPER_API |
O |
X |
X |
X |
O |
||
|
Make SAP business objects (e.g. Customer) available |
DEVELOPER_API |
O |
X |
X |
X |
O |
Inherited attributes of the root object
The following table contains attributes that are defined during the instancing of the processing modules. These can be used within the API methods.
|
Attribute |
Use |
More information |
|---|---|---|
|
CURRENT_API_FUNCTION |
Currently called function of the RFC API |
|
|
CURRENT_LOG_GUID |
GUID within the LOG table |
|
|
CUST_GLOBAL |
Global customizing |
|
|
CUST_OBJECT |
Customizing of the processing module |
|
|
CUST_MAPPING |
Customizing of the finding |
|
|
IX_CONTROL |
External control structure |
|
|
KEY_SEPARATOR |
Separator for compound table keys |
|
|
PARAMETERS |
Determined parameters according to priority: Object -> Mapping -> External parameters |
Inherited methods of the root object
The following table contains methods that are implemented in the root object and used by the framework. The implementation examples from the 4th part of the API description - sample coding - partly contain ABAP coding that demonstrates the call of these methods. By redefining existing methods within custom processing modules, you can encroach on the standard processing considerably (e.g. converting data types).
|
Method |
Use |
More information |
|---|---|---|
|
Z_IF_IA_IXA_INTREXX_API* |
API methods |
|
|
CHECK_BAPIRET2 |
Checking of BAPIRET2 structures for errors and message attachments |
|
|
GET_FIELD |
Identify the single value from a table with incoming data |
|
|
GET_FIELD_WITH_X_FLAG |
Like GET_FIELD with update information for BAPI calls |
|
|
GET_FIELDS_FROM_STRUC |
Transfer incoming data to a transfer structure |
|
|
GET_NEW_NUMBER_KEY |
Simple number sequencing |
|
|
GET_SERVER_CONFIG |
Identify value from an external configuration value |
|
|
LOCKING* |
Modelling of locking concept |
|
|
MAP_BAPIRET2_TAB_TO_IXA_MSG |
Mapping of BAPI messages to an internal format |
|
|
MAP_FIELDVALUE* |
Convert values from an internal to external presentation (and vise versa) depending on the data type |
|
|
MAP_INTREXX_LANGUAGE_TO_SAP |
Mapping of the portal language from Intrexx to SAP |
|
|
MAP_IXA_MESSAGE_TO_BAL_LOG |
Mapping of the internal messages to the format of the application log |
|
|
MSG_APPEND |
Append a message for the external caller |
|
|
SET_FIELD |
Transfer a single value to the export |
|
|
SET_RESULTS_FROM_STRUC |
Transfer a transfer structure to the export |
Checklist: Create a new processing module
Create a class
Each processing module consists of an ABAP Objects class, which is inherited from a root class of the Portal Framework. To do this start the transaction SE80 for example. You can create a new ABAP class via the Context menu (right-mouse button).
Provide the new class with a technical name (perhaps based on your internal naming conventions) and a label.
Afterwards, an additional edit field will open via the highlighted button where you can specify which existing class the new class should inherit its properties from. Enter a class of the framework here.
Examples:
-
Z_CL_IA_IXA_OBJECT (WAS 6.x)
-
Z_CL_IA_IXA_OBJECT46 (SAP Basis 4.6)
If you have not assigned the new class to the local $TMP package, a popup for the transport query should open after confirming by clicking on "Save". The new class has been created and can now be activated. Activation is started via the 
button, for example.
A selection of the objects to be activated will then open.
After confirming here, the new class is activated and can be used.
Redefining the API methods
The extension concept of the Portal Framework is that the determined processing modules overwrite the corresponding API methods of the API interface. The API method "GET_DETAIL" is redefined here as an example. To do this, place the cursor on the API method and click the button 
.
Subsequently, the ABAP workbench generates an inheritance of the selected method with a coding suggestion for calling the same-named method of the parent object.
It makes sense here to open the inherited method of the parent object and add custom coding before or after it. In many cases however, the entire method must be reimplemented. The basic framework for such a reimplementation could be used as shown in the following coding:
method Z_IF_IA_IXA_INTREXX_API~GET_DETAIL.
* -------------- init
cv_processed = 'X'.
ev_error = 'X'.
* -------------- get inbound parameters
* -------------- initial check routines
* -------------- process
* -------------- fill outbound parameters
* -------------- finally set no error
ev_error = ' '.
endmethod.
This proposal assumes that the method can be exited at any time using the ABAP command "EXIT" in the event of an error. The error flag is only deleted at the end.
Create a transfer structure
For the tabular transfer of data via the API to an external caller a transfer structure is implemented. The external caller determines the structure of this structure (e.g. field names and technical properties of these fields) via the API method GET_METAINFO. Experience shows that it is a good idea to define this transfer structure as a structure in the ABAP dictionary. You can then treat this structure like a table, for example, and use the API methods for the registered processing module of the data handler "GENERIC_VIEW" (e.g. "GET_METAINFO"). In the following, the creation of such a transfer structure will be described as an example. Transfer structures usually contain a subset of actually available SAP tables or views, or rather fields from BAPI structures. If possible, you should use the same field names as the actual SAP processing functions (e.g. BAPI function modules). The data can then be transferred in a time-saving manner using the ABAP command "MOVE-CORRESPONDING". Transfer structures can defined SAP data in a table row that actually is not available or is not identifiable via joins. Examples of this are:
-
Customer data with address and communication information in a row
-
Process text fields (e.g. text field from status code)
The invoking API method is responsible that all necessary conversions take place before the data is added to the exit parameter of the API methods. A transfer structure is created either via transaction SE11 or once more in the ABAP workbench SE80.
The technical name of the new structure is requested in a popup.
You then define the field names and data elements of your transfer structure in the structure maintenance. The transfer structure should contain all key fields needed for the identification later.
Activate the structure.
Registering the processing module
The newly created class must be registered in Customizing for processing modules. The following screenshot shows the registration of the processing class created above as an example, which only refers to the transfer structure "YIXAPI_DEMO" with the key field "PARTNER".
Alternatively, it is also possible to implement generic processing modules without a specific reference to a transfer structure. In this case, the actual transfer structure is identified from other parameters generically (e.g. from the externally used data group name). The following prefixes are recommended as a naming convention for the required technical name "OBJECTTYPE":
-
Generic modules - GENERIC_*
-
Modules with BAPI reference - BAPI_*
Otherwise, the technical names should contain references to the in-house project and provide information on the expected functionality (e.g. "*ORDER*").
Finding the processing module
The processing module that was just registered is not yet found by the framework. The customizing of the determination must be maintained for this. The following screenshot demonstrates this for the explained example.
The new processing module can be accessed in future via the data handler "DEVELOPER_API" and the external data group "YIXAPI_DEMO".
Testing and debugging
This section describes the options as to how new processing modules, and their finding, can be tested and debugged.
Test the finding via the RFC API
The externally called RFC functions of the RFC API are listed in the API RFC functions chapter. Each of these RFC functions can be tested and debugged internally via the "SE37 ABAP" transaction. The following example shows this using the implemented API method "GET_DETAIL" of the processing module from the chapter Checklist Creating a new processing module. The externally called RFC function module for the API method "GET_DETAIL" is "Z_IA_IXA_API_GET_DETAIL". This is now started with SE37.
A window with the functional module interface will open.
The IS_CONTROL parameter plays an important role in determining the processing module.
The parameter can be edited by clicking on the button 
.
For a visually improved view, click on the button 
. For the test, it is sufficient to fill in the fields "IX_DATAGROUP" and "IX_DATAHANDLER". The values must be the same as those entered for the determination.
After confirming and returning to the interface view, the RFC function module can be started by pressing the F8 key or by clicking on the 
button. Depending on the API module used, it may be necessary to to fill other parameters.
After the start, the interface view contains the return values.
An initial export parameter "EV_ERROR" is a good indication that a processing module with these parameters has been found and executed. To find out whether the correct processing module has been started, a breakpoint can be placed in the corresponding API method of the processing module.
Debugging within the SAP system
This section describes a debugging option without an external call. With this, the ABAP developer can test the basic functionality of a processing module before an external user calls the RFC API functions remotely. To do this, place a breakpoint within the ABAP coding (e.g. at the start of the API method) using the CTRL-SHIFT-F12 key or by clicking on the 
button.
In newer releases (Basis SAP Gateway >6.10), a selection window for the type of breakpoint to be created can now be opened. A "Session breakpoint" must then be selected here.
The breakpoint is displayed in the coding.
The test must then be repeated by calling the relevant RFC function module. The transaction SE37 must be restarted for this. The debugger is called up when the breakpoint is reached.
The ABAP develop can now test in debug mode and find errors as usual.
External debugging
External debugging enables troubleshooting and testing of ABAP coding that is invoked externally (e.g. via RFC from the portal). In doing so, errors can be found that originate from the externally calling parameter populating in a different manner than what is expected. This option is available in SAP systems that use an ABAP basis >= 6.10. External debugging must be activated in the ABAP Workbench settings (transaction SE80, menu "Utilities / Settings").
It is also possible to debug users that deviate from the ABAP developer or login names. In this way, you can monitor, for example, the technical user that the external caller uses to log in to the RFC API. Please note that the user entered here must be sufficiently authorized (e.g. debugging, ABAP development) and categorized as a dialog user (e.g. only temporarily during the test phase). When the selection pop-up for the type of breakpoint appears, select "External breakpoint" here.
For the breakpoint to take effect for the external caller, the external system may have to log in again. If the debugger does not open after calling the API function, even though the internal test works, the SAP documentation on external debugging contains further information on troubleshooting. In most cases, you will find what you're looking for in the *.TRC files of the remotely used RFC API.
Externally activated debugging
Another method for activating the debug mode is made available by the externally used SAP RFC SDK. This makes it possible, for example when using the SAP Java Connector, to activate the debug mode externally (see documentation on SAP Java Connector). External callers that use the SAP Java Connector may provide parameters that remove this behavior. A limitation of this method is that this only functions stabily on MS Windows and an SAPGUI needs to be installed on the external caller's computer. This usually excludes this alternative because the server in the data center should not be used for development and tests.
More information
SAP Trust Manager SSO configuration
API Description Part 1 - Overview
API Description Part 2 - SAP Portal Plugin
API description part 4 - sample coding
Developer's Guide Part 2 - Integration scenario SAP external data group
Developer's Guide Part 3 - Scripting integration scenario
Developer Manual Part 4 - Personalized SAP Access / Single Sign On (SSO)
Send us an e-mail