This is Sid; The topic of my Blogging activities in SDN will be initially for the Business Rules and BRFplus from a technical point of view and will follow it up by DSM and the areas in SAP. You may also find Blog and publications of Carsten Ziegler very helpful.
Some of the organisations, if not most of them which I have worked with view the business rules the same way they would view any other kind of requirement in their blueprint. This way we will most likely end with a lot of rules, which has led to rebuilding them all back in ABAP in some cases. A more efficient way would be to determine the decision making components in the requirements and then take it further which would be ideally the regular or rapid change in the business. If the Business want to make changes to behavior regularly then the decision making component and business rules will be a good basis for automating it. You may find Blog and publications of James Taylor on this very helpful.
Saying that, If the Business want to make changes to behavior regularly and the Business Users want to make changes to the rules rather than a Technical User, Then restrictions on the BRFplus workbench actions play a major role. Restricting the business users from what they can do in the workbench would definitely make us all sleep a lot better for sure. It can be as simple as not allowing the business users to edit certain rules which again depends on the requirement we have. There are a lot of ways which we can achieve this, as one would say no two developers program the same way.
I would say my approach would be handling through the application exit class in the BRFplus and assisting it by maintaining authorization data in custom roles. Below I have a basic scenario where the users are restricted by maintaining the data in authorization data of the role.
First step would be creating the authorization fields, which we would be using in the authorization objects. We need authorization objects to maintain the data in the roles which we want the users to give access to.
Once we have all the necessary fields the we need for the authorization abject, we can move onto creating the authorization object.
Next we move on to creating the roles. Based on the business model and restrictions we intend to apply to the users we have to model our roles and use them appropriately.
We can add necessary transaction to the roles.
Once the roles have been created, we can move on to authorization maintaining the BRFplus expressions in the authorization data.
We have to add the authorization object manually in the authorization maintenance and generate the profile.
Here we can maintain all the universal unique identifications and the respective processing type access you would like to give the users. Once we have maintained the authorization data then we can restrict the users from the custom class maintained in the application exit class of the BRFplus application.
Once the authorization data has been maintained, we move onto adding the users to the roles.
Now we move onto creating the exit class and adding the application settings interface to the exit class.
Once the application settings interface has been implemented, we can restrict users from the interface method authority_check.
By passing the importing parameters ID and the activity of the method authority_check to the authorization object set the exporting parameter ev_passes respectively to restrict the user. All that which is left is to add the exit class to the BRFplus application.
We can even restrict the user to certain actions, enhancing the expressions to suit our business requirements, creating expressions/rules dynamically from a report or any such, all of which I will be addressing in my future blogs. As I said earlier, it all depends on the requirement and what we will be comfortable giving access to the business users.
Hope this was knowledgeable and will come in handy in your future endeavors and that you will stay with me for the next blogs.