Skip to Content
Author's profile photo Tobias Trapp

Common Misconceptions of DSM/BRFplus

I am glad that many people read my blogs about BRFplus/DSM on SCN and I got many questions about them. And it is even more interesting there are three questions I’m hearing all the time so I decided to answer in this small blog post.

„DSM is of no use because no one is so crazy to do hot deployment into production!“

This sentence always makes me smile and my answer is as follows: if you don’t have the grit to deploy your software into a productive system you should stop working in business and do research & design instead. The truth is very simple: It comes the time that you deploy your application resp. change into production and you can use DSM with or without any downtime.

The major question is whether the installation process of software into a productive system is robust or if there’s the danger of crashing the productive system. SAP experts are highly skilled and know complex procedures to deal with transports. Please be aware that DSM has its advantages:

  • rules systems can be deployed as a whole and the process is transparent in the sense of audits and reviews compared to dealing with transports. If a problem occurs just undeploy the latest version which is nearly impossible if you work with transports.
  • rule systems are easier to test: just deploy them in a test client or test landscape, so tests can be performed much easier and this is good for the quality of your implementation.

So please don’t tell me that you are afraid of deploying into production. As SAP experts should know about all of state-of-the-art techniques of deployment and transportation. And please note that DSM is not about (recklessly) deployment – it is a mechanism to make those things more robust. Moreover it has many features like debugger, unit test environment, HANA expression types, future activation of rules and so on. I recommend to look at the product and its features.

Technically hot deployment is not a big risk since SAP has many experience with object generation and in many frameworks liek web services and output management for example many objects will be generated on thy in production. With DSM it is easier since you have a good toolset for deployment.

„The WDA frontend of BRFplus is so slow – why can’t you code this in ABAP Dynpro“

When I’m hearing or reading those words I’m feeling despair. At first WDA is not slow and you can develop very fast UIs using it. It is interesting that I hear this argument only by people who know only ABAP Dynpro.

But hearing this in connection with BRFplus and DSM I get sad because its UI is sophisticated as well as highly optimized. I know many other BRM frameworks like condition techniques, HDT, BRF and so on, but BRFplus allows very fast development: I love its drag&drop features, the fast navigation forward into detail views and backwards and the extremely flexible UI. So if you have this impression of BRFplus please ask a BRFplus expert to demonstrate you how efficiently you can work with it. And if you have knowledge about ABAP Dynpro please have a second look at the BRFplus UI and ask yourself how to create it. I think even using commands like IMPORT DYNPRO and GENERATE DYNPRO it will be difficult and perhaps even impossible.

So I recommend to learn how to use the UI and you will start to like it.

“At a hands-on session I did some simple exercises but this is child’s play. Formost we need naming conventions for real world rule systems.“

Yes, we need naming conventions for many reasons, f.e. we have to ensure that in the context of a rule set or functions or data elements have unique names. But please consider the following: in legacy frameworks like BRFplus  we use naming convention for multiple purposes like internal structuring of rule sets, separation of artifacts having different ownership and prevention of reuse for example. Please be aware that those aspects can be realized and controlled(!) using different techniques like modularization of BRFplus application, catalogs and unnamed artifacts. So I recommend that you start to learn the advanced features of BRFplus.


To be honest I’m not surprised about those misconceptions. When SAP started to explain the table lines shouldn’t be used anymore many people spoke up and declared the end of the world and that it wouldn’t be possible to code efficient ABAP applications in the future. The same happened when ABAP Objects was introduced: many people argued that it is not possible to develop scalable ABAP applications using OO techniques. Today we are laughing about this mind-feebleness but this is not fair: every technology based on new paradigms creates misconceptions and I’m not immune to misunderstanding, too. In fact this is a weakness of my character type since I definitely belong to the judging character types according Myers & Briggs classification. So “getting things done in the most efficient and effective way” is my motto – and this is why I like BRFplus. But one weakness of my character type is that I’m judging too fast so I try to slow down and to examine the facts more carefully instead coming to hasty conclusions.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Carsten Ziegler
      Carsten Ziegler

      About deployment

      What many people do not understand is that transport can dramatically limit
      your ability to respond to change. As a consequence, business expert deploy
      disconnected desktop tools that give them all the freedom, or they write
      documents with instructions how to deal with cases etc. All of that is
      difficult to control and audit. DSM with its flexible deployment model is the
      only tool that combines it all: quick updates, full transparency, automation,
      and integration into the SAP stack. Additionaly, as Tobias explained, there are
      many tools that make deployments save. It is not only the test tool for UT like
      tests and test deployments, but also the possibility to test the new rules on
      the target system in a controlled sandbox.

      About naming

      Naming in BRFplus is technically irrelevant. Any name may be used. There are
      also icons that are quickly learned so that people know what an objet is
      without a need to code this into the name. On another aspet DSM provided a
      features called customer attributes that allow defining customer
      specific attributes for objects such as decision tables. Any additional
      information may be put into those attributes.

      Author's profile photo Tobias Trapp
      Tobias Trapp
      Blog Post Author

      I made the same experience: especially in large SAP implementation projects where you have to transport many customizing entries - say more than 1000 customizing tables - transport management becomes very difficult since the order of transports can't be arbitrary. So every tool that makes transport easier and more transparent will reduce the risks of the project. If more SAP applications would have the same configuration mechanisms like DSM or would use DSM implementation projects would be much much easier.

      Custom DSM attributes are very useful and I recommend to use them everytime you start to think about naming conventions. Especially in migration projects from BRF to BRFplus you should think about using them.

      Best Regards,


      Author's profile photo Jocelyn Dart
      Jocelyn Dart

      Hi Tobias, Great blog and well argued. I suspect many IT people grossly underestimate how much pain the IT backlog gives to the business.  Giving the business at least some aspects of the system, i.e. business rules, where the business is the expert and the business can control the adaptation, testing and deployment of their own data is not only of real benefit to the business, but it considerably reduces the pain points and complaints they have with IT, which can only be good news for IT!

      These sorts of considerations also clarify who should be chosen as responsible for deployment on the business side... really you want the person who will be held accountable if its wrong.  Because then they won't just make sure its tested before they put it in... they'll watch it like a hawk until they are confident its behaving as expected.   And yes those sorts of people are just as common in business as IT.

      Thanks again for blogging!