Use SAPODA to generate business object definitions and business object
handlers for each RFC-enabled function that you want to support. You
can use the generated objects without any modifications. However, you
can manually edit these objects to refine the functionality.
After the objects are generated, you must add the business object
definition and its corresponding BAPI-specific business object handler to your
WebSphere business integration system's runtime environment.
The BAPI-specific business object handler files are:
- BAPI Name.java
- BAPI Name.class
For example, given the BAPI_SALESORDER_CREATEFROMDAT2 BAPI and a
user-specified prefix of sap_, SAPODA generates the
following:
- sap_bapi_salesorder_createfromdat2 (business object definition
that includes all child business objects)
- Bapi_salesorder_createfromdat2.java
- Bapi_salesorder_createfromdat2.class
- Important:
- You can modify the name of the generated business object as well as the name
of its child business objects. To do so, you must edit the definition
as a text file rather than in Business Object Designer. If you do
change a business object's name, ensure that you also modify all
references to the names that you change. Also, if you modify the names
of the generated.class file for the business object handler,
you must maintain the changes for the application-specific information for the
associated business object.
- Note:
- For BAPIs and RFC-enabled ABAP functions that are developed in a development
namespace, SAPODA removes or replaces "/" characters in the
function name with "_" when naming the business object definition,
.java, and .class files.
SAPODA removes the "/" character only when it is the first
character of the name. Although the definition name or file name does
not contain this character, the code still accurately calls the specified
function with its proper name containing the "/" characters. Also, when
a function name begins with a digit, SAPODA prepends the name with the string
Rfm_.
This section describes the following tips and tricks for developing
business objects and BAPI-specific business object handlers:
Most BAPIs 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 that child
business object into the repository only once, or copy only a single
definition file into the repository directory.
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:
- Open the definition file for the top-level business object in a text
editor.
- Locate the definition of the BOprefix_return child
business object.
- Change the child's name to be unique. For example, append a
number to the text (sap_return_2).
- 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.
- Save the changed definition file.
- Use Business Object Designer to load the newly named child business object
into the repository.
- Note:
- Alternatively, if the WebSphere Integration Server is the integration broker,
you can use the repos_copy command to load the definition into the
repository.
SAPODA interprets all BAPI interface parameters and, for each one, it
creates a corresponding 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 "Developing business objects for the BAPI Module".
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.
SAPODA uses the name of the BAPI function module to generate the name of
the business object definition. 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:
- Save the definition to a file.
- Use a text editor to shorten or change the name.
- Use Business Object Designer to load the newly named child business object
into the repository.
- Note:
- Alternatively, if the WebSphere Integration Server is the integration broker,
you can use the repos_copy command to load the definition into the
repository.
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 26, you would do the following:
- In the Child_2 attribute of the Top_Level_BusObj business object, change
the attribute's AppSpecificInfo value to:
ITable_7:
- In the AppSpecificInfo at the business-object level of the Child_2
business object, change the value to:
ITable_7:
- In the AppSpecificInfo for each attribute of the child business object,
using Attribute_14 as an example, change the value to:
IField_14:
