The function of an ABAP handler is to get business object data into or out of the SAP application database. When processing business object data, ABAP handlers:
Every ABAP handler receives business object data in the same format (flat structure). However, each ABAP handler has specific requirements for business objects that are determined by the complexity of the WebSphere business object definition, the native API that SAP provides, and the level of functionality that the ABAP handler provides. For these reasons, ABAP handlers may interpret business object data by parsing it into a structure specific to the business object. This enables the ABAP handler to more easily manipulate the data.
The adapter provides several ABAP handlers, such as an IDoc handler. The IDoc handler leverages SAP's IDoc technology by providing an ABAP handler to interpret business object data by reformatting it into an IDoc-based structure for the ABAP handler to use.
Once the ABAP handler interprets the business object data, the ABAP handler must integrate it with the SAP application database. It must manipulate the business object data to use SAP native APIs such as Call Transaction, BAPI, or ABAP SQL to get data into or out of the application database.
The intent of a Create, Update, or Delete operation is to modify the SAP application database. While the SAP application database schema for a given business object defines the structure of the data, the transactions provided by SAP that modify that data have a much broader scope of influence. As a result, directly modifying the application database tables of an SAP application can have disastrous results to the applications's data integrity.
Instead of directly modifying the database tables, SAP provides a flexible ABAP API (Call Transaction) for Create, Update, and Delete operations. Call Transaction is SAP-provided functionality for entering data into an SAP application. It guarantees that the data adheres to SAP's data model by using the same screens an online user would use in a transaction. This process is commonly referred to as screen scraping.
If the verb is Retrieve, then the connector uses ABAP SQL statements to retrieve data from the SAP application database. The business object data provides the keys for the where clause when pulling data. The difficulty in this methodology of retrieving data is that the retrieved data must be represented in a format that represents the business object structure. This is done in the ABAP handler ABAP code.
Regardless of the verb of the business object, the connector waits for two types of confirmations:
If the ABAP handler returns a non-zero code, then no business object is returned to the connector. If ABAP handler processing is successful, then the connector expects new business object data that reflects the operation performed. For example, after a successful Create, the returned business object is an exact copy of the business object initially sent in, except that the keys are updated. Similarly, a successful Retrieve results in a fully formed instance of the business object. However, Create, Update, and Delete operations have different requirements for returned business objects than do Retrieve operations.
When InterChange Server (ICS) is the integration broker, the difference in requirements comes from how the WebSphere business integration system handles business objects, specifically dynamic cross-referencing of object IDs during mapping. When the connector returns a business object to InterChange Server after a Create or Update operation, the mapping infrastructure attempts to update the cross-reference tables with the newly acquired object ID. This is accomplished by looking up the value of the business object's ObjectEventId attribute that was set when the business object was originally sent to the connector.
To the ABAP handlers, this is significant because the ABAP handlers are responsible for "stitching" the object IDs into the business object that is returned to the connector. Typically this is not an issue for Retrieve operations because there is no corresponding dynamic cross-referencing. Retrieve operations generate an entirely new business object that is returned to the connector. This business object does not have any direct relationship to the structure of the original business object.
The business object data returned by the ABAP handler must be in the same flat structure format as when it was initially passed in to function module Y_XR_RFC_DO_VERB_NEXTGEN. The ABAP handler needs to send out only simple type attributes with the following information for each:
The attribute name is not required at this point, because the connector uses only the application-specific information to create a business object from this data. Identifiers for the beginning and ending of business objects or object type attributes are not used and should not be added. For example, the BoName and BoVerb rows are not used in the business object returned from the ABAP handler. They are initially passed into the ABAP handler only to facilitate processing.
The ABAP handler must adhere to the following set of rules when populating a flat structure with business object response data representing an WebSphere business object:
Figure 11 illustrates a flat business object (no object type attributes).
Figure 11. Flat business object SAP_Material
Table 10 represents the structure of a flat business object,
SAP_Material, whose key value is ItemID. Notice that field
ATTR_NAME is not required, APPTEXT is unique for each
attribute, and because this business object is flat, the PEERS
field can be left blank.
Table 10. Flat business object SAP_Material
ATTR_NAME | ATTR_VALUE | ISKEY | ISNEW | PEERS | OBJ_ NUMBER | APPTEXT |
---|---|---|---|---|---|---|
(blank) | 000000000000001179 | (blank) | (blank) | (blank) | (blank) | ItemId |
(blank) | Toaster 6000 | (blank) | (blank) | (blank) | (blank) | ShortDesc |
(blank) | SAP_124 | (blank) | (blank) | (blank) | (blank) | ObjectEventId |
Figure 12 illustrates a hierarchical business object (containing object types).
Figure 12. Hierarchical business object SAP sales order (IDoc)
Table 11 shows a representation of a flat structure of a hierarchical
business object based on an IDoc Sales Order. Notice that field
ATTR_NAME is not required, APPTEXT is unique for each
attribute, and because this business object is hierarchical, the
PEERS field lists the appropriate relationship.
Table 11. Hierarchical business object based on an IDoc sales order
ATTR_NAME | ATTR_VALUE | ISKEY | ISNEW | PEERS | OBJ_ NUMBER | APPTEXT |
---|---|---|---|---|---|---|
(blank) | USD | 0 | 0 | 1 | (blank) | E1EDK01:CURCY |
(blank) | 0000000101 | 0 | 0 | 1 | (blank) | E1EDK01:BELNR |
(blank) | SAP_124 | 0 | 0 | 1 | (blank) | E1EDK01: ObjectEventId |
(blank) | User1 | 0 | 0 | 2 | (blank) | Z1XRV40:ERNAM |
(blank) | SAP_125 | 0 | 0 | 2 | (blank) | Z1XRV40: ObjectEventId |
(blank) | 001 | 0 | 0 | 1 | (blank) | Z1XRV40:QUALF |
(blank) | 1000 | 0 | 0 | 1 | (blank) | E1EDK14:ORGID |
(blank) | SAP_126 | 0 | 0 | 1 | (blank) | E1EDK14: ObjectEventId |
(blank) | User1 | 0 | 0 | 2 | (blank) | Z1XRV40:ERNAM |
(blank) | SAP_127 | 0 | 0 | 2 | (blank) | Z1XRV40: ObjectEventId |