User Guide PUBLIC

Document Version: 1.04.09 – 2017-01-30

SAP Decision Service Management (DSM)

Content

1 SAP Decision Service Management (DSM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Decision Service Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Using Managed Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Assigning Applications to a Managed System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
1.4 Deploying Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Secure Operation of SAP Decision Service Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Approval Workflow for Deploying or Deleting Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7 Customer-Defined Expression or Action Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.8 Multi-Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
1.9 Service Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

SAP Decision Service Management (DSM)

2 PUBLIC Content
1 SAP Decision Service Management
(DSM)

Use

SAP Decision Service Management offers solutions to overcome some of the limitations on SAP’s ABAP-
based rule engine, Business Rule Framework plus (BRFplus). It is designed as a separate add-on to an SAP
NetWeaver system, extending the capabilities of BRFplus. The rationale of SAP Decision Service
Management’s approach is that even if a system does not offer the BRFplus rule modeling tools, it may still be
capable of executing the source code that BRFplus generates for its rules. The purpose of DSM is to let you
model the rules and generate the source code for the rule objects in an up-to-date design time system, and
then to deploy the generated code to your productive systems, which may be based on a lower release of SAP
NetWeaver.

By implementing SAP Decision Service Management, you can overcome the following BRFplus limitations:

● BRFplus was introduced with SAP NetWeaver 7.0 Enhancement Package 1, and we recommend using
BRFplus with systems based on SAP NetWeaver 7.0 Enhancement Package 2 (or higher). However, many
productive systems at the customer site run on a lower release, and organizations may be reluctant to
upgrade the very heart of their systems.
● Especially bigger companies tend to split their business activities into segments that are handled by
multiple productive systems, each dedicated to a particular business aspect (for example, one system
dedicated to procurement activities, another to the CRM system, one to the SRM system, and so on). If all
of these systems use business rules, a first approach could be to add another system, namely a dedicated
BRFplus system that provides rules for all of the different business cases, segments, and business units
covered by the various systems. However, this type of landscape, with one central rule provider system,
can easily run into performance problems due to the high number of requests from the productive
systems. When this happens, a system administrator would ask for a landscape with one central business
rule modeling system acting as the single source of truth, surrounded by productive systems that should
be able to execute business rules on their own, rather than requesting rule calculations from the rule
provider system.
● The scenario with a central rule provider system receiving requests from the productive systems can have
another drawback: If a rule has not been set up properly either from a technical or a business point of view,
or if there are technical problems with the rule provider system itself, then these problems multiply with
the number of productive systems. On the other hand, a distributed approach with autonomous
productive systems can help to isolate the problem before it spreads over the entire system landscape.
● Certain business cases ask for a different system behavior based on a planned time schedule. Examples
for such business cases are decisions that have to react to legal changes that were announced in advance,
trade promotion activities for a limited period of time, and so on. Although it is possible to model such time
dependencies within the capabilities of BRFplus rules, this approach always tends to hide the time-
dependent differences in system behavior. Customers then ask for a more obvious way to react to date
and time circumstances influencing the system behavior.
● Modeling business rules with BRFplus is based on the data structures that are available in the system in
which the modeling is done. However, companies may decide to have a central SAP system that is used
for master data management, but the data that is maintained in that system is not available in systems
used for development, testing, or quality assurance. Since business rules depend strongly on master data,

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 3
 this data dependency can lead to difficulties when it comes to testing new or modified rules before they
are released for productive use.
You could try to avoid this problem by replicating the productive data in the test system. However, this
approach is likely to lead to data inconsistencies sooner or later, with the consequence of unreliable and
misleading test results. Such unreliable results are even harder to detect because, based on the initial data
replication, a test engineer would erroneously tend to think that the test environment has been well
prepared.

Implementation Considerations

Implementing SAP Decision Service Management is useful only if you are already using, or plan to use, SAP’s
ABAP-based business rules management system, BRFplus.

For the DSM system landscape, the following minimum requirements apply:

● For the design time system: SAP NetWeaver 7.3 Enhancement Package 1 SP5 or higher (SAP NetWeaver
7.3 Enhancement Package 1 SP6)
● For managed systems: SAP NetWeaver 2004 SP13 or higher

For more details on the supported releases and support packages, see the SAP Decision Service Management
installation guide.

Integration

SAP Decision Service Management is an add-on that extends the capabilities of BRFplus. BRFplus can still run
as a stand-alone tool, and it is up to you to decide for which of your rule applications you want to take
advantage of the extensions offered by DSM. On the other hand, running DSM alone without accessing
BRFplus rule content does not make any sense. DSM offers no functionality that can be used outside the realm
of BRFplus.

Features

SAP Decision Service Management offers the following features:

● With DSM, you can establish a connection between the BRFplus design time system and a remote system
(the managed system) to access data structures that reside in the managed system.
● Once you have created and successfully tested new rules, you can deploy the BRFplus function as a
service to one or multiple managed systems. The deployed services can then be called within the managed
systems. Before actually deploying a service, the system lets you perform a test deployment to find out if
everything is OK with the service.
● Once you have successfully deployed a service, you can export its source code (with or without lean trace
support). Together with the source code, an XML representation of all the BRFplus objects related to a
particular service is stored in the managed system. You use this to restore the state of the rule model to
the state it was in at the time the service was deployed.

SAP Decision Service Management (DSM)

4 PUBLIC SAP Decision Service Management (DSM)
● You can use any SAP system as a managed system, as long as it is based on SAP NetWeaver 2004
(software component SAP_BASIS 640) or higher. This enables you to implement BRFplus-driven rules
logic in a system environment that does not normally support BRFplus.
● Services can be deployed in such a way that they are effective from a specific time in the future.

Constraints

The following BRFplus expression types are not supported by DSM:

● BRMS connector
● Dynamic expression
● Step sequence
● XSL transformation

Example

Your company has set up a central master data management system, but the data that is available in that
system is not propagated to the test system in which you test new and modified rules. However, to get a
realistic impression of the system performance of a rule, you need to let it operate on the real-world data
stored in the central system.

With DSM, you enable the relevant BRFplus application that contains the new rule to access the data
structures stored in the central system. You can then conduct your functional and performance-oriented tests
in the test system while running it against the data in the central system.

More Information

1.1 Decision Service Manager

Use

The Decision Service Manager is the central administration tool for maintaining managed systems, assigning
applications to the managed systems, deploying services to the managed system, and keeping track of all
system activities related to DSM.

In a DSM system landscape, the Decision Service Manager runs in the DSM design time system. This means
that DSM has direct access to the rule modeling environment of BRFplus and the BRFplus data objects,

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 5
whereas accessing the managed systems is accomplished with the help of RFC connections pointing to the
managed systems.

Features

Maintaining Managed Systems

You define which of your SAP systems you want to use as managed systems. Making this definition is a
prerequisite for the person in charge of modeling business rules with BRFplus to get access to the data
available in the managed system, in addition to the data in the design time system.

Associating a BRFplus Application with a Managed System

You establish a connection between a managed system and one or more of the BRFplus applications residing
in the design time system. After the connection has been established, the application has access to the ABAP
Dictionary of the managed system when it comes to data binding for BRFplus data objects.

Deploying Services

From the BRFplus functions that belong to an application that has been associated with a managed system,
you select those that you want to deploy as a service in the managed system. Instead of actually deploying a
service, you can first perform a test deployment to find out if everything is alright with the function to be
deployed.

Retrieving Deployed Data

After a successful deployment, Decision Service Manager offers tools that you can use to retrieve the
deployed data from the managed system. This is helpful for quality assurance as well as for restoring or
copying the status of the involved objects in other systems.

Deployment Log

The system keeps track of all Decision Service Manager activities related to managed systems, applications,
and services. The log contains information pertaining to each of the managed systems available. The amount
of information displayed in the log can be reduced according to a time-based filter option.

Documentation

For each managed system, you can enter a descriptive text that helps users understand for which purpose a
particular managed system has been set up. The same applies for each single deployment of a particular
service. Here, the documentation field may explain the reasons why a particular service has been deployed two
or more times (for example, to react on changes in the service environment, modified use cases, and so on).

For BRFplus applications and functions, the documentation that has been maintained for these objects in the
BRFplus workbench is shown.

Technical Information

On this tab, the system displays various technical data with respect to the currently selected managed system,
such as the target system and the user ID defined in the RFC destination that is used to establish
communication between the design time system and the managed system. You can also find a list of all the
DSM-related services that are supported in the managed system and that correspond to the different features
offered in the Decision Service Manager.

SAP Decision Service Management (DSM)

6 PUBLIC SAP Decision Service Management (DSM)
Procedure

To use the Decision Service Manager, proceed as follows:

1. Log on to the SAP system serving as the design time system in your business rule modeling landscape.
2. Run transaction DSM and choose Enter.
The system opens a new browser window with the Decision Service Manager.
Once Decision Service Manager is up and running, you can add the URL shown in the browser to your
browser favorites. This allows you to run DSM without having to start the backend system first.

Note
You can also use DSM’s administrator role SAP_DSM_ADMINISTRATOR in the SAP NetWeaver Business
Client (NWBC). The role provides a menu for administrators assigned to the role.

Furthermore, an NWBC-based cockpit is available for the Decision Service Manager. To run the DSM
cockpit in the Business Client, use the following URL:

protocol://mySAPServer.corp:12345/sap/bc/nwbc/dsm_cockpit

Example:

https://mySAPServer.corp:12345/sap/bc/nwbc/dsm_cockpit

You also have the option of working with the user menu of the DSM role without the cockpit in SAP
NetWeaver Business Client.

1.2 Using Managed Systems

Use

A managed system is an SAP system in which you want to execute business rules modeled with BRFplus,
using data that is available in the database of that system. Using managed systems is the solution of choice for
the following scenarios:

● The productive, business-critical systems in your system landscape are based on SAP NetWeaver release
range between 640 and 701. With these releases, BRFplus is either not available at all, or it is not
recommended for use.
● You have a distributed landscape of multiple productive systems and want to make sure that the business
rules that are active in these systems are all in sync. The Decision Service Manager is an administrative
tool that provides an overview of the availability and the status of rule services that have been deployed to
the various systems. It also helps you deploy any service throughout the landscape.

From a technical perspective, a managed system can be seen as a set of data describing an access path from
the design time system where BRFplus rules are modeled to the productive target systems where these rules
are processed. A managed system, in this technical sense, consists of the following data:

● Technical System Name for the managed system. You define this name when you create a new managed
system. It is used for referencing the target system. Once the new managed system has been saved, this
name cannot be changed.

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 7
 Note
The System Name of the managed system must be unique within the scope of the client that you use to
logon to the managed system.

● Description: For each managed system, you can maintain a short descriptive text. For example, you may
enter the business scenario supported by a particular system in your landscape.
● RFC Destination; The technical name of the RFC destination that is used to establish a connection between
the design time system and the managed system. Note that RFC destination names are case-sensitive.

Note
There is a 1:1 relationship between a managed system and an RFC connection. Therefore, you cannot
use the same RFC connection for different managed systems. If you need to set up more than one
managed system using the same remote system, you can do this by setting up several different RFC
destinations with the same settings, and associate these functionally equivalent RFC destinations with
the managed systems.

● Documentation: You can enter a text of any length here to describe what purpose a particular managed
system serves, or what kind of services are being deployed to it.

Features

Modifying DSM Settings versus Ongoing Activities

The settings that you maintain in Decision Service Manager have a fundamental impact on the way how
business rules are modeled, and how they can be distributed in your system landscape. There is no support for
concurrent write access to the DSM settings in the design time system. In your managed system, you can
toggle between edit and display mode using the Edit or Display buttons.

As a general rule, the following applies:

● To modify DSM settings in the design time systems, you must be working in edit mode in the particular
managed system.
● As long as one user is running a managed system in edit mode, all other users can run this system in
display mode only. However, several users can work in different managed systems in edit mode at one
time.
● For ongoing activities based on the DSM settings that are currently in effect, the managed system does
not have to be in edit mode. This is because these activities may lead to changes only in the managed
systems, but not in the design time system.

Note
After having selected a system, you need to be in edit mode if you want to add or remove application
assignments of a managed system. This is because the assignments between managed systems and
applications are maintained in the design time system.

In contrast to the restrictions that are in effect for system-related settings, there are no restrictions
concerning the ongoing activities that you do on a daily basis. For example, it is not necessary to switch to
edit mode if you want to deploy a service. You can even delete an existing deployment while still being
logged on in display mode.

SAP Decision Service Management (DSM)

8 PUBLIC SAP Decision Service Management (DSM)
Accessing Dictionary Elements in the Managed System

The main purpose of using SAP NetWeaver Decision Service Management is to make business rules modeled
with BRFplus available to productive systems in which the BRFplus modeling environment cannot be used. As
a consequence, the rules to be defined must be able to access the ABAP Dictionary objects that reside in the
productive system. To do so, you set up a managed system that points to the productive system, and you
associate a BRFplus application with the managed system. Once this association has been established, you
can bind the BRFplus data objects of the assigned application to the ABAP Dictionary objects in the remote
system, rather than to the objects in the design time system.

Note
A similar mechanism is in place with respect to function modules and static methods that reside in the
remote system. This is needed for procedure call expressions that are executed in the managed system.
Here, the expression needs access to the function modules and methods in that system. Therefore, in the
design time system, the function modules and static methods that you can assign to a procedure call
expression are taken from the repository of the remote system.

Service Deployment

Once you have associated a BRFplus application with a managed system and defined the business rules based
on data from the managed system’s repository, you need to make the BRFplus rules available in the managed
system. To do so, you select a BRFplus function and deploy it to the managed system as a service. Once the
service has been deployed successfully, it can be called from within the managed system.

Technical Information

For each managed system that you maintain, the Decision Service Manager displays some technical data that
you may find useful. This data is displayed on the Technical Information tab:

Table 1:

Field Description

System ID, Client The ID and client of the managed system. The information given here is taken from the
definition of the RFC destination used to establish a connection between the design time
system and the managed system

User The ID of the user defined in the RFC destination. This user is passed to the managed sys­
tem when connecting from the design time system. For proper operation, this user must
have been granted the same authorizations as you would need to log on to the managed
system and work with BRFplus rules manually.

System Available Indicates whether the managed system can be accessed via the given RFC destination
and is currently up and running.

Unicode-enabled Indicates whether the managed system supports unicode-based codepages. Although
unicode support is not mandatory for running a managed system, it is important to take
care of this setting in order to avoid potential problems. Such problems can occur if uni­
code-based characters are used in the design time system that are not supported in the
managed system. In this case, problems can arise with respect to readability and ease-of-
use of the BRFplus content, but also with respect to correct rule execution or even to the
ability to execute a service.

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 9
Field Description

Installed Components Indicates the type of the managed system (for example, WebAS 640, SAP NetWeaver
702, and so on). When you click the link, the system displays the stack of software com­
ponents that are installed in the system.

Installed Services Displays a list of services that are related to features of the Decision Service Manager.
The contents of this list can vary depending on the release of the managed system.

Operating System Displays the operating system on which the application server of the managed system
runs.

SAP Release Displays the release of the managed system.

Database System Displays the name of the database used by the database server attached to the managed
system.

Constraints

Consequences of Deleting a Managed System

You can delete a managed system at any point in time. This includes deleting a managed system that has one
or more applications assigned, with data objects referring to the ABAP Dictionary of the managed system, and
with services that have been deployed to the managed system. The consequences of such a deletion vary,
depending on the objects involved:

● Data objects (elementary, structures, tables) that have been bound to elements residing in the ABAP
Dictionary of the managed system keep their binding information. However, a consistency check of such
an object reveals the now invalid type definition, and reactivation would not be possible.
● All expressions, functions, or other objects referring to an object with inconsistent data binding inherit the
consistency problems from the referenced objects and cannot be used until the problem is solved.
● Services that have already been deployed to the managed system remain functional. This is obvious
because inside of the managed system itself, there is by definition no problem with accessing the ABAP
Dictionary of that system.
The services themselves are disconnected from their origin (that is, the design time system of the
underlying BRFplus functions). However, as long as you know what the original system was, you can
restore the original environment by setting up a new managed system based on an RFC connection
pointing to the same system and client like the one of the deleted managed system. In the Decision
Service Manager, you can then select the new managed system to see the deployments that were made
based on the deleted managed system.

More Information

Assigning Applications to a Managed System [page 11]

SAP Decision Service Management (DSM)

10 PUBLIC SAP Decision Service Management (DSM)
1.3 Assigning Applications to a Managed System

Use

Assigning a BRFplus application to a managed system is a prerequisite to make BRFplus business rules
available to the managed system. Once an application that is located in the design time system has been
associated with a managed system, the BRFplus data objects can be bound to elements from the ABAP
Dictionary in the managed system, rather than in the design time system. This means BRFplus functions can
be deployed and executed as a service in the managed system.

You can assign as many applications to a managed system as you need. However, each BRFplus application
can be assigned to only one managed system.

Prerequisites

The managed system is based on SAP NetWeaver 2004 or higher.

Activities

Assigning an Application to a Managed System

To assign an application to a managed system, proceed as follows:

1. In the Decision Service Manager, select the managed system you want to use.
In the lower part of the screen, the system completes the Deployment, Applications, and Technical
Information tabs with data.
2. Choose Edit.
3. On the Applications tab, choose Add to associate an existing BRFplus application with the managed
system, or choose New to create a new application and associate it with the managed system.

Note
When you decide that you want to assign an existing application, the search dialog opens and lets you
refine your selection. The system ensures that the result list contains only applications that have not
already been assigned to a managed system. If you think a particular application is missing in the result
list, it has most likely been assigned to a managed system already. To clarify the situation, start the
BRFplus workbench, navigate to the application in question and check whether assignment already
exists. If an assignment already exists, the icon indicates this in the title row of the work area.

4. Once you have established the association, choose Save.

Note
If you assign an application to a managed system while the BRFplus workbench is already running in
another browser window, the workbench does not immediately recognize this assignment. To make the

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 11
 workbench aware of the new assignment, you need to save any pending changes and then restart the
BRFplus workbench.

Accessing ABAP Dictionary Elements in the Managed System

To bind a BRFplus data object to an ABAP Dictionary element in the managed system, proceed as follows:

1. Open the BRFplus workbench and navigate to the application that you have associated with the managed
system.
2. Make sure that in the title row of the work area, the managed system indicator is visible (between the
application status indicator and the word Application).
3. Navigate to a data object (element, structure, or table), or create a new one.
4. Set up a data binding between the BRFplus data object and an ABAP Dictionary element.
The ABAP Dictionary elements offered by the system are those residing in the managed system, not in the
local design time system.
5. Save your settings, check, and activate the data object.

More Information

1.4 Deploying Services

Use

Deploying services means that you transfer the ABAP OO classes and methods that have been generated for a
BRFplus function in the design time system to the managed system that is associated with the application to
which the function belongs. After a successful deployment, the functionality that you have implemented
during rule modeling in the BRFplus workbench is available as a service in the managed system. Here, any
local report or function module can access the service by simply calling the relevant class methods.

Features

Deployment Test

Once you are done with modeling a business rule in the BRFplus workbench, you need to deploy it to the
managed system to make it available for execution in that system. It is a good idea to check in advance
whether everything is OK with the systems involved. To do so, use the Deployment Test function. The test
checks whether the business rule itself is OK and the managed system is available. If the test is successful, you
can choose to proceed directly with the real deployment of the service.

Automatic Prevention of Duplicate Deployments

SAP Decision Service Management (DSM)

12 PUBLIC SAP Decision Service Management (DSM)
If a rule service has already been deployed successfully to a managed system, there is no need to repeat this
deployment. Moreover, depending on your business, it can even be legally required to keep business-critical
components unchanged unless a change is needed for business reasons. Apart from that, in daily business, it
can sometimes be difficult to have a complete overview of which service has been deployed in which status to
which system. Although it is possible to find the information needed to clarify the deployment status, this can
be tedious. You may find it much easier to simply click the Deploy button once again. The system then helps
you to avoid unneccessary deployments by running through the following steps:

1. In the design time system, check whether code has already been generated for the BRFplus function to be
deployed as a service:
○ No generated code available: Generate code.
○ Code available: Check whether the function time stamp is newer than the code time stamp:
○ Function is newer: Generate code.
○ Function is older: Keep the existing source code.
2. In the managed system, check whether the service has already been deployed:
○ Service has been deployed: Check whether the deployment ID is the same as in the design time
system:
○ Deployment ID is identical: No deployment necessary – exit.
○ Deployment ID is not identical: Deactivate deployed service and start a new deployment.
○ Service has not been deployed: Start a new deployment.

Note
Be aware that this check can fail under the following circumstances: If the managed system receives
service deployments from more than one design time system for the same service, it is not possible to
provide deployment IDs that are unique across system boundaries. In this case, we recommend
deciding on one design time system that is used for deploying that service.

Managing Different Deployments of the Same Service

Multiple Deployments

Once you have successfully deployed a service for the first time, the respective source code is automatically
activated in the managed system and can be used from that point in time. However, sooner or later the
underlying rule model may have to be changed. When that happens, you select the changed function in
Decision Service Manager and deploy it again into the managed system.

This results in a new entry in the list of deployments for that particular service. Again, the new version is
automatically activated, and the Valid To field of the previous deployment is changed from Unlimited to the
value of the Valid From field of the new deployment, minus one second.

Retrieving Outdated Deployments

If there are multiple deployments for a service, only the source code of the newest deployment is active in the
managed system. If, for whatever reason, you need to retrieve an older version of the service that has been
deployed in the past, there is no way of simply selecting and reactivating the older deployment. However,
restoring an older version is possible with the following procedure:

1. In the Decision Service Manager, select the deployment you want to retrieve.
2. Choose Retrieve Source Code or Retrieve Source Code with Trace .
The system retrieves the source code that has been deployed with the selected deployment and prompts
you to save it as a local text file. The difference between the two options is that during the deployment,

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 13
 code has been generated for the deployed service in two flavors, namely with and without trace support.
The two options let you decide which of these versions you want to retrieve.
3. Choose Retrieve XML .
The system retrieves the XML representation of the BRFplus rule objects involved in the deployment and
prompts you to save it as a local XML file.

You can now check the files exported from the managed system. If you decide to restore the older version,
import the XML file to the BRFplus workbench in the design time system (note that this will overwrite the
current version). Then repeat the deployment of the function as a service.

Note
Retrieving the source code from the managed system is technically not needed to restore a particular
version of a service. However, in most cases you will find it helpful to analyze the deployed source code, so
downloading the source code is meant as a means to make troubleshooting easier.

You can also use the Source Code, Source Code with Trace, and XML retrieval functions for your current
deployments.

Deleting Deployments

If the list of deployments for a service has grown too long, and if you are sure that the deployments before a
certain point in time will never be used again, you can delete the older deployments. To do so, proceed as
follows:

1. In the Decision Service Manager, select the service for which you want to delete older deployments.

2. In the Actions column, choose .

The system opens a dialog in which you can specify the deletion criteria.
3. Choose from different predefined time frames, or define an individual cutoff date.
4. Choose OK.

The system deletes all of the data that is related to the service deployments that fall into the specified time
frame. The deployment that was active at the cutoff date is kept in the system, with its activation date adjusted
to the cutoff date.

Technical Aspects of Service Deployment

Transport

You deploy a service from one system to another using the RFC connection that you have defined during the
setup of the managed system to which you want to deploy. DSM deployments make no use of the SAP Change
and Transport System. This is because data transfer via an RFC connection is very easy and lets you bypass
the transport schedule that is in effect for your system landscape. In many organizations, this transport
schedule is unflexible and allows changes only in long intervals, which, in many cases, can be inappropriate
when you have to react quickly to changes in your business environment.

Lean Trace Support

As already mentioned, deploying a service means transferring ABAP OO classes from the design time system
to the managed system. In fact, for each BRFplus function that you deploy, the system transfers two classes:
One class with the lean trace enabled, the other one without lean trace support. Deploying both versions is
necessary because the use case in the productive system can change at any time and may or may not need
lean trace support. There is no way for the managed system to pull a different deployment from the design

SAP Decision Service Management (DSM)

14 PUBLIC SAP Decision Service Management (DSM)
time system, so both versions must be present. In the managed system, there are routines available that
automatically detect which of the two versions must be executed.

Note
The fact that each single service consists of two classes, which are identical to a large extent, can lead to
the effect that in case of errors, certain error messages may be displayed twice. However, once the problem
has been solved in the BRFplus workbench, both error messages disappear at once.

Naming

The ABAP OO classes that are transferred to the managed system during deployment must have a unique
technical name to ensure that no conflicts with existing classes can arise. DSM creates class names starting
with the reserved namespace /FDT/, followed by an automatically generated UUID for this purpose. All
classes related to service deployments are assigned to the special $TMP package that exists in every SAP
system. This package is reserved for objects that are not meant to be transported to any other system in the
system landscape.

Activities

To deploy a BRFplus function to the managed system as a service, proceed as follows:

1. In the Decision Service Manager, select the managed system you want to use as deployment target.
The system populates the list in the lower screen area with the deployments that have already been made
to the selected system.
2. Choose Deploy.
The system displays the object search dialog, with the Object Type restricted to Function.
3. Specify the search criteria and perform the search.
4. From the result list, choose the function you want to deploy as a service.
5. The system prompts you to enter an optional comment as deployment documentation. In the same dialog
box, you can decide whether you want to activate the service immediately after deployment, or if
activation shall take place at a particular time in the future.
6. To start the deployment, choose Deploy.

Result

The system displays messages to inform you whether the deployment was successful. In case of success, the
deployed service is now ready for use in the managed system.

More Information

Secure Operation of SAP NetWeaver Decision Service Management [page 16]

Approval Workflow for Deploying or Deleting Services [page 18]

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 15
1.5 Secure Operation of SAP Decision Service Management

Use

Using SAP Decision Service Management (DSM) basically means setting up a system landscape that is
optimized for applications using business rules modeled with BRFplus. In other words, using DSM is the task of
a system administrator, and it involves data exchange between different systems in your landscape on a
regular basis, including your systems for productive use. The following sections describe the security-related
aspects of using DSM.

Integration

The authorization objects described in the Features section below are assembled in the predefined user role
Decision Service Manager: Administrator role (SAP_DSM_ADMINISTRATOR) that is shipped with SAP Decision
Service Management.

Note
In addition, using DSM also requires that the user is assigned to the SAP_FDT_BC_ADMINISTRATOR role
that is shipped with BRFplus.

Features

Authorization Objects

The different activities that you can carry out in DSM are covered by the SAP authorization concept. This
means that you can assign different access rights to managed systems and deployment activities to the
people who work with DSM. The following authorization objects are related to DSM operation:

Table 2:

Authorization Object Description

DSM_MS You use this authorization object to control the activities that a user is allowed to perform with
respect to managed systems and service deployment, including the authorization to run the
central DSM administrative tool, the Decision Service Manager. The authorization object pro­
vides a detailed list of different activities for which you can decide whether a user shall be
granted authorization.

FDT_BRS_MS You use this authorization object to control the decision service deployment from the design
time system into the associated managed systems. In addition, you can control user access
to the deployed decision service code in different formats.

SAP Decision Service Management (DSM)

16 PUBLIC SAP Decision Service Management (DSM)
Authorization Object Description

FDT_BRS_VA You use this authorization object to control which dictionary types a decision service may ac­
cess (data elements, structures, tables).

Caution
For the secure operation of SAP Decision Service Management it is crucial to properly maintain and assign
the authorization objects and roles mentioned above. Since service deployment with DSM does not rely on
the SAP Change and Transport System (CTS), it is not sufficient to restrict the authorizations related to
that area. The CTS authorization concept is not relevant for service deployment with DSM.

Authorization Objects: System Reference

When using DMS, you are operating different types of systems, namely the central design time system and the
managed systems. The authorization objects mentioned above are relevant for the following system types:

Table 3:

System Authorization Object

Design Time System DSM_MS

Managed Systems ● FDT_BRS_MS

● FDT_BRS_VA

Trusted Relationship Between Systems

Using DSM always implies having a system landscape where one design time system communicates with one
or more managed systems. Here, the term communication stands for service deployment into the managed
systems. This means that executable source code is transferred from the design time system to the managed
systems. Since the managed systems are set up as business-critical, productive systems, it is necessary for
involved systems to have established a mutual trusted relationship. This is accomplished by exchanging the
public keys of the security certificates that are installed in the involved systems. By doing so, the integrity of
the exchanged data is guaranteed. For more information, see the SAP Decision Service Management
Installation Guide. Systems that have not passed their public key to the managed system cannot deploy any
BRFplus-related services to that system.

Lock Concept for Decision Service Manager

The Decision Service Manager is the central administrative tool of DSM and works on managed system level.
The settings that you make in this tool must reflect precisely the status of your system landscape, and the
proper association of an application with a particular managed system is crucial for the correctness of the
services that are modeled within that application. Changes made in Decision Service Manager can have far-
reaching effects on your company’s business. Therefore, running Decision Service Manager in editing mode is
restricted to one session per managed system. As long as the session for a managed system is running, all
other users can run the tool for this particular managed system only in display mode. This is to prevent
concurrent changes to the same objects and the potential problems that may arise.

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 17
1.6 Approval Workflow for Deploying or Deleting Services

Use

This sections describes how you enable an approval workflow for deployment or deletion of services.

Activities

Deployment

To enable an approval workflow for deploying services, proceed as follows:

1. Run transaction SWE2.

2. Activate an event type linkage for ABAP class CL_FDT_DSM_WFL and event DSM_WORKFLOW_START.
○ In the Receiver Type field, you can specify your own workflow template.
○ In the Receiver Call field, you can use receiver function module SWW_WI_CREATE_VIA_EVENT_IBF.
3. Select the Linkage Activated indicator.
Once activated, DSM automatically replaces the Deployment button with a button that allows you to start
the approval process.

Example
SAP provides the following templates as examples:

● WS68100003: Simple approval step

● WS68100004: Approval step that checks whether the document has changed

Deletion

To enable an approval workflow for deleting services, proceed as follows:

1. Run transaction SWE2.

2. Activate an event type linkage for ABAP class CL_FDT_DSM_DEL_WFL and event
DSM_DEL_WORKFLOW_START.
○ In the Receiver Type field, you can specify your own workflow template.
○ In the Receiver Call field, you can use receiver function module SWW_WI_CREATE_VIA_EVENT_IBF.
3. Select the Linkage Activated indicator.

Example
SAP provides template WS68100005 as an example.

For more information about approval workflow options, see the Modeling Workflows documentation in the SAP
NetWeaver Library on SAP Help Portal.

SAP Decision Service Management (DSM)

18 PUBLIC SAP Decision Service Management (DSM)
1.7 Customer-Defined Expression or Action Types

Use

Although BRFplus provides a set of action and expression types such as decision tables, formulas, message
logs, you may want to develop your own action or expression types for the following reasons:

● Functionality not (yet) available

BRFplus action and expression types do not provide special features that you may need for your scenario.
Very often this is true for action types because actions are usually more dependent on a specific
environment.
● User Interface Simplification
Generic BRFplus action and expression types may provide too many features, making the UI more
complex than required in specific use cases.
● Compound Action and Expression Types
You can combine several expression types or action types into one compound type that allows better UI
usability and integration

This section describes how you activate your own expression types or action types in the DSM scenario.

Prerequisites

For your defined expression or action types, you have a working implementation for the generation mode with
no switch to interpretation mode.

Activities

1. Redefine method IF_FDT_EXPRESSION~GET_DSM_AVAILABILITY.

2. Define the release from which you want to start supporting your own expression or action types.
To do so, specify the start release you want in the returning parameter.
When you want your defined expression or action type to be available from SAP_BASIS 7.02, simply enter
702 in the field for the returning parameter. Now all managed systems with a NW release equal to or
greater than NW 7.02 will support your expression type.

METHOD if_fdt_expression~get_dsm_availability.
rv_start_release = 702.
ENDMETHOD.

Note
You can only define a start release, and all higher releases then have to support your expression or action
types. You cannot define gaps for releases that do not support your own defined expression or action types.

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 19
 Caution
You as owner of your defined expression or action types are responsible for ensuring that the generated
code works correctly in the managed system and does not have any syntax errors.

1.8 Multi-Deployment

Use

This section describes how to deploy one or more services to one or more managed systems. Multi-
deployment enables you to make sure that a given service is deployed to all relevant systems in your system
landscape. In this way, you can ensure that the service in question works in a consistent manner in all of the
systems in your landscape. If the changes contained in a service to be deployed take effect at a particular time
(for example, because you are planning a sales promotion campaign for a limited time), you can define that the
service is activated with a user-defined delay.

Synchronized Activation of Deployed Services

When you deploy a service in a complex system landscape with multiple target systems (maybe even
distributed around the globe), ensuring that the deployed service is activated at the exact same time in all
target systems becomes a challenge. Some of the systems may be temporarily unavailable for numerous
reasons (hardware failure, regular system shutdown for maintenance reasons, poor network connection,
changed logon policy, and so on). You can specify that DSM automatically ensures that after a service
deployment has taken place, all of the affected systems listen to each other so that the service is activated
simultaneously in all systems. In addition, you can define any point in the future to be used as the moment of
activation. This is useful for all kinds of planned changes in system behavior, such as a year-end sales
campaign, an adaptation of previously announced legal changes that influence your business, and so on.

Example
You are running a web shop on a cluster of four identical systems that are controlled by a load balancing
system. You have implemented new discount logic for orders that add up to a total of more than 100 Euros.
With multi-deployment, you select the changed service, the four systems, and start the deployment. The
deployment logic inherent in DSM makes sure that the changed business logic takes effect in all of the
systems in the cluster at the same time. This guarantees that your customers can take advantage of the
new discount regardless of the system to which the load balancer has routed them after system logon.

Deployment Documentation

When you deploy a service to your system landscape, it is quite normal that you are doing so to apply changes
to the processes that make up your business. Therefore it is a good idea (and in certain use cases it may even
be legally compulsory) to take some notes about the purpose of a particular deployment, or about the
underlying business decisions that were executed by performing the service deployment. This kind of
documentation makes it easy for interested parties to understand the motivation for each deployment at a

SAP Decision Service Management (DSM)

20 PUBLIC SAP Decision Service Management (DSM)
later time. As a result, DSM gives you the opportunity to enter your comments whenever you are about to start
a new deployment.

Prerequisites

You have installed SAP Note 1858436 .

Activities

1. In the Decision Service Manager, choose Multi-Deployment.

The system displays the Multi-Deployment screen.
2. Add the services or managed systems you want to deploy:
○ To add services, under Decision Services, choose Add and select the relevant services.
○ To add managed systems, under Managed Systems, choose Add and select the relevant systems.

Note
You need to select at least one service and one managed system to continue.

3. To start the multi-deployment workflow, choose Deploy.

Note
Depending on the system settings, the button label may read Start Deployment Workflow instead of
Deploy. This indicates that for the current system, the deployment approval workflow is in effect. This
means that service deployments are not performed immediately after you have clicked the start button.
The actual deployment depends on an approval decision made by a person with proper authorization.

The system displays the Deploy Function screen.

4. In the Documentation field, enter your deployment documentation.
This documentation is then valid for each deployment in your scenario.
5. Under Activation Time, specify when your services are to be activated:

Table 4:
Option Description

Immediate Deployment Activates all deployed services immediately after import into the managed
systems.

As of Date/Time Activates all deployed services on the date and time you specify.

All services simultaneously This option is recommended when you want to make sure that all of the serv­
ices in all your systems are updated at the same time . The system deter­
mines the point in time which is at least one hour in the future.

6. To start the deployment or the deployment workflow, choose Deploy.

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 21
1.9 Service Import

Describes how to integrate services that already exist in different systems into the Decision Service Manager.

Use

The rationale of working with SAP NetWeaver Decision Service Management is to start with one central
repository of services residing in the DSM system ("single source of truth") and to deploy these services to the
managed systems in your system landscape.

However, in a real-world scenario, you will often find that there are valuable and fully functional services in the
managed systems that do not exist in the central DSM system. Here are some examples of how such
inconsistencies may arise:

● Legacy services that already existed in the managed systems before these systems were integrated into
the DSM deployment landscape.
● Services that have been created locally in a managed system for testing or simply by accident.
● Services that have been properly deployed from the DSM system, but have been deleted in the DSM
system after deployment.

You use the Service Import tool to consolidate the services that are available in various managed systems with
the service repository of the central DSM system, or to transfer services that have already been defined in
BRFplus (without the DSM extensions) into a DSM system that has been set up anew. To accomplish this, you
select the services in a managed system that you want to import into the DSM system, and the import tool
then imports the selected service.

Prerequisites

● If the described functionality is not available in your system, depending on the release status of both your
DSM system and the managed systems, you have to apply one or more SAP notes as described in SAP
note 1784597 .
● Your managed system runs on SAP NetWeaver 7.02 or higher.

Activities

To use the Service Import tool, proceed as follows:

1. In Decision Service Manager, in the list of Managed Systems, select a system based on SAP NetWeaver
7.02 or higher.
The system displays the Service Import tab in the Details section. If the Service Import tab does not
appear, this indicates that the system you have selected is based on an SAP NetWeaver release lower than
7.02.

SAP Decision Service Management (DSM)

22 PUBLIC SAP Decision Service Management (DSM)
2. On the Service Import tab, enter a search string into the Search field.
The search string you enter is compared with the technical name and the description of the available
services. You can use the '*' and '+' wildcard symbols.
3. To see the matching services, choose Search for Active Services or Search for Inactive Services,
respectively.

Note
The result list displays a maximum of 50 services. If there are more matching services available, the system
displays a message to make you aware of that. It is then up to you to refine the search criterion so that the
number of results fits into the maximum number of result list entries.

When you search for inactive services, the system displays them for information purposes only. You cannot
import inactive services into the DSM system.

Result

For each service in the search result list, the system displays the following details:

Table 5:
Column Content

Actions Offers a link to start the import of the service.

Service Name Technical name of the service.

Service Description Service description as maintained in Decision Service Man­

ager.

Application Name Technical name of the BRFplus application to which the

service belongs.

Application Description Application description as maintained in Decision Service

Manager.

State Indicates whether the service already exists in the DSM sys­
tem or not. If it does, importing the service from the man­
aged system will overwrite the already existing service in the
DSM system. For checking the existence of a service in the
DSM system, the system relies on the object ID of the serv­
ice as it has been assigned automatically upon creation of
the service function in BRFplus.

Import Options

As soon as you click the Import icon in the Actions column, the system presents you a dialog with different
options for the import to be performed. These options are:
Import Type

● Standard: With this option, the service is imported. If a service with the same ID already exists in the DSM
system, it will be overwritten by the imported service.

SAP Decision Service Management (DSM)

SAP Decision Service Management (DSM) PUBLIC 23
● Local Copy: With this option, the service is imported and stored as a local copy in the DSM system. You
can then decide at a later point in time if the already existing service shall be overwritten by the imported
one.
● Assign application to managed system: With this option set, the system assigns the service to the
managed system from where you are about to import it into the DSM system. This is useful if the service
needs access to ABAP Dictionary objects that are present in the managed system but not in the DSM
system. Services making use of objects from other BRFplus applications always need to be imported with
this option set.

When you have made your settings, start the import by choosing Import from Managed System. The system
displays the success or failure message in the message area of the DSM workbench. In addition, the system
makes you aware of differences in the scope of features due to different releases of the involved systems:

● If the source system has a higher release than the DSM system, you must be aware of the possibility that
the imported service makes use of features that are not available in the DSM system. Therefore, we highly
recommend that you make sure that after the import, the service still works as expected.
● If the source system has a lower release than the DSM system, you may decide to enhance the imported
service by features that are available in the DSM system but not in the source system.

Importing an entire application

Often, you may find it helpful not only to import a mere service into the DSM system, but also the entire
application to which the service belongs so that you have all the relevant design time objects available to make
further improvements to the service, or corrections, if necessary. The following process takes into account
that some of the objects may rely on system resources that are only available in their current system (for
example, Dictionary objects or Repository objects like function modules and classes). To avoid any possible
import errors, the process follows an iterative approach. Proceed as follows:

1. Log on to the managed system from where you have already imported the service.
2. In the BRFplus workbench, choose Tools XML Export .
3. Export the application object alone, without any objects that belong to it.
4. Log on to the DSM system.
5. In the BRFplus workbench, choose Tools XML Import .
6. Import the application into the DSM system.
7. In the Decision Service Manager, select the managed system from which you have exported the
application.
8. Assign the previously imported application to the managed system. This is to let the application access
resources that reside in the managed system.
9. Switch back to the managed system and export the application once again, but this time together with all
objects that belong to the application.
10. Import the second export into the DSM system.

Note
If you are sure that the objects in an application that you want to import do not use any Dictionary or
Repository resources whatsoever, you may of course skip the preparatory import of the empty application
and start with the complete application right away.

SAP Decision Service Management (DSM)

24 PUBLIC SAP Decision Service Management (DSM)
Important Disclaimers and Legal Information

Coding Samples
Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system
environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP
intentionally or by SAP's gross negligence.

Accessibility
The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be
a binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however,
does not apply in cases of willful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations
of SAP.

Gender-Neutral Language
As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as
"sales person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun
does not exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.

Internet Hyperlinks
The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does
not warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any
damages caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for
transparency (see: http://help.sap.com/disclaimer).

SAP Decision Service Management (DSM)

Important Disclaimers and Legal Information PUBLIC 25
go.sap.com/registration/
contact.html

© 2017 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP SE
or an SAP affiliate company. The information contained herein may
be changed without prior notice.
Some software products marketed by SAP SE and its distributors
contain proprietary software components of other software
vendors. National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company
for informational purposes only, without representation or warranty
of any kind, and SAP or its affiliated companies shall not be liable for
errors or omissions with respect to the materials. The only
warranties for SAP or SAP affiliate company products and services
are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein
should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered trademarks
of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the
trademarks of their respective companies.
Please see http://www.sap.com/corporate-en/legal/copyright/
index.epx for additional trademark information and notices.