Function sapnwrfc::binding::RfcConfirmUnit

pub unsafe extern "C" fn RfcConfirmUnit(
    rfcHandle: RFC_CONNECTION_HANDLE, 
    identifier: *mut RFC_UNIT_IDENTIFIER, 
    errorInfo: *mut RFC_ERROR_INFO
) -> RFC_RC

Removes the UID from the backend's status management.

After RfcSubmitUnit() returned successfully, you should use this function to cleanup the status information for this unit on backend side. However, be careful: if you have a three-tier architecture, don't bundle Submit and Confirm into one single logical step. Otherwise you run the risk, that the middle tier (the NW RFC lib) successfully executes both, the Submit and the Confirm, but on the way back to the first tier an error occurs and the first tier can not be sure that the unit was really executed in the backend and therefore decides to re-execute it. This will now result in a duplicate execution in the backend, because the Confirm step in the first try has already deleted the UID in the backend, and consequently the backend is no longer protected against re-execution of this UID. In a three-tier architecture, the first tier should trigger both steps separately: first the Submit, and after it knows that the Submit was successful, the Confirm. Also in case the Confirm runs into an error, do NOT execute the Submit again, never! You may try the Confirm again at a later point, but otherwise just ignore the error. Better a left-over entry in the status information table than a duplicate unit...

\in rfcHandle A connection into the same system, into which the corresponding bgRFC unit has been sent via RfcSubmitUnit(). \in *identifier The correct combination of UID and type of the unit. Best use the output you get from RfcCreateUnit(). \out *errorInfo More details in case something goes wrong. \return RFC_OK, RFC_INVALID_HANDLE, RFC_COMMUNICATION_FAILURE