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.