Let’s take a deep dive into one of the most crucial areas of SAP S4 HANA MDG, the BRF+ rule based workflow process for master data objects. Today we are going to go into the configurable rule based workflow for MDG. This is a highly customizable standard workflow template that allows for a configurable number of steps & roles involved in the creation & change of master data. This post will help you if you already have a fundamental knowledge of what SAP MDG is & how it works. If you’re new to SAP MDG I recommend the following articles:
In order to have an overview of SAP MDG in S4 HANA check out the following article: https://techconsultinghub.com/2022/03/01/sap-s4-hana-mdg-overview-part-1/
If you would like to learn more about change requests in SAP MDG check out the following article: https://techconsultinghub.com/2023/01/21/sap-s4-hana-mdg-change-request-process/
In this article we will explore the following topics:
- Overview of the SAP MDG rule based workflow
- How to configure the SAP MDG rule based workflow decision tables
- SAP MDG configuration that supports the rule based workflow process
Overview of the SAP MDG BRF+ rule based workflow
As detailed in the change request overview article the change request template determines which workflow template will be utilized. From an SAP enhancement perspective workflows are created using the SAP business workflow concept. Typically creating a workflow is a custom job for developers but MDG comes predelivered with a number of different workflow templates.
The most flexible of the workflow templates is WS60800086 (BRF+ rule based workflow) and as you can see below I have provided an example of the material change request type that comes with this rule based workflow standard.
This workflow template is unique as the design for the workflow template relies on the configuration of 3 business rules framework plus tables (BRF+). This allows a one step approval or a ten step approval to create/change master data. Let’s take a look at some of the features of a rule based workflow
- Configurable Number of Steps – Workflow steps are configurable based on BRF+ decision tables so you can have a s single approval or ten approvals required. Additionally, based on context in the change request you can change who needs to approve making it very flexible
- Faster Enhancements – There are several natural enhancement spots in the rule based workflow. If the standard configuration does not meet the business requirements, there are natural places to add custom code without having to fully develop a custom workflow
- Quick Excel Based Configuration – Due to the nature of decision tables using BRF+ you can easily export to excel, manipulate the workflow steps and upload from excel making it easy to configure
- Reuse of Workflow Steps – Since workflow steps can be easily downloaded to excel, having similar workflows across different change request types is easier due to BRF+
- Parallel Steps Enhancement – Ability to have parallel steps in which two tasks for the workflow can occur in parallel. This does require some minor enhancements for logic of multiple steps that can be approved or rejected but is native to the workflow template
Now that we have an overview of the features of the rule based workflow, jumping in and showing how it works will give a better idea of the use cases.
How to configure the SAP MDG rule based workflow decision tables
The key to the rule based workflow is understanding the three primary decision tables that drive the entire process
- Single Value Decision Table using BRF+ – In simple terms let’s call this the primary driver of the workflow table. This is the most important table that determines what the next step of the workflow will be. Based on this next step it will either take you to the user agent decision table if a user will perform the next action or to the non user agent decision table if a non user system based activity is going to happen
- User Agent Decision Table using BRF+- When the single value decision table determines that a user should perform an action, then this table will say WHO will perform that action. The options are a user, role, job, organizational unit, position, the change request creator or the last user in the workflow (INIT or LAST)
- Non User Agent Decision Table using BRF+ – When the single value decision table determines that a system activity should occur then it goes to the non user agent decision table. Here a number of system activities can occur such as data replication, activating the data in the change request, removing the change request (rollback), or completing the overall workflow (last step)
What is a decision table in BRF+
Let’s take a look at the single value decision table and understand how it works. To understand the decision table the first step is to understand its structure in BRF+. Condition tables in BRF plus all work the same so let’s take an example quickly to understand how a condition table works with a master data business rule example.
A condition table in BRF+ simply looks like a standard table with some some of the columns in grey and other columns in green. The columns in gray are considered condition columns and the columns in green are result columns. Let’s create an example where based on the material type & plant assigned we determine the MRP Controllers name. Let’s break it down, first we have 2 conditions which are material type & plant. Then we have a result we want which is the MRP controllers name.
- Condition Columns
- Material Type
- Plant
- Result Columns
- MRP Controller Name
Now we would have a table created that has this structure and let’s fill in some example data
| Material Type (Condition) | Plant (Condition) | MRP Controller (Result) |
|---|---|---|
| FERT | 1001 | JOHN SMITH |
| HALB | 1004 | RICK NEELY |
| HALB | 1005 | RICK NEELY |
| HALB | 1001 | BOB JAMESON |
| NLAG | COLE KEEDAN |
In this example imagine we had a material type as HALB & the plant is 1005, in this case the MRP controller which is the result of the decision table would be RICK NEELY. This is a simple example and as we go further it will get more complicated but think of it as an IF statement with the condition columns on the left to determine the result which would be the columns on the right. As a note, in this table we made plant as optional. In this case regardless of the plant if the material type is NLAG COLE KEEDAN is the MRP controller.
Decision table details of MDG rule based workflow
Now that we have gone through this simple example, let’s take a look at what makes up the single value decision table which we stated is the primary driver of a workflow in SAP MDG. As a note CR standards for change request:
- Single Value BRF+ Decision Table in MDG
- Conditions
- CR Previous Step – This is the last step that occurred in the workflow. If it is the first step 00 is the initial step
- Previous Action – There are actions (buttons on the workflow) that can occur such as approve, reject, send for revision etc. this provides what the last action was. It is not a required field so for example the initial creation step can have this blank since it doesn’t matter the action (which was submit)
- Chng. Req. Priority – The priority that was provided on the change request (this is a configurable drop down field)
- Chng. Req. Reason – The reason field drop down on the change request (this is a configurable drop down field)
- CR Rejection Reason – The reason a change request was rejected (this is a configurable drop down field)
- CR Parent Step – This is used in the case of a parallel workflow (a topic for a future blog post)
- Parallel Agt Grp No. – This is used in the case of a parallel workflow (a topic for a future blog post)
- Results
- Condition Alias – This is just a way of linking the single value table with the user or non user agent table. You can put any number of letter combination that helps you identify a unique ID that will link to the other tables
- New Chng. Req. Step – This is going to be the new step of the workflow. Remember the previous step is a condition and the result will be a new step
- New CR Status – This will be the next status of the workflow, remember there was a previous step and now when it gets to the new step of the workflow this will determine the status
- Hours to Completion – This is to set time for a specific step of the workflow before a very basic auto generated email notification is sent to the user. It is very generic with little information so typically this is not utilized
- Merge Type – This is utilized as part of the parallel processing functionality which is complicated and requires custom development so will be a topic a future post
- Merge Parameter – This is utilized as part of the parallel processing functionality which is complicated and requires custom development so will be a topic a future post
- Dyn Agt Sel Service – In the case there is complicated logic to determine the role and you want to add additional logic to determine the role/user that should be assigned you can have development implemented here. Service name would be placed in this field
- Conditions
Below is a screenshot of the key fields needed at a minimum for the workflow to be ran in the single agent BRF plus decision table
For the full list of fields & settings see below
Next let’s take a look at what fields make up the User Agent Decision table
- User Agent BRF+ Decision Table in MDG
- Conditions
- Condition Alias – Remember this was the result of the single value decision table. Now it is the condition which determines the result of the user agent table. This value must match with one of the condition aliases from the single value decision table. As a note the workflow checks for a match in either the user agent or non user agent table, it checks both to see what’s valid
- Results
- User Agt Grp No. – This is used for parallel processing where there will be more than one user agt at the same time. You can just default 001 if you won’t be using parallel
- Step Type – Step type is another configuration in SAP MDG that determines which buttons will be available to the user. For example, approve/reject or activate/send for revision etc.
- User Agent Type – Here is where you specify if it is a User, Role, Position, Job, organizational unit or special user (CR creator or Last Step User). Typically you don’t want to specify individual users, you want to specify a role since users can join and leave the company & also you want more than one person being able to process the change request
- User Agent Value – This is where you would put a user name if user was the agent type, role if role was selected etc. Now for special user in the user agent table you use INIT for the initiator of the change request (Who created the CR) and you use LAST for the last user who processed the change request
- Conditions
Below is a screenshot of the key fields needed at a minimum for the workflow to assign a user to a step in the single agent BRF plus decision table
For the full list of fields & settings see below
Next lets take a look at the final table, the non user agent decision table. The fields utilized for this table are listed below
- Non User Agent Decision Table in MDG
- Conditions
- Condition Alias – Remember this was the result of the single value decision table. Now it is the condition which determines the result of the non user agent table. This value must match with one of the condition aliases from the single value decision table. As a note the workflow checks for a match in either the user agent or non user agent table, it checks both to see what’s valid
- Results
- Agent Group – This is used in the case case or parallel workflows, for non parallel workflows you can default 001
- Process Pattern – This is what tells the system what it is supposed to do, examples are data replication, activating the data in the change request, removing the change request (rollback), or completing the overall workflow (last step)
- Service Name – This is used when you want the system to perform a custom developed program, you have a service name that triggers your program that you can add here. For example, if after activation you want to send a custom email to users outside the workflow process you can add a custom program to do that and specify a service name that links to the program
- Conditions
Below is a screenshot of the key fields needed at a minimum for the workflow to perform a system activity based on the non user agent BRF plus decision table
For the full list of fields & settings see below
Now that you have an understanding of the 3 key BRF+ decision tables that drive the functionality and remember that the single value determines the steps which will either lead to the user agent or non user agent table for details on those steps let’s put it all together with the standard SAP example.
Tutorial of SAP MDG standard BRF+ rule based workflow
We will now walk through a tutorial on the standard SAP MDG BRF+ rule based workflow and call out the key concepts. First let’s start with the workflow itself, let’s show a flowchart diagram detailing the process. I am not going to use the business process flow which would be more detailed with business steps and less technical. In order to show the relation between the tables I will use a technical model of the workflow
As a note this is the standard workflow set up that comes out of the box with SAP MDG for the rule based workflow for material creation. I find that in practice there is better standards around how to name the different aspects of the workflow such as the condition alias but let’s start with their example and make sure we understand the key concepts. Let’s review how SAP set’s up their BRF decision tables for the workflow diagram I posted above and walk through it. First let’s take a look at the single value decision table. Remember this is the primary table that drives the actual workflow itself in terms of steps. As a note I have hidden a few columns that are not used in this workflow
Now let’s talk through how the technical diagram is set up, there isn’t a perfect way to represent these tables in a flow diagram since it’s a bit complicated but I feel the way the workflow is shown above will do the best way to represent this table. Let’s walk through the components.
- Workflow Steps: Workflow steps are represented in the workflow diagram as the key process flow components (blue or gray shapes). There are two main steps in the single value decision table, the previous step (CR previous step column) and the new step (New Chang. Req Step Column). As you can see each step has it’s own shape in the technical workflow diagram and is labeled accordingly.
- Previous Actions: Actions are shown as the first text leaving a shape along the line. So for example if you look at the step final check (90) in the technical workflow there are two lines going out from that step either activation (09) or reject (04).
- Condition Alias: Remember the condition alias is a tricky concept but it is just used to determine the assignment of a step. In the technical workflow this is modeled in the line one of the last texts right before the next step. For example, if you’re leaving the final check (90) step along the activation line the condition alias is 2.
- New CR Status: The new CR status is modeled as text along a line right before the next step of the workflow (close to the condition alias). For example, again looking at the final check step (90) if you travel along the activation line you can see there is a new CR status of Changes to be Executed (02)
Let’s take a look at the example of when the change request is in final check (90) and it is moving toward the activation step. Here I have called out below all the different aspects of the single value decision table and where it fits within the technical diagram.
The diagram represents what was described above. As a note the new step becomes the previous step when the workflow is deciding what to do next. For example, the previous step when the workflow starts is Processing (00) and the new step is Final Check (90). After the workflow reaches that new step the process starts over with the previous step being Final Check (90) and the workflow then determines the new step based on what is called out such as the previous action.
Now that we understand the single value decision table let’s move on to the next aspect of the workflow. There are two primary color systems that depict either the BRF user agent decision table or the BRF non user agent decision table
- User Agent Decision Table Steps: These are represented in a blue color called out as user activity in the legend for the workflow. Any step in blue represents a user activity and therefore will be determined by the user agent decision table. This means the condition alias must only match the condition alias in the user agent decision table and not the non user agent decision table
- Non User Agent Decision Table Steps: These steps are all represented in a gray color as system activity in the legend for the workflow. Any step in gray represents system activity (no user agent) and will be maintained in the non user agent decision table. This means the condition alias for that step must only match the condition alias in the non user agent decision table and not the user agent decision table.
Let’s look through the example to understand in more detail. Whenever we get to a workflow step we need a condition alias to tell us how to assign the step. Either to a user or to the system. Let’s take a look at the first step which is after a user submits it goes to the final check step with condition alias 1.
Now that we see the condition alias is 1 let’s check to find where the condition alias 1 is located. It would either be in the user agent decision table or non user agent decision table. If you were building this workflow you know that you want a user to perform the next step. In that case you would add in condition alias 1 to the user agent decision table. You can see below that’s what SAP did, the condition alias 1 is in the user agent table.
As a note, BRF decision tables allow you to have multiple conditions assigned to the same step. If it is expanded you can see what this means
This is stating that if the condition alias is 1 or 5 or 7 the resulting user agent group, step type, user agent type & user agent value would be the same. This is a simplification that is not necessary. You could create a row for each condition alias 1, 5 & 7 and have the same resulting steps. It is a matter of preference.
The point though is that for condition alias 1 the step type is activate change request (8) which if you look in MDG configuration would mean an activate button or a reject button. The user agent type is user and the agent value is ANZEIGER. This means for this final check step it would be performed by the ANZEIGER user (that’s their user ID in SAP) and they would have an activate or reject button.
Next let’s take a look at a step where is will go to the non user agent decision table since it is a system activity. After the the user activates a change request in the workflow it should then perform the system activity of taking data in the staging table and activating it in the active area table. As you can see after activation the condition alias is 2.
In this case since we want the condition alias 2 to be located in the non user agent decision table since we don’t want a user to perform a step but we want the system to perform a step. As we can see the non user agent decision table contains the condition alias 2
The condition alias is 2 and the process pattern is the Activation (Bypass Snapshot) (06). This is the step that tells the system to activate the data in the staging area. As a note bypass snapshot means that if there was data changes in the underlying table while the change request was in progress it ignores them and overwrites with what was in the SAP MDG staging table. As you work more with MDG the process patterns will make more sense.
Now that you understand the basic relationships between the 3 tables that drive the workflow and the technical diagram that ties it all together follow along for yourself and see if you can understand how the workflow is working end to end based on the three decision tables. For ease of use I put the technical workflow followed by the single value decision table, user agent decision table and lastly the non user agent decision table.
SAP MDG configuration that supports the rule based workflow process
So far through this post we have utilized the standard workflow from MDG that comes out of the box. SAP has included some standard configuration that allows the workflow process to function. Below I will call out what is configuration within the workflow and what is not configuration. As a note to reach all of the configuration locations utilize Tcode MDGIMG which will quickly bring up the menu for SAP MDG configuration
| Workflow Item | Used In | Configurable? | Configuration Location |
|---|---|---|---|
| Previous Step | Single Value Decision Table | Yes | General Settings-> Process Modeling-> Workflow-> Rule-Based Workflow-> Configure Change Request Steps for Rule Based Workflow |
| Previous Action | Single Value Decision Table | Yes (With Enhancement) | General Settings-> Process Modeling-> Workflow-> Define Change Request Actions |
| CR Priority | Single Value Decision Table | Yes | General Settings-> Process Modeling-> Change Requests-> Define Priorities for Change Requests |
| CR Reason | Single Value Decision Table | Yes | General Settings-> Process Modeling-> Change Requests-> Define Reasons for Change Requests |
| CR Rejection Reason | Single Value Decision Table | Yes | General Settings-> Process Modeling-> Change Requests-> Define Rejection Reasons for Change Requests |
| CR Parent Step | Single Value Decision Table | No | No configuration, this is directly entered into BRF table without reference to configuration |
| Par Agent Group No. | Single Value Decision Table | No | No configuration, this is directly entered into BRF table without reference to configuration |
| Condition Alias | All Tables (single, user, non user) | No | No configuration, this is directly entered into BRF table without reference to configuration |
| New Step | Single Value Decision Table | Yes | General Settings-> Process Modeling-> Workflow-> Rule-Based Workflow-> Configure Change Request Steps for Rule Based Workflow |
| New CR Status | Single Value Decision Table | Yes | General Settings-> Process Modeling-> Change Requests-> Edit Statuses of Change Requests |
| Expected Completion | Single Value Decision Table | No | No configuration, this is directly entered into BRF table without reference to configuration |
| Merge Type | Single Value Decision Table | No | No configuration, this is directly entered into BRF table without reference to configuration |
| Merge Parameter | Single Value Decision Table | No | No configuration, this is directly entered into BRF table without reference to configuration |
| Dyn. Agent Sel Service | Single Value Decision Table | Yes | General Settings-> Process Modeling-> Workflow-> Rule-Based Workflow-> Define Service Names for Rule Based Workflow |
| User Agt Grp No. | User Agent Decision Table | No | No configuration, this is directly entered into BRF table without reference to configuration |
| Step Type | User Agent Decision Table | Yes | General Settings-> Process Modeling-> Workflow-> Define Change Request Step Types and Assign Actions |
| User Agent Type | User Agent Decision Table | No | Defined list of values provided by SAP based on workflow |
| User Agent Value | User Agent Decision Table | No | Based on other elements in SAP such as roles, users etc. |
| Agent Group | Non User Agent Decision Table | No | No configuration, this is directly entered into BRF table without reference to configuration |
| Process Pattern | Non User Agent Decision Table | No | Defined list of values provided by SAP based on workflow |
| Service Name | Non User Agent Decision Table | Yes | General Settings-> Process Modeling-> Workflow-> Rule-Based Workflow-> Define Service Names for Rule Based Workflow |
As you can see there are a lot of moving parts that come together to create the rule based workflow. I hope this has provided a detailed overview of all the fields needed & how the decision table work to drive the workflow. If you have any questions feel free to comment below! Look out also for an upcoming post that will include a more complex example of the BRF+ rule based workflow & the limitations of what can be done through the standard workflow. Please consider subscribing below so you will be the first to know when a more complex workflow example will be provided.