Skip to Content
Author's profile photo Arun Prakash Karuppanan

BOL or API? – Some performance considerations

     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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Short and to the point.
      Do you have a concrete example as in you could use for this particular case
      or API

      Author's profile photo Arun Prakash Karuppanan
      Arun Prakash Karuppanan
      Blog Post Author
      Well, in our project, we use several "read-only" columns for displaying various item condition values. We were using the BOL relations to fetch it
      BTAdminI->BTCondISet->BTCondICondLineAll->loop and find cond relevant to column. For orders with huge number of items, the time taken for the initial read(open for display) was huge. Until a colleague changed the process by using the CRM_PRIDOC_READ_OW FM and exported them to a global variable, from which the getters fetched the values to display.
      Author's profile photo Former Member
      Former Member
      I faced these BOL performance issues a lot of times already. As it is just a layer of code above the "old" function module APIs, it will always be slower than direct calls.
      You are quite correct to mention that it is a lot more convenient. I do like the BOL layer a lot better than the old APIs as I do not have to declare hundreds of variables to convert the values between the different FM interfaces. STRING is just so much easier 🙂

      However I would like to throw another topic into discussion: What about custom developments?
      When putting time and effort into new developments in the BOL layer people tend to do just the GenIL classes. There is no underlying API as with standard SAP. Honestly I tend to omit writing FMs for my new data objects. The BOL is sufficient in 90% of the cases.
      Same goes for adjustments to standard BOL objects. You do a little tweak here and there. Using the BOL layer for IO everything is fine. Someone uses the "old" API and "bamm" you skip all the new logic and possibly a lot of consistency checks.

      So what do you think: Is it OK to do everything in the BOL/GenIL layer? Should there always be an underlying API that is usable in performance critical cases? What about the costs? Should adjustments in the BOL always be reflected in the API?

      Great idea to write a blog about it!

      cheers Carsten

      Author's profile photo Arun Prakash Karuppanan
      Arun Prakash Karuppanan
      Blog Post Author
      In my custom BOL development, I did not go for an "API" layer other than the GenIL classes. For all purposes, the GenIL classes were sufficient. I had only the WebUI to worry about. However, for standard transactions, the API layer was already there and proven stable. It makes sense to reuse them rather than merge the functionalities. It is also necessary to continue to support existing functions, for example, the numerous BAPIs...
      Author's profile photo eddhie kurnianto
      eddhie kurnianto

      Hi Arun,

      Nice blogs for reviewing performance between API and BOL.

      In your blog you give a tip how to synch the changes done with API to BOL buffers.

      Could you kindly please give an example how to synch the changes with API to BOL buffers?

      For example: there is changes of priority in task that done by API. How to synch the changes to BOL buffers?

      Thanks in advance


      eddhie kurnianto

      Author's profile photo Vinodkumar Kommineni
      Vinodkumar Kommineni

      Hi Arun,

      Thoughtful blog indeed. I would prefer to create separate API classes for the custom functionality also as that would give the flexibility to reuse them instead dumping everything into GenIL component.

      Thanks for the tip that is very much needed. I had  faced such problem earlier and had to do a dummy update to trigger the sync.



      Author's profile photo Former Member
      Former Member


      When working in the web ui, i'll strongly advise to stick to the bol because of the buffer as you stated. Using the API and then making a delibarate change in the bol layer will work but that looks like an overkill and i don't see the point.

      I did some performance measures comparing BOL vs API a while ago.

      The results weren't very different, but yes if you for example have to write a mass data update program, or a migration program, then it's better to use the API indeed.



      Author's profile photo Luís Pérez Grau
      Luís Pérez Grau


      Agree, but considering I'm a BOL fan, I would like to add: I love how the interfaces are normalized, Is fantastic the quantity of stuff you can do with a few lines (BPath), clean code, very easy to see whats going on, etc. (if you don't deal with condition BOL model or similar that are a pain) I think deserves sacrifice a bit of performance for clear-normalized-easy-to-maintain development.

      So if you ask me I only would use APIS:

      • When you are in a software layer that makes sense, like inside a core BADI, and even with that, you maybe have the same arquithectural problem, the API that your use is too up level for the lever which you are, and the API that you can use is no released by SAP (most of the cases, like ORDER_MAINTIAN)
      • When you are doing high performance data transfer
      • When no BOL programming is supported 🙂