Hi Suhas,
just came across this old post and find your suggestion... and I don't think it's 100% correct, sorry. IMHO, your statement would be correct, if saying 'you should bundle all function calls in update task in a single LUW. This will ensure if the commit fails all the previous changes are also rolled back.'
The important thing is that we are discussing the BAPIs here - and these are usually developed the way that all the checks are carried out before the update FM is registered in the BAPI for update processing, with purpose to detect all potential errors at the first place. So, it's very, very unlikely that any BAPI would trigger the same kind of errors in the update FM as we can normally see in dialog transactions where the errors occur time from time and lead to express message about cancelled update.
What I intend to say is that BAPI errors (of application nature, i.e. 'logical' or 'data integrity risk' errors) are detected first and (should any be found) returned in some BAPIRET2 return table actually before BAPI reaches the update FM registration internally. Then if one out of 10 BAPI calls fails this way (which can be detected just by looking for 'E' messages in return table) then COMMIT WORK AND WAIT would not fail but would rather process remaining 9 BAPIs successfully (since the BAPI which 'failed' did not manage to register the update FM yet).
So, to reach 'all or nothing' logic on more BAPIs in one LUW, the only way is to check the presence of 'E' message after each BAPI call and stop the processing on the first 'E' message found.
BR
Michal