sap decision service management (dsm) · pdf file1 sap decision service management (dsm) ......

User Guide PUBLIC

Document Version: 1.04.09 – 2017-01-30

SAP Decision Service Management (DSM)

Content

1 SAP Decision Service Management (DSM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Decision Service Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Using Managed Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Assigning Applications to a Managed System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.4 Deploying Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5 Secure Operation of SAP Decision Service Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.6 Approval Workflow for Deploying or Deleting Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.7 Customer-Defined Expression or Action Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.8 Multi-Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201.9 Service Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 P U B L I CSAP Decision Service Management (DSM)

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) P U B L I C 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.



● 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,


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.



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.

NoteYou 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.


NoteThe 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.

NoteThere 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.

NoteAfter 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.



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.

NoteA 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 system 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 unicode-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.


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 components 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]



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.

NoteWhen 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.

NoteIf 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


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



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.

NoteBe 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,


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.

NoteRetrieving 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



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.

NoteThe 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]


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.

NoteIn 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 provides 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.



Authorization Object Description

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

CautionFor 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.


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.

ExampleSAP 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.

ExampleSAP 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.



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) availableBRFplus 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 SimplificationGeneric 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 TypesYou 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.

NoteYou 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.


CautionYou 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.

ExampleYou 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



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.

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

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

NoteDepending 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 services in all your systems are updated at the same time . The system determines the point in time which is at least one hour in the future.

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


http://help.sap.com/disclaimer?site=https://launchpad.support.sap.com/#/notes/1858436

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.



http://help.sap.com/disclaimer?site=https://launchpad.support.sap.com/#/notes/1784597

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.

NoteThe 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 Manager.

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 system or not. If it does, importing the service from the managed 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 service 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.


● 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.

NoteIf 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.



Important Disclaimers and Legal Information

Coding SamplesAny 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.

AccessibilityThe 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 LanguageAs 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 HyperlinksThe 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 P U B L I C 25

http://help.sap.com/disclaimer/

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.

https://go.sap.com/registration/contact.html

https://go.sap.com/registration/contact.html

http://www.sap.com/corporate-en/legal/copyright/index.epx

http://www.sap.com/corporate-en/legal/copyright/index.epx

sap decision service management (dsm) · pdf file1 sap decision service management (dsm) ......

Documents