Standard BAPI or wrapped in a ZBAPI?

Question

Hi folks,
Iu2019m doing a scenario File to RFC (BAPI_PO_CREATE).
The file has several purchase orders to create and Iu2019m wondering which the best approach to follow? Iu2019ve been thinking in the following two approaches:
1 u2013 As BAPI_PO_CREATE only creates one PO per call, with help of ccBPM and a block ParForEach I can call BAPI_PO_CREATE synchronously for each header line plus items. However, this scenario must be atomic (or we create the entire POu2019s or nothing is created) so Iu2019ve to set the test parameter of this BAPI, collect each exception and in a switch step ask if there is exceptions. In case of exceptions a new message is created with all exceptions and mailed to the business process responsible. If everything is ok, Iu2019ve to repeat the BAPI calls but now without the test parameter set, in order to crate all PO in R/3.
I didnu2019t try it before but I think it can work.
2 u2013 Wrapping the BAPI_PO_CREATE, BAPI_TRANSACTION_COMMIT and respective rollback in a ZBAPI; with this I can model the development as I wish. I can create a ZBAPI to receive all POu2019s and inside it in a loop create each PO and also do the exception handling there.
The first approach seems aligned with SAP best practices; however it seems complex to handle and heavy for PI system performance compared with second approach.
Another point is we are going to upgrade SAP ERP; therefore we will get the local integration engine to develop ABAP proxies. I think with the 2ª approach we can move quickly (migrate) these developments to ABAP proxy.
Which are the best practices for integration with RFC adapter? Should I always use standard BAPIs or in this case is recommended to wrap the BAPI?
Thanks in advance,
Jorge.

Answer 1

Hi,
>>Which are the best practices for integration with RFC adapter? Should I always use standard BAPIs or in this case is recommended to wrap the BAPI?
there are a few alternatives to your approach because of which
I wouldn't use any of those two which you proposed
this is what I'd so:
since you don't have ABAP proxies yet - you should use IDOC
PORDCD101 to create purchase orders - this way you can send all of them
in one call (IDOC bundling) but in ERP they will appearch as one by one
so even if one of them will not work you will know which one is it
(this is not the case with RFC calls as they are not persistent in ERP)
if you can wait for abap proxies - you can also choose the abap proxy approach (also does not matter if you do them one by one or all at once
as they will be persistent in ERP so you will know which one failed
and you can reprocess - the same as with IDocs)
since RFCs in your two scenarios are not persistent you'd
have to build some functionality to cover that - but there is no need to do it
as you have :
1. stasdanrd IDOC
2. you can do it with proxies
Regards,
Michal Krawczyk