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 InterChange server (ICS) 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 meta-data, 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.
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.
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 ICS 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 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.
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 ICS 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 28, 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:
