Learn how to apply best practices in business process model and notation (BPMN) for integrating rules into your process models. See how to apply these best practices with SAP NetWeaver Business Process Management (SAP NetWeaver BPM). Although an explicit rules activity is missing in SAP NetWeaver BPM’s modeling palette, you can use the mapping activity for this purpose. By invoking the ruleset as a standard function, it is possible to tightly integrate the ruleset without the overhead you typically face if you are invoking the rules by Web services. With that, you can decide for yourself which way you want to integrate rules into your business processes.
Key Concept
SAP NetWeaver Business Process Management (SAP NetWeaver BPM) and SAP NetWeaver Business Rules Management (SAP NetWeaver BRM) (both part of SAP NetWeaver Composition Environment) are complementary technologies. SAP NetWeaver BPM is focused on the modeling and execution of business process model and notation (BPMN)-based processes whereas SAP NetWeaver BRM cares about externalizing business logic that can be expressed in the form of if-then-else rules or decision tables. Both are key technologies in service-oriented architectures and help companies flexibly adapt applications to their particular needs.
There are different options for integrating business rules into processes built with SAP NetWeaver Business Process Management (SAP NetWeaver BPM). SAP NetWeaver Business Rules Management (SAP NetWeaver BRM) and SAP NetWeaver BPM, which are both part of SAP NetWeaver Composition Environment, fit together perfectly. On one hand is a tool for flexibly creating and executing collaborative business processes based on the standard business process model and notation (BPMN). On the other hand is a technology for handling rules-based business logic that can be easily adapted during runtime as your business requires it. The technologies complement each other and increase their usefulness if used in combination, so how should they be combined? You have three options:
- Calling business rules out of an automated activity as a Web service
- Calling business rules directly out of a gateway
- Calling business rules directly out of a mapping activity
Option 1 is the typical service-oriented architecture (SOA) approach: the business rule is service enabled and called via Web services by an automated activity. This approach is recommended if the rules should be reused by more than one business process. In this case, you typically develop your rules in a dedicated rules project, make the rules available as a Web service, and consume them in several projects (not only business process projects). Although this is a valid approach, you have to pay a price for it: a performance penalty for the Web service overhead.
Options 2 and 3 are used in case the rules only make sense in the context of the business process you are going to model. In this case, the overhead of creating a Web service for the rules doesn’t make much sense. Instead, you want fast invocations and a lean method of integrating the rules in your business process. The only question is: How should you integrate them? Although possible, it is not recommended that you call the rules directly out of a gateway. The reason is that the reader of the BPMN diagram is not aware of the additional complex logic being executed by the gateway. Gateways should only split or join the process flow. They should not take over any activities that are better modeled explicitly, and using a ruleset to drive a decision is certainly an activity that is noteworthy. As a rule of thumb, if you want to model something in BPMN that drives a decision, then model it explicitly as an activity followed by an exclusive gateway. Never hide activities behind a gateway. Keep in mind: Gateways never execute anything.
Having said this, it becomes obvious that the recommended approach for integrating rules is to call the ruleset out of an activity — but, which activity is appropriate? BPMN 2.0 explicitly foresees a business rule task for these kinds of activities. However, the latest version of SAP NetWeaver BPM doesn’t support this new task (yet). What should you do to be prepared for the future? The answer: Make use of the new mapping activity that is part of the latest SAP NetWeaver BPM release. I will show you how to achieve this.
In my SAPexperts article “SAP NetWeaver Business Rules Management: Externalize Critical Business Logic for Enhanced Flexibility,” you learned how to model rules by importing an XSD file on which the rules relied. This approach makes sense if you want to develop standalone rulesets. In contrast to that, the new use case requires that the rule be tightly integrated within the process. For this scenario, it makes sense to define the variables for the rules as well as the signature of the associated function that can be called from the process engine directly within the ruleset. This is how it works:
Step 1. I assume that you have defined a new process composer development project. In the Composite Designer, you can simply achieve this by dragging and dropping the Process icon from the palette into the Process area (Figure 1). For more details about working with the Composite Designer and how to create process models, take a look at my SAPexperts article "Composite Designer and SAP NetWeaver Business Process Management Minimize Composite Application Development Efforts."

Figure 1
Create a new process in the Composite Designer
Figure 2
Figure 2
The process composer development project in more detail
Figure 3
Figure 3
Create a ruleset with the New Flow Ruleset wizard
Figure 3Note also the Collection column of the table. For each parameter, you can decide whether it is a single value field or a collection of fields. Finally, you can rearrange the order of the parameters by using the Up and Down buttons adjacent to the table. Once you are done with your parameters click the Finish button to proceed.
Step 4. A new tab strip for your newly created ruleset opens (Figure 4). In the Signature section, you see a summary of the settings you entered in the New Flow Ruleset wizard. You can still make changes to your signature if you want. Recognize the error marker beneath the Result drop-down list. The associated error message tells you that you have defined the return type, but you haven’t assigned to it a concrete parameter that actually represents the return parameter. As I indicated in my description above, the assignment of the return parameter has to be done in a separate step.

Figure 4
The Overview page of your newly created ruleset
Figure 5
Figure 5
Assign the Result field from the identically named drop-down list
Note
It is important to emphasize that if you do not correctly define the return type in the rule set and determine the cardinality of the field, and then choose the dedicated variable correctly, the final step does not work properly. Be sure to read these steps closely and follow them carefully.
From now on you can model your rules as you need. This is beyond the scope of this article. If you need an introduction to rules modeling, I recommend the SAP NetWeaver Business Rules Management article I referenced earlier, as well as “Flow Rulesets: Take Control Over Your Rule’s Execution Sequence.”
Step 5. Once you have finished your rules modeling exercise, you can integrate the ruleset as part of your process model using the mapping activity. Drag and drop the Mapping activity from the Palette somewhere into the process model. Ideally, you drag it directly onto a connecting line between activities and events (Figure 6).

Figure 6
Dragging the Mapping activity into the process model
Here is how it works: Right-click the Mapping activity and choose Properties from the context menu. The Properties tab opens beneath your process model — here, click Mapping. What you see is the mapping editor displaying your process context on both sides (Figure 7).

Figure 7
The mapping editor for the mapping activity
Figure 8
Figure 8
Expression editor opened for the approvalNeeded field
Figure 9
Figure 9
Calling the ruleset with parameters taken from the process context
Figure 10
Figure 10
Setting the approvalNeeded field by calling the ruleset with parameters filled by the process context
Figure 11
Figure 11
Explicit modeling of the ruleset, reacting to the result by using a gateway
The conditions for the Yes and No gates of the gateway are pretty obvious: The No gate is set as default, whereas the Yes gate relies on the value true in the approvalNeeded field.

Dr. Volker Stiehl
Prof. Dr. Volker Stiehl studied computer science at the Friedrich-Alexander-University of Erlangen-Nuremberg. After 12 years as a developer and senior system architect at Siemens, he joined SAP in 2004. As chief product expert, Volker was responsible for the success of the products SAP Process Orchestration, SAP Process Integration, and SAP HANA Cloud Integration (now SAP HANA Cloud Platform, integration service). He left SAP in 2016 and accepted a position as professor at the Ingolstadt Technical University of Applied Sciences where he is currently teaching business information systems. In September 2011, Volker received his Ph.D. degree from the University of Technology Darmstadt. His thesis was on the systematic design and implementation of applications using BPMN. Volker is also the author of Process-Driven Applications with BPMN as well as the co-author of SAP HANA Cloud Integration and a regular speaker at various national and international conferences.
You may contact the author at editor@SAPpro.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.