Implementing Your Own BAPIs
SAP provides a large number of BAPIs. If you want to implement your own BAPIs, you have to use your own namespace.
You have the following options:
• You can develop your own BAPI in the customer namespace.
• You can modify a BAPI delivered in the standard system.
1. Copy and modify the function module belonging to the original BAPI.
2. In the Business Object Repository create a subobject type for your BAPI object type in the customer namespace (Tools → Business Framework → BAPI Development → Business Object Builder).When you create the subobject type the methods of the business object inherit the subtype.
3. Set the status of the object type to Implemented (Edit → Change release status → Object type).
4. You can change and delete the methods of the subtype or enhance them with your own methods.
Notes about Asynchronous BAPIs
If you want to implement an asynchronous ALE business process, you have to Define a BAPI-ALE Interface from the BAPI.If you implement a BAPI as an asynchronous interface, in addition to following the standard programming BAPI guidelines, keep in mind the following:
• The BAPI must not issue a COMMIT WORK command.
• The method's return parameter must use the reference structure BAPIRET2.
• All BAPI export parameters with the exception of the return parameter are ignored and are not included in the IDoc that is generated.
• Status records log the BAPI return parameter values.
After the function module which converts the IDoc into the corresponding BAPI in the receiving system has been called, status records are written for the IDoc in which messages sent in the return parameter are logged.If, in at least one of the entries of return parameter, the field Type in the return parameter is filled with A (abort) or E (error), this means:
• Type A:
Status 51 (error, application document not posted) is written for all status records, after a ROLLBACK WORK has been executed.
Type E:
Status 51 (error, application document not posted) is written for all status records and a ROLLBACK WORK is executed.Otherwise status 53 (application document posted) is written and a COMMIT WORK executed.
Filtering Data
There are two filtering services provided for asynchronous BAPI calls using the BAPI-ALE interface.
Interface Reduction: If you want to reduce the BAPI interface, you do not have to define any filter object types. The BAPI reduction does not have any conditions - it is a projection of the BAPI interface. The developer of the BAPI whose interface is to be reduced must create the BAPI as a reducible using appropriate parameter types. The optional BAPI parameters and/or BAPI fields are deactivated in the distribution model for the data transfer. You can reduce an interface in two ways,
• By fields (using checkbox lists)
• Fully • Parameter Filtering Filter Object Types [Extern] are assigned to the business object method. The valid filter object values must be defined in the distribution model. The BAPI parameter filtering is linked to conditions, it is therefore content-dependent: The lines in table parameters of asynchronous BAPIs are determined depending on the values in the lines (or dependent lines) for the receiver.
Filters are used to define conditions in the form of parameter values that must be satisfied by BAPIs before they can be distributed in ALE outbound processing. The table dataset of a BAPI is determined when the parameters are filtered. Hierarchy relationships between table parameters of the BAPI can also be defined. Distribution by Classes [Extern] is also supported.
For more information see Filtering BAPI Parameters BAPI filtering is the term used for the shared use of both the filter services of the BAPI interface. BAPI filtering is implemented as a service in ALE outbound processing.
Prerequisites for Using Filter Services
The table below lists the prerequisites that the BAPI interface must satisfy, so that ALE filter services can be used. The BAPI can have the following parameter types: Field Reduction Full Filtering Parameter Filtering
1. Unstructured without checkbox
2. Unstructured with checkbox X
3. Single-line structured without checkbox
4. Single-line structured with checkbox X .
5. Multiple-line structured without checkbox
X X
6. Multiple-line structured with checkbox
X X X
7. Multiple-line unstructured without checkbox
X
8. Multiple-line unstructured with checkbox
Note: The fields filled with X satisfy the prerequisites.
Explanation of above table:
1. An unstructured parameter without a checkbox is, for example, a BAPI key field (e.g. the parameter Material in methods of the business object Material). This parameter type cannot be reduced.
2. If there is an unstructured checkbox parameter with the name PX and the data element BAPIUPDATE for an unstructured parameter with the name P, the parameter P is reducible. The parameter is reduced by setting the value of P and of the checkbox parameter PX to EMPTY.
3. A single-line, structured parameter without a checkbox is not reducible.
4. A single-line, structured parameter P with structure S and associated checkbox PX with structure SX can be reduced by fields, provided that:
• S and SX have the same number of fields, which are identical in name and sequence.
• The FUNCTION field and the key fields in S and SX each have the same data element.
• All other fields in SX have the data element BAPIUPDATE.
The FUNCTION field in P and the key fields must be marked as mandatory fields. All the other fields you can chose whether to label them as mandatory. Mandatory fields cannot be reduced. Non-mandatory fields are reduced by setting the field values and the corresponding checkbox to EMPTY.
5. Multiple-line structured parameters (table parameters) without a checkbox cannot be reduced by fields. Parameter filtering and full filtering are possible.If the hierarchy is maintained and, if dependent tables exist in the hierarchy, records of the dependent tables will also be filtered.
6. A multiple-line structured parameter P with checkbox PX can be reduced by fields, fully filtered or filtered by parameters.
• For field reduction the prerequisites under 4 must be met.
• The checkbox PX must lie directly under P in the hierarchy, with identical key fields, so that the corresponding lines from P and PX are filled, when the parameters are filtered.
• If the hierarchy is maintained and, if dependent tables exist in the hierarchy, records of the dependent tables will also be filtered.
7. A multiple-line, unstructured parameter can only be fully filtered and cannot be used in a hierarchy. Parameter filtering is not allowed.
8. Multiple-line, unstructured parameters with a check box cannot be filtered.
RELATED LINKS
No comments :
Post a Comment