Use SAPODA to generate RFC-enabled function-specific business
object definitions and RFC Server-specific business object handlers
for each RFC-enabled function you want to support. You can use the
generated files with minimal modifications.
The only edit you must make is specifying the name of the
destination collaboration in the verb application-specific
information of the Server verb.
- When the WebSphere InterChange Server is the integration
broker, this information is required because a collaboration cannot
explicitly subscribe to an event that is pushed to the connector.
Therefore, the RFC Server-specific business object handler must
determine the appropriate destination collaboration from the
business object's metadata, and then instantiate the
collaboration.
- When WebSphere MQ Integrator (WMQI) is the integration broker,
a dummy value is required for the RFC Server-specific business
object handler to process the event correctly.
- Important:
- If the RFC-enabled function that you are using does not contain
a simple field attribute, and SAPODA has created a Dummy_key
attribute as the key attribute, do not modify the values of this
attribute.
After the business object definition and its corresponding RFC
Server-specific business object handler are generated, you must add
the business object definition to your WebSphere business
integration system's runtime environment.
- Use Business Object Designer to load the business object
definition into your repository.
- Note:
- Alternatively, if the WebSphere InterChange Server is the
integration broker, you can use the repos_copy command to
load the definition into the repository.
- Use a system command to copy the RFC Server-specific business
object handler files to the following directory under the product
directory:
\connectors\SAP\bapi\server
The RFC Server-specific business object handler files are:
- RFC-EnabledFunctionName.java
- RFC-EnabledFunctionName.class
For example, given the BAPI_PO_CREATE RFC-enabled
function and a user-specified prefix of sap_, SAPODA
generates the following:
- sap_bapi_po_create (business object definition that
includes all child business objects)
- Bapi_po_create.java
- Bapi_po_create.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
Server verb application-specific information for the associated
business object.
- Note:
- For RFC-enabled ABAP functions and BAPIs 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_.
The following are tips and tricks for developing business
objects and RFC Server-specific business object handlers.
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:
- 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 InterChange Server is the
integration broker, you can use the repos_copy command to
load the definition into the repository.
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 unneeded 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 unneeded 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 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:
- Save the definition to a file.
- Use a text editor to shorten or change the name.
- Use Business Object Designer to copy the newly named child
business object into the repository.
- Note:
- Alternatively, if the WebSphere InterChange 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 29, 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:
