Skip to Content

Why BOPF is a strategic part of our application architecture


As head of development one of my responsibilities is to deliver high class custom applications to our business. It would be best to achieve this without spending money 😉   So I am always looking for ways to get things done more efficient. As new technologies (especially UI technologies) are trending to come along more frequently things are getting more complicated. Our proven way to develop custom applications in the past did not match today’s requirements to be ready for frequent innovations and also to remain cost efficient. So we needed a new approach.


To be able to integrate new technologies in an easier way there are just a few design principles to observe. These are the separation of concerns and loose coupling. Both design principles will make it easier to replace components with new ones without side effects. Those new components can integrate new technologies.

A common approach is to set up a high level architecture showing the application layers. So that’s what we have done at first.

architecture - plain.png

The layers and components within a layer focus on having a unique application model that delivers data and functionality to several consumers. Consumers can be lightweight portal and mobile user interfaces (SAPUI5) as well as heavyweight transactional user interfaces (Floorplan Manager). Also collaboration through SOAP webservices shall be possible.

The key feature to be able to adapt new ui technologies in an easy way is the dedicated integration layer. This layer works as an adapter transforming data by means of FPM feeder classes and Gateway data provider classes.

So far we have set up a high level architecture for developing applications using the current UI technologies and being able to adapt new UI technologies when they come into play.

Cost Efficiency

As I said before cost efficiency is another key figure to deliver custom applications. At first sight the architecture will tend not to be cost efficient. Implementing three adapters to serve SAPUI5, SOAP and FPM cannot be cost efficient. So what will help us to become more cost efficient.

Our approach was to identify components that are not bringing value to the business and to reduce efforts for these components. To bring value to the business means that it is helping us to cover our company specific needs and to enable us to differentiate from our competitors. So on the other hand if things do not bring value to our business this does not implicate that those things are useless. These things are just more likely to cover general aspects of an IT solution.

The user interfaces are bringing value to the business. The more a user interface is tailored to the specific needs of the business the more savings are achieved with respect to process efficiency. But having two implementations for the user interface will result in higher costs. So we may end up in spending the money we just saved. The key figure is to use functions that enable us to easily tailor user interfaces to our needs.

Having a look at the integration layer ends up in realizing that mapping and converting data is nothing that brings direct value to the business. In this layer we have to place multiple implementations to support our user interfaces. To be cost efficient we have to get rid of multiple implementations as well as individual implementations. But we also have to stay agile to be able to support new technologies.

Within the application layer there is the specific business logic that is bringing direct value to the business. But it also covers many functions like transaction handling, locking a.s.o. that is not bringing direct value to the business.

So we have collected plenty of aspects that are not bringing value to our business. The key to avoid spending plenty of money on implementing these aspects is to reuse existing components. The best solution would be to use proven and solid frameworks that cover those aspects. And that’s were BOPF comes into place.

Target Architecture

Based on the fundamental architecture above we are now integrating BOPF and check if it will help us to focus on business needs.

BOPF will be placed within the application layer. The core framework helps us implementing the business object with its information structure. Without any coding we get a working business objects with all common aspects like transaction handling, locking a.s.o. Further standard functionality like admin data, authorization checks, attachments, texts and change documents can be “plugged in” with reuse components. Our BO specific business requirements can be added by implementing actions, validations and determinations.

Now let’s have a look further on our way towards the user interface. The next layer covers integration aspects. BOPF has further components like the FBI (Floorplan BOPF Integration) and GBI (Gateway BOPF Integration) that let us reduce implementation efforts within the integration layer. For simple scenarios you can consume the business objects directly but in real world you probably will implement and FBI-View. So within the integration layer you will still need to implement some exit classes and do some modeling (like composition of BOs and reducing information for external access).

To be flexible for further technological innovations we rely on further standardization with SADL or getting new standard based integration components like GBI or FBI when necessary.

On the UI layers we focus on the strategic technologies like Floorplan Manager and SAPUI5 with Netweaver Gateway. While the Floorplan Manager and Netweaver Gateway already allow us to easily build transactional (stateful) web applications and REST services we hope that River RDE will be the missing step to efficiently develop SAPUI5 based applications.

Now it’s time for the big picture with the frameworks and components being places in the fundamental architecture.

architecture with bopf.png

You may wonder why integration to SAP standard is nearly shaded away. If the SAP standard BOs are also implemented by BOPF everything is fine, but to integrate with other technologies is not as easy as it should be. Maybe SADL will help here too, but SADL relies on BOs being implemented with at least another framework and most of the SAP BOs are free implementations. But to be fair, most of the customer BOs are also free implementations and are not based on frameworks.


As you can see the usage of BOPF as a framework for creating business objects can help you focus on your business needs and to reduce efforts for implementing standard functionality. In addiction it supports the separation of concerns and helps you establish a clear fundamental architecture.

Like in all strategic pictures things look perfect. In real world you will probably have situations where things don’t fit perfectly. But in the end I am sure there are much more pros than cons.

Another aspect when being in real world is that you usually do not start from scratch and have to integrate into already existing BOs that are developed without frameworks. In another blog post I will describe a way on how to convert existing developments to the BOPF world.

You must be Logged on to comment or reply to a post.
  • Hi Kai,

    I like your blog and I share your point of view. BO frameworks can reduce development costs, standardize application architecture, are compatible with SAP standard BO models and support multiple UIs. They are meta-data driven, easier to understand and so reduce maintenance costs. Moreover there is a good support of reuse tools and integration into other frameworks like BRFplus.

    I also have some questions: How did your developers adopted this shift of paradigm? Do you have some do’s and don’ts when starting with BOPF in custom development projects?

    Best Regards,
    Tobias Trapp

    • Hello Tobias,

      we are still on our way to shift to this new architecture and not every developer in our team is already developing this way. I think this is one of the aspects  to be aware of. The shift takes time.

      In an overview the things to keep in mind are

      • Marketing for target audience IT department
        • Technology overview (capabilities of the framework)
        • Architecture overview (like in my blog)
        • Show challenges in our landscape (new UI technologies, multiple implementations)
      • Marketing for target audience developers
        • Kickstart Hands-On Workshop showing basic functionality having a running application at the end of the workshop
        • Best Practice articles in our in-house wiki for IT documentation (with links to the good tutorials published by Thea on SCN)
      • Implementation considerations
        • Start with simple BOs with low dependencies to existing developments
        • Respect your developers work done in past because they have done a great job without help of a framework!
        • Use redesign projects to switch to BOPF
        • Even enjoy the small successes (it takes a long breath to complete the mission)
        • Celebrate successful implementations and promote them

      As I mentioned in the introduction of my blog I am the head of development. The first productive BOPF based application has been implemented by myself. So if you are convinced by the advantages of using the framework start with yourself using it. 😉

      Best Regards,


  • My first impressions is BOPF complicates, not simplifies.  Takes longer to program around the complicated framework so you lose any productivity gains promised by the framework.

    • Hi Kenneth,

      I agree that it looks a bit complicated at first sight. That's probably because of the usage of the command pattern. I am sure there will be coming some round ups for the developers to become more productive when implementing the command objects. Beside this you will be very productive with the framework. I could already save some hours of implementations.

      So in your opinion, is it the command pattern that seems to complicate things or are there also other aspects of implementation that are complicated from your point of view.



      • Yes, having to use all the layers of keys causes extra programming effort and is just plain confusing.  I haven't programmed in it myself, but I've sat in on a class and have seen another sharing their work they did in it.  😐   That's the look I had afterwards!

        • Well, like always it depends what are going to do. From my perspective programming a full-blown business object takes time, think of persistency but also integration into frameworks like Business Application Log, Archiving, BRFplus and so on. If you have more than one BO it will become even more severe since you should standardize it otherwise the maintenance costs will become high. BOPF is a good way to standardize it and you have great tools that will help you when your data model is complex.

          In my last project I had to develop a new business object and since BOPF is not availablein SAP_BASIS I had to use Object Services which is still fast compared coding persistency from scratch. But with BOPF I would have been much easier. And now it become even more severe since this BO has to be exposed to mobile apps using OData –with BOPF this would have been an easy task.

          So my suggestion is to give BOPF a try. I made the experience that ABAP development changes and –at least in my company – a senior ABAP developer needs at least one the following skills: BOPF, OData or BRFplus/DSM. But I also learned that many appreciate it because they have good chances to join development projects that do really cool stuff with new technology.

          Best Regards,

          • Here's maybe a strange question for you two.  I have some custom db tables for a custom application.  Can I create a BOPF object to use the tables I already have somehow?  I wouldn't want to create new db tables just to experiment with BOPF for these tables.  But I think BOPF would handle the db updates better than I have programmed them.

          • Yes. There's a way to reuse existing tables in BOPF. You can create a data access class for this purpose. This topic will be part of my next blog post in about 2 weeks (convert existing developments to BOPF). So I would ask you to wait 2 weeks. Is it okay for you?



          • Sounds great!  I'm in no hurry.  It would just be a personal side project for me to help learn BOPF and get some benefits of the framework.  I'll be looking forward to it.

  • Hello Kai,

    Thanks for give some output to BOPF, I didn't know this framework existed, but once more the same question pops to my head,  another business object layer? how many we have right now? the classical BOR, Persistence objects, BOL and now BORF, who knows what's in SAP Labs kitchen right know or I'm missing (like BORF)...

    I really appreciate the efforts of SAP trying to make everything object oriented, and I also understand BOR is something old which should be replaced, firstly we tried persistence object, but as Tobias said is quite tedious to implement and the project should be correctly sized, which not allays happens...IMHO persistence object was a little too much, and I don't know how many projects (excluding SAP) was implemented, but if there's people still using structured ABAP....well...

    Going back to the topic, ok,  we have BOL/GENIL which looks like very similar, at least from the modelling perspective, all this framework was ported from CRM to  ECC and changed the classes extension to be cross application,  can someone clarify which framework we should use to have something homogeneous, I'm not talking about CRM because we are happily stuck with BOL/GENIL, but if was going to develop on ECC (again) I would try to implement models using BOL/GENIL, but wait, there's BOPF...



    PD: Sorry for the off topic, but I saw in this blog a good opportunity to rise my concerns 🙂

    • Hi Luis,

      you're right that from modelling perspective both frameworks have much in common. When it comes to implementation they are completely different.

      In my understanding BOL/GenIL is just an outer shell for individual full blown implementations. There is much to code and the inner structure is not standardized. The benefit of this approach is that you can easily reuse nearly any kind of existing developments. Especially existing model implementations with APIs like they already existed in CRM require this kind of approach to save investments.

      When using BOPF the inner structure of implementation of modeled elements is much more regulated. The strict separation of DB access and application logic with framework based data buffering between these parts requires extensive refactoring. But in the end you have a well formed and well implemented BO saving much individual coding.

      In a first attempt I thought of using both frameworks. BOL/GenIL should be the framework to save investments on existing developments and BOPF should be our choice for new implementations and redesigns. When I learned BOL/GenIL a little better I experienced that I would be able to easily create an outer shell for my existing developments to be ready for new technologies on the UI side, but on the model side I am stuck on half the way. So actually I would clearly prefer using BOPF for BO implementations.

      By the way there's another framework for BO implementations in the SAP world. It's called SPI (Service Provider Interface). I don't know details about it. It's just the name I saw within the context of frameworks.

      Best Regards,


      • I believe you made a very valid point when you talked about the model implementation, is still tedious, to be honest with you I allways skip this part using AET or Rapid applicatinons, so in a real project I never created a full BOL/GENIL model as the development efforts will be quite expensive and usually the business is not clear enough to build a full application using BOL/GENIL and in a future take advantage in that investment. Some objects maybe are in one single view or other become used everywhere, well, I guess everyone know what I'm talking about...

        I really appreciate the time you took in you response sharing your thoughts and experience was a really good feedback.

        Another one???!! SP???!!! I will pretend I never readed this...gosh... 😀

    • Hi Luis,
      I suggest using BOL/GENIL to enable legacy applications for UI technologies which offer special support for it like FPM or CRM Web UI.
      Creating new applications I suggest using BOPF. You get more features for free - I do not want to repeat the whole blog. And quite often, frameworks want to be the master, having the full control. BOPF can be used in a 'slave' mode, so that you can combine BOL and BOPF BOs in one transaction.
      But the most interesting part for me is the fact that in the context of BOPF, FPM and Gateway we have the models from the UI to the persistency under control. So we can leverage model informations to push down read requests, including sorting, filtering, aggregations, paging and access control to the database. You get the full transactional support and the performance of the database - based on the same model. This is the vision we are working on step by step. I hope that you find this as exiting as we do.
      Kind regards

      • Hi Thea,

        Actually I'm quite happy that someone from SAP give some light about this, so thanks to be involved in this discussion.

        Do you have any example/doc/whatever how BOL and BOPF can be mixed? a blog would be really cool.

        From the CRM side I don't see a very big benefit to use BORF as you already said, the Web UI fully supports the BOL (IMHO quite nicely) but doesn't BORF 🙁 If SAP replace the Web UI for another UI technology, let's say...FIORI, well, that will be a different story, but before that firstly all the existing models should be ported to BORF, in this scenarios I belive SAP should lead and fix a standards approach, otherwise we will have a mess, as allways...



  • My only real question is why wasn't this done five to six years ago for ERP when SAP was pushing a SOA/ESA approach?  I really don't understand why SAP never has ever completed a uniform API on a single technology for ERP that covers all business functions within the last 15 years.

    I really appreciate you sharing this information with us, but I really feel that unless SAP decides to implement this across an entire application, I don't see the full benefits except for new developments.

    Take care,


    • We will be rather off topic but I think there's an easy answer: Sexy Fiori apps will sell but a sexy application architecture will not. The decision makers on customer side don't look behind the scenes and the people looking behind the scenes are not heard by the decision makers. The benefits of a good architecture will come in mid to long term and require investments. Without a clear demand from the market (that will be the business case) they will probably never go this way. And if there would be a clear demand from the market you will not face one SAP but several kingdoms within SAP (for each module) making their own decisions on how to code an applications. To me it was like a revolution that UI technology has been centralized.

      • Totally agree and I would like to add: Big changes on behind scenes are SCARY, "It took me 20 years to make this work, there's no way I'm going to change it" We don't have to go that far even in CRM we have one nice component which has his own rules, conditions, everyone loves conditions...

        What I nice off topic, really exciting 🙂

      • We will be rather off topic but I think there's an easy answer: Sexy Fiori apps will sell but a sexy application architecture will not.

        As far as SAP is concerned, a consistent API would improve the upgrade rate of the customers, and therefore would reduce the number of releases SAP has to maintain (which I imagine is a huge chunk of money).

        Customers don't upgrade because the API is a piece of *, and every ISV has to create some workaround during implementation that explodes in the upgrade.

        The way business logic is coupled to the UI in transactions like VA02 is appaling, and WM is the worse offender from my experience.

      • But failure to actually stick with one API technology and/or provide this is a "technical debt" that haunts SAP as it trys to sell newer applications.  It's interesting after doing some research that BOPF was an "obscure platform" relegated to the SAP TM module back in 2008.  I just find it weird with the BOPF technology around for at least six years, it's now considered strategic.  What's changed in six years that makes BOPF a strategic solution instead of some framework developed for something else?

        Take care,


        • In the blog I described "just" one customers view so it's the strategy of a single customer (and I hope I can inspire some other customers). For me there are two major changes that happened last year:

          - BOPF became available for customer implementations (before it was an internal tool and for customers to extend SAP BOs)

          - I have heard about that framework for the first time 😉

          Best Regards,


        • Hi Stephen,

          It's interesting after doing some research that BOPF was an "obscure platform" relegated to the SAP TM module back in 2008.

          I'm wondering why you look at threads from 2008 since everything is published here: . Especially the  connection to ByD is very interesting since there are even more frameworks which have been successfully used there and are now available in SAP Business Suite - think of BRFplus for example. BRFplus was developed in context of ByD and turned out to be very powerful because it is better than all all existing frameworks. So SAP took the chance to introduce it to SAP Business Suite and is now able to focus on a few tools instead a plethora of outdated crap.

          If you want to know why BOPF is strategic and why it is more compared do BOR/BOL/GenIL/Object Services is no secret. Maybe  James Wood will offer a public SAP Mentor Monday webinar and give an introduction - James is an expert in this area and wrote awesome blogs about this topic.



          • I guess my concern is that SAP keep repeating the same behavior pattern that they did with IDOC/BAPI/ALE/WebServices/BOL/BOR/etc and always make these interfaces used for "new development", but never fix the fundamental problems with ERP.

            If SAP changes technology flavor of the day every two to three years, how can customers or anyone ever expect SAP to produce a stable business API.  I'm waiting to see if in EHP7 SAP finally eliminated the BDC issue with vendor master creation.  Perhaps SAP really likes the movie groundhog day when it comes to providing API's for the suite.

            Take care,


          • Do you see any other chance? An ERP solution needs a common BO model and a Framework for this. I don't consider BOL/GenIL as state of the art - BOPF is the better choice. But nevertheless we can build bridges from a superior framework to BOL/GenIL - and I appreciate this.

            never fix the fundamental problems with ERP.

            Blogging about fundamental problems of Business Suite is one of my favourite topics: f.e. the different Business Partner models of SAP Business Suite that have non-consistent extensibility mechanisms. BOPF can't solve this but it solves a very important problem: SAP Business Suite is technologically heterogeneous and contains too many different frameworks and programming paradigms - and this is what BOPF can adress.

            In other words: BOPF is part of SAP Business Suite Foundation (software component SAP_BS_FND) - so it can't solve above mentioned problems in software components SAP_APPL or BBPCRM, but it is a solid foundation for future development.

            If SAP changes technology flavor of the day every two to three years,

            Yes, if SAP would decide to introduce to change central frameworks every year then this would be harmful to every IT strategy. But at the moment I see exactly the opposite: SAP starts to focus on strategic frameworks. And yes, I hope that there will be a more  strict governance process in the future for SAP Business Suite.



          • Stealing from a tv show/movie: Would you agree that  "In the end SAP can only have one API framework for the suite and I hope this is the last one"?

            Take care,


          • No, I don't think that will ever happen. But as you do I would appreciate if SAP Business Suite would be more consistent and there are migration paths from one technology to the next.

            Take care,


          • It's impossible to provide migration paths for arbitrary technology if the concept is different enough. SAP needs to be consistent, instead of jumping to the new flavor every 2-3 years, which shows a tremendous lack of vision from a technology stand point.

          • I'm afraid I until I see how the standard applications starts to move to that direction I don't feel like moving to BOPF (maybe to play with). One example is CRM, in the past we had the APIs and little by little BOL/GENIL was introduced, but as people cared!, "we are still using SAP GUI" then..BOOM! "we are not maintaining SAP GUI anymore, for users, so use Web UI, and guess what? Web UI "only" works with BOL/GENIL, ok everyone knows if you want to accomplish something that lasts you should implement it in that way, I guess what I expect from ECC is a similar "strategy" so "hey! everything works on BOPF principles, finally it's time to change".

            Another different story is BRF+, which BTW I'm not an expert , but is something I see easier to be escalated and implemented.



          • I think it is very easy:

            • If you create an add-on to an existing SAP solution you will have to use the underlying programming model - and this is BOL/GenIL for CRM and BOPF for above mentioned Travel Management for example.
            • In custom development you have more degrees of freedom. But if you want to create a own BO the blog entry tells some reasons to use BOPF for rapid development of standardized BOs. IMHO BOPF is really cool and worth a try.

            It gets more interesting if you want to use BOPF in CRM context - this should be topic for another blog.

            But I feel some discomfort between the lines of your comment: SAP promotes many new technologies  and we don't know what will stay - and I'm convinced that not everything will survive. And yes, we all have questions about the direction how Business Suite will evolve - and next AP TechEd/d-code SAP should clarify it. But again, I don't see it as problem of BOPF. For BOPF is documentation, SAP Trainings, an SCN subspace - so you are not alone.



          • Why should we rely on these frameworks? We have a choice which is to ignore them, and that's what I do, because the investment is not worth it when they keep changing them. I have training costs, added development costs, etc.

            All the benefits that I would reap from investing substancial effort in using the framework (reduction in maintenance cost), is lost by the regular changes SAP makes.

            If you use common industry best practices for application development, you don't really need these frameworks.

  • Practical question about oData integration. I setup my BOs, create a oData channel for them, and after some months I add more fields to by BO.

    What happens to the oData channel? It updates automatically or do I need to make manual changes?

    I don't particularly like the FloorPlanManager so the other benefit seems Gateway Integration.

    • Hi Joao,
      currently there is no automatic update of the OData model in Gateway. The idea behind is, that a Gateway service represents an "outside" model, mostly an UI model. The service implementation maps the outsid model to the backend implementation - this is how Gateway started. An automatic update of the service does not fit into this philosophy.
      But the development process of UIs is getting quite cumbersome if you just want to create a Fiori UI on BOPF or CDS models. Therefore we are currently experimenting with exposing these model types generically, meaning that updates on the models reflect automatically in the Gateway service.
      This contradicts of course the basic philosophy of Gateway and I cannot promise that these PoCs will result in a delivered feature but it would simplify the development process.
      Kind regards

      • Hello,

        It may contradict the philosophy of Gateway, but if you make it optional there is not problem. The fact is that, unless BOPF takes some effort off the maintenance of the OData Channel it isn't really worth it. I can design custom classes like I do in any other language, and expose them in Gateway with little effort. Unless BOPF makes this automatic what's the point?

        I have to wonder why the focus on these frameworks that go away after a few year, while companies like Google and Apple have undeniable success in maintaining a very competitive (consumer) ecosystem without them. They provide great APIs, that's what developers need. Ok, in way Apple as Core Data but that is consistent with the OO model, you just inherit from generic classes that have additional (persistency) functionality. It's light, it's simple, and it doesn't completly break a developers worklfow.

        These frameworks can't replace a consistent and complete API for SAP ECC, a fact that SAP keeps ignoring.

  • It's always interesting to hear feedback on something "new" (if we can use "new" in terms of at least 6 years old "kid"). Especially from a customer side. Thank you Kai!

    My first impression after running through some materials available in BOPF SCN space was.... YAF! No, I'm not yelling 🙂 Yet Another Framework!

    As mentioned by Luís Pérez Grau it looks quite similar to BOL/GenIL. I don't want to compare this two frameworks right now, but it'd be interesting to see the comparison in all aspects from someone who is experienced in both. Especially I'd love if it is a customer.

    I personally think BOPF came to Business Suite in quite a similar way as BOL/GenIL did. Sorry, I compared them again, but as it is. BOL/GenIL came from CRM to Business Suite when it was ready for. The same applies here with BOPF. 6 or more years of proven use in TM module (mainly, I think) gave it the result.

    But here my main question: will BOPF be used widely in Business Suite as expected? Or outside its generic applications (TM and some others) it will be used as much as BOL/GenIL does? The time will show, I hope.