BOL or API? - Some performance considerations

[arunprakash_karuppanan]

     I for one, hate to see direct API calls in the UI layer. We tend to follow the "standard" style of coding and it's for the best. But is this applicable in all scenarios? Well, it depends.

     Having used both the API function modules and BOL for modifying data, I would say that BOL is definitely a boon to the programmer. It shields the programmer from taking care of some intricate technical stuff that is required when using the API Function Modules. Programming in BOL is almost like simulating user inputs and this makes our lives easier. I don't care about the negligible performance costs in this case.

      When it comes to reading data, I find that it's the opposite. Reading data using the API function modules is far easier than using BOL relations and far more performance effective. But, we are tempted to give in to the novelty of the BOL and aesthetics considerations. The Web UI as such is oriented towards "modification/processing" of orders. When we integrate custom functionalities into the Web UI that includes some read-intensive code blocks, do we take into account the processing costs involved? We all know that using single selects within loop to fetch data is a huge performance bottleneck. Do we consider this when writing code using BOl method? If a 1..n relation has further relations for each of it's entity, we use the familiar while..endwhile loop into the collection and read those relations. Each read call(get) made by the BOL  hits the order read API. Isn't this the same thing as nested select statements? Though it is true that it will be buffered after the initial read, the performance cost involved in the initial read itself is huge. For those relying on code inspector checks to find performance bottlenecks, these will slip through. When a code block is meant only for reading data, this point could be considered. Just make sure that all modifications have been sent to the API layer before this(the core->modify). When performance matters, there is nothing wrong if you employ a diligent mix of the BOL and API methods.

   Finally, here's a tip. For those relying on API FMs for changing data, there's the problem of synching the API and BOL buffers. Without the synch, the changes will not show up in the UI. The MODIFY method of the CL_CRM_BOL_CORE class will trigger a synch only if a change has been registered in the BOL layer. So, in places where this method fails due to a lack of modification in this BOL layer, do a deliberate change to an existing BOL entity. You can even change some data and then change it back to its previous value. Once the change flag is set, the synch will happen and the changes done using the API FMs will show up in the front end.