Tips and tricks

The following are tips and tricks for developing business objects and RFC Server-specific business object handlers.

Multiple business objects contain the same return business object

Most RFC-enabled functions use the same name for the return object. When SAPODA generates a business object definition, it creates a child business object to represent this return object. If multiple business object definitions contain an identically named child business object, you can add the definition for child business object into the repository only once.

To enable multiple business objects to contain the return business object, you must modify the name of the return business object to be unique for each business object.

To rename the return business object, modify the definition of each business object definition that contains it. The definition of the child business object is contained in the same definition file as its parent.

To rename the child, do the following:

  1. Open the definition file for the top-level business object in a text editor.
  2. Locate the definition of the BOprefix_return child business object.
  3. Change the child's name to be unique. For example, append a number to the text (sap_return_2).
  4. Change all references in the definition to refer to the newly named child. For example, change the value of the Type property for every attribute that represents the child business object.
  5. Save the changed definition file.
  6. Use Business Object Designer to load the newly named child business object into the repository.
    Note:
    Alternatively, if ICS is the integration broker, you can use the repos_copy command to load the definition into the repository.

Generated business object definition contains unnecessary attributes and child business objects

SAPODA interprets all RFC-enabled function interface parameters and, for each one, it creates a corresponding WebSphere business object attribute or child business object. To increase performance of business object processing, remove all unrequired attributes and business objects from the business object definition.

Note:
SAPODA facilitates graphically removing all optional attributes and child business objects before definition generation. For more information, see Provide additional information.

To increase performance of business object processing, you can also remove all unrequired importing and exporting table parameter values from the application-specific information.

After definition generation, you can use Business Object Designer to manually edit the business object definition if you require other changes. However, be careful that you remove only attributes that you absolutely will not be using.

Generated business object names are too long or fail your naming conventions

SAPODA uses the name of the RFC-enabled function module to name the generated business object. You can use a text editor to modify a business object's name.

Important:
If you do change the name, ensure that you modify all references to the name as well. However, do not modify the parameter names of the generated application-specific information.

To change a generated business object's name:

  1. Save the definition to a file.
  2. Use a text editor to shorten or change the name.
  3. Use Business Object Designer to copy the newly named child business object into the repository.
    Note:
    Alternatively, if ICS is the integration broker, you can use the repos_copy command to load the definition into the repository.

Generated AppSpecificInfo for table parameters specify unnecessary parameters

Table parameters can be both importing and exporting parameters. If you do not require importing or exporting of values for a table parameter, you can remove it from the application-specific information.

For example, for a create operation, if you do not need to return the table data from the SAP application after the create operation has completed, you can remove the exporting parameter value (such as Etable name).

For a retrieve operation, you do not need to specify any importing table parameters. Therefore, you can remove the importing parameter value (such as Itable name).

Note:
You must remove the unrequired value from the AppSpecificInfo of the attribute in the parent that represents the child as well as from the AppSpecificInfo at the business-object level of the child business object. Do not remove the colon (:).

For example, to remove the ETable_7 exporting parameter in Figure 30, you would do the following:

  1. In the Child_2 attribute of the Top_Level_BusObj business object, change the attribute's AppSpecificInfo value to:
    ITable_7:
     
    
  2. In the AppSpecificInfo at the business-object level of the Child_2 business object, change the value to:
    ITable_7:
     
    
  3. In the AppSpecificInfo for each attribute of the child business object, using Attribute_14 as an example, change the value to:
    IField_14:
     
    

Copyright IBM Corp. 1997, 2003