Overview of Required API Methods
The following table is intended to provide a brief overview of which API functions must be implemented to achieve a certain external functionality.
|
Requirement |
Data Handler |
get_DataObjects |
get_MetaInfo |
get_List |
get_Detail |
modify |
delete |
update_temp_key |
|---|---|---|---|---|---|---|---|---|
|
Displaying Internal Tables |
GENERIC_VIEW |
O |
X |
X |
||||
|
Search Help Features |
GENERIC_VIEW |
O |
X |
X |
||||
|
Function Calls |
GENERIC_FUNCTION |
X |
||||||
|
Trigger functionality with data stored in an external system |
GENERIC_FUNCTION |
X |
||||||
|
External data modeling, data storage in SAP |
GENERIC_STORE |
X |
X |
X |
X |
X |
||
|
Trigger Functionality 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 lists attributes that are set during the instantiation of the processing modules. These can be used within API methods.
|
Attribute |
Uses |
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 the Processing Module |
|
|
CUST_MAPPING |
Customizing the Determination Process |
|
|
IX_CONTROL |
External Control Structure |
|
|
KEY_SEPARATOR |
Delimiters for composite table keys |
|
|
PARAMETERS |
Parameters determined by priority: Object -> Mapping -> External Parameters |
Inherited Methods of the Root Object
The following table lists methods that are implemented on the Root object and used by the framework. Some of the implementation examples from Part 4 of the API description— Sample Code —contain ABAP code that demonstrates how to call these methods. By redefining existing methods within your own processing modules, you can significantly modify the standard processing (e.g., converting data types).
|
Method |
Uses |
More Information |
|---|---|---|
|
Z_IF_IA_IXA_INTREXX_API* |
API Methods |
|
|
CHECK_BAPIRET2 |
Checking BAPIRET2 Structures for Errors and Attaching Messages |
|
|
GET_FIELD |
Determine the individual value from the table containing the input data |
|
|
GET_FIELD_WITH_X_FLAG |
How to Use GET_FIELD with Update Information for BAPI Calls |
|
|
GET_FIELDS_FROM_STRUC |
Transferring Incoming Data to a Transfer Structure |
|
|
GET_NEW_NUMBER_KEY |
Simple Number Range Implementation |
|
|
GET_SERVER_CONFIG |
Determine the value from an external configuration value |
|
|
LOCKING* |
Illustration of the Lockdown Plan |
|
|
MAP_BAPIRET2_TAB_TO_IXA_MSG |
Mapping BAPI Messages to an Internal Format |
|
|
MAP_FIELDVALUE* |
Value conversion from internal to external representation (and vice versa) by data type |
|
|
MAP_INTREXX_LANGUAGE_TO_SAP |
Mapping the Intrexx portal language to the internal SAP language |
|
|
MAP_IXA_MESSAGE_TO_BAL_LOG |
Mapping Internal Messages to the Application Log Format |
|
|
MSG_APPEND |
Add a message for the external caller |
|
|
SET_FIELD |
Pass a single value to the export |
|
|
SET_RESULTS_FROM_STRUC |
Pass a transfer structure to the export |
Checklist for Creating a New Processing Module
Creating a Class
Each processing module consists of an ABAP Objects class that inherits from a root class of the Portal Framework. To do this, start transaction SE80, for example. You can create a new ABAP class here using the context menu (right-click).
Give the new class a technical name (possibly based on your internal naming convention) and a description.
Clicking the highlighted button will open an additional input field where you can specify which existing class the new class should inherit from. Specify a class from 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 package $TMP, a pop-up window asking for transport information should open after you confirm by clicking "Save." The new class has been created and can now be activated. Activation is initiated, for example, by clicking the " 
" button.
A list of objects to activate will appear.
Once you confirm, the new class is activated and ready to use.
Redefining API Methods
The Portal Framework's extension concept involves the identified processing modules overriding the corresponding API methods of the API interface. Here, the "GET_DETAIL" API method is redefined as an example. To do this, place the cursor on the API method and click the " 
" button.
The ABAP Workbench then generates an inheritance for the selected method, including a code suggestion for calling the method of the same name in the parent object.
In this case, it makes sense to call the inherited method of the parent object and place your own code before or after it. In many cases, however, the entire method will have to be reimplemented. The basic framework for such a reimplementation could be used as shown in the following code snippet:
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, in the event of an error, the method can be exited at any time using the ABAP "EXIT" command. The error flag is cleared only at the very end.
Creating a Transfer Structure
A transfer structure is used to transfer data in tabular form via the API to an external caller. The external caller determines the structure of this data (e.g., field names and technical properties of these fields) using the GET_METAINFO API method. Experience has shown that it makes sense to define this transfer structure as a structure in the ABAP Dictionary. You can then treat this structure, for example, like a table and use the API methods for the registered processing module of the "GENERIC_VIEW" data handler (e.g., "GET_METAINFO"). The following section provides an example of how to create such a transfer structure. Transfer structures usually contain a subset of actual SAP tables or views, or the fields of BAPI structures. If possible, you should use the same field names here as those used by the actual SAP processing functions (e.g., BAPI function modules). You can then transfer the data quickly using the ABAP command "MOVE-CORRESPONDING." Transfer structures can define SAP data in a table row that does not actually exist or cannot be determined using joins. Examples of this include:
-
Customer master data, including address and contact information, in a single row
-
Formatted text fields (e.g., text field for the status code)
The called API method is responsible for ensuring that all necessary conversions have been performed before the data is passed to the API method's input parameters. A transfer structure is created either using transaction SE11 or in the ABAP Workbench (SE80).
A pop-up window appears asking for the technical name of the new structure.
In Structure Maintenance, you then define the field names and data elements of your transfer structure. The transfer structure should contain all the key fields that will be needed later for identification.
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 earlier as an example, which refers only to the transfer structure "YIXAPI_DEMO" with the key field "PARTNER."
Alternatively, it is also possible to implement generic processing modules that are not specifically tied to a transfer structure. There, the actual transfer structure is determined generically based on other parameters (e.g., the data group name used externally). The following prefixes are recommended as a naming convention for the required technical name "OBJECTTYPE":
-
Generic Modules - GENERIC_*
-
Modules Related to BAPIs - BAPI_*
Otherwise, the technical names should include references to the internal project and provide clues about the expected functionality (e.g., "*ORDER*").
Determining the Processing Module
The processing module that was just registered cannot yet be found by the framework. To do this, you must maintain the Customizing settings for the determination process. The following screenshot illustrates this for the example shown.
The new processing module will be accessible in the future via the data handler "DEVELOPER_API" and the external data group "YIXAPI_DEMO."
Testing and Debugging
This section describes ways to test and debug new processing modules and the process of identifying them.
Testing Lookup via the RFC API
The RFC functions of the RFC API that are called externally are listed in the " API RFC Functions " chapter. Each of these RFC functions can be tested and debugged internally using the "SE37 ABAP" transaction. The following example illustrates this using the implemented "GET_DETAIL" API method of the processing module from the chapter " Checklist: Creating a New Processing Module." The externally called RFC function module for the "GET_DETAIL" API method is "Z_IA_IXA_API_GET_DETAIL". This is now started using SE37.
A window containing the function module interface opens.
The IS_CONTROL parameter plays an important role in determining the processing module.
Click the " 
" button to edit the parameter.
Click the " 
" button to display a clearer view. For the test, it is sufficient to fill in the "IX_DATAGROUP" and "IX_DATAHANDLER" fields. The values must be the same as those entered for the determination.
After confirming and returning to the interface view, you can start the RFC function module by pressing F8 or by clicking the " 
" button. Depending on the API module used, it may be necessary to There are still more parameters to fill in.
After the program starts, the interface view displays the return values.
An initial export parameter "EV_ERROR" is a good indication that a processing module with these parameters was found and executed. To determine whether the correct processing module has been started, you can place a breakpoint in the corresponding API method of the processing module.
Debugging in SAP
This section describes a debugging option that does not require an external call. This allows the ABAP developer to test the basic functionality of a processing module before an external consumer calls the RFC API functions remotely. To do this, set a breakpoint within the ABAP code (e.g., at the beginning of the API method) by pressing CTRL-SHIFT-F12 or by clicking the " 
" button.
In newer releases (based on SAP Gateway >6.10), you can now open a dialog box to select the type of breakpoint to be created. Here, you need to select a "session breakpoint."
The breakpoint is displayed in the code.
After that, the test must be repeated by calling the appropriate RFC function module. To do this, transaction SE37 must be restarted. The debugger is called when the breakpoint is reached.
The ABAP developer can now test and debug as usual in debug mode.
External Debugging
External debugging allows you to troubleshoot and test ABAP code that is called externally (e.g., via RFC from the portal). This also makes it possible to detect errors caused by the external caller setting parameters differently than intended. This option is available in SAP systems that use ABAP Basis version 6.10 or later. External debugging must be enabled in the ABAP Workbench settings (transaction SE80, "Tools / Settings" menu).
It is also possible to debug users whose ABAP developer or login name differs from the default. For example, this also allows you to monitor the technical user with which the external caller logs in to the RFC API. Please note that the user entered here must have sufficient permissions (e.g., debugging, ABAP development) and be classified as a dialog user (e.g., even if only temporarily during the testing phase). When the pop-up menu for the breakpoint type appears, select "External Breakpoint" here.
For the breakpoint to take effect for the external caller, the external system may need 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 additional troubleshooting tips. In most cases, you'll find what you're looking for in the *.TRC files for the RFC API being used remotely.
Externally Triggered Debugging
Another way to enable debug mode is through the externally used SAP RFC SDK. For example, when using the SAP Java Connector, it is possible to enable debug mode externally (see the SAP Java Connector documentation). External callers that use the SAP Java Connector may provide parameters that trigger this behavior. One limitation of this procedure is that it works reliably only on MS Windows, and SAPGUI must be installed on the external caller's computer. That usually rules out this option, since the server in the data center should not be used for development and testing.
More Information
SAP Trust Manager SSO Configuration
API Description, Part 1 - Overview
API Description, Part 2 - SAP Portal Plugin
API Description, Part 4 - Sample Code
Developer's Guide, Part 2 - Integration Scenario: SAP External Data Group
Developer's Guide, Part 3 - Integration Scenario: Scripting
Developer's Guide, Part 4 - Personalized SAP Access / Single Sign-On (SSO)