Here's a short description how BAPIRETURN Exception Mapping works:
- SAP.Connector.DLL comes with builtin proxy types for BAPIRETURN, BAPIRETURN1, BAPIRET1, BAPIRET2, and BAPIRET2Table. To make them easier to use, they they are inherited to follow there natural content extension.
- The base class of all Proxies "SAPClient" has properties "BapiReturn" and "BapiRetTable" that are used as "storage" of last error occurd.
- When MapBapiException is turned on, the proxy generator will creat NO proxy types for the BAPIRET* types, but instead use the build in types. AND it will create overloads of all functions that have a BAPIRET* parameter in there signuture, where this paramter is removed and instead mapped to the BapiReturn or BapiReturnTable property.
- The setter of the BapiReturn property will check the given value if it is an error. It looks like this:
public virtual BAPIRETURN BapiReturn
{
get
{
return _bapiReturn;
}
set
{
if (value != null)
{
_bapiReturn = value;
if ((value.Type == "E") || (value.Type == "A"))
{
throw new BapiException(value);
}
}
}
}
The setter of BapiReturnTable will do a similar check, but it will itterate over the entries of the table to find an error entry.
From this explanation you see that BAPIRETURN Exception Mapping only works on the overloads without the BAPIRET* parameters. If you need to customize the checking logic, you can either check the BapiReturn / BapiReturnTable parameter after the call or override the these properties and implemement them like you want.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.