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 from the business object definition all
attributes and business objects that are not required.
- 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 from the application-specific information all importing
and exporting table parameter values that are not required.
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 unneeded 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:
