SAP Basis Tech Supports

Symptom

You want to restrict access to message payloads in message monitoring for adapter engines to certain types of messages, e.g. excluding special interfaces or including only messages from a certain sender.
Other terms

Runtime Workbench, RWB, Message Display Tool, MDT
Reason and Prerequisites

You have to create your own actions and group them to roles as described in the solution.
Solution

The solution described here, is not a general available part of our software. If you want to use it, please, contact SAP for further information.
You have to execute the following steps:
1. Define your own actions2. Group them to roles3. Create an XML document containing the definitions of 1 and 2.4. Deploy it to your server5. Modify the Exchange profile, such that the custom actions and roles are used.6. Assign the roles to users or groups

These steps are described in the following:
1. An action is identified by its name. It contains one Permission, which is defined by a permission class, a name and its value. The action is defined in the XML syntax like:



a) The permission class is always ‘com.sap.aii.mdt.util.MonitoringPermissionExt’.b) The name of a Permission is used to specify a class of XI Messages for which this Permission applies. It’s a comma separated list of attribute-operator-value triplets.The Attribute gives one of the header attributes of an XI Message. Valid attributes are:
partyName, partyAgency, partySchema, service, interfaceName, interfaceNamespace, senderPartyName, receiverPartyName, senderPartyAgency, receiverPartyAgency, senderPartySchema, receiverPartySchema, senderService, receiverService, senderInterfaceName, receiverInterfaceName, senderInterfaceNamespace, receiverInterfaceNamespaceValid operators are: =, <, >, <=, >=, <>.
Please note that < has to be escaped as < and > has to be escaped as >.The Value defines what XI Messages are allowed by this Permission. The value in the Permission can end with a wildcard to allow a set of values in the XI MEssage.
Here are some examples:partyName=partyA, senderService=serviceA*, senderService<>serviceA2, receiverService=serviceB, interfaceNamespace=interfaceNamespaceA, interfaceName=interfaceApartyName=*, service=serviceA, interfaceNamespace=interfaceNamespaceA, interfaceName=interfaceAservice<>serviceA, interfaceNamespace=interfaceNamespaceA, interfaceName=interfaceA
Omitted attributes are regarded as *. For instance, the last example is equivalent to partyName=*, service<>serviceA, interfaceNamespace=interfaceNamespaceA, interfaceName=interfaceA.
The same attribute can appear multiple times like ’senderService’ in the first example. The Permission is granted if all expressions are fullfilled (logical AND). Example one contains the term ’senderService=serviceA*, senderService<>serviceA2′. This means that the permission is granted for XI Messages with a sender service that begins with ’serviceA’ (like ’serviceABC’, ’serviceAll’, …) but not for Messages with sender service ’serviceA2′.
For each attribute, a sender-/receiver specific and an unspecific version can be used: service, senderService, receiverService. An unspecific attribute means a check for sender and receiver side. The semantic is somewhat different in case the operator ‘<>‘ (not equal) is used:’service=abc’ means: Grant permission if sender service equals ‘abc’ OR receiver service equals ‘abc’’service>abc’ means: Grant permission if sender service lexicographically follows ‘abc’ OR receiver service lexicographically follows ‘abc’’service<>abc’ means: Grant permission if sender service is unequal ‘abc’ AND receiver service is unequal ‘abc’c) The value of a Permission can be one of the following:
‘execute’, ‘display’, ‘cancel’, ‘payload’, ‘edit_header’, ‘edit_payload’2. You can group several actions to a role. This can either be done with an XML document (see below) or in the user admin WebUI, which is invoked with http://: /useradmin. Select Roles there and follow the instructions in the UI.3. With the definitions in 1 and 2 you have to create an XML document, which contains all the necessary information. As a blueprint for such an XML file, you can use the standard XML document, which is included in the application (see attachment ‘actions.xml’). Please have also a look at the attached file ‘examplerole.xml’. Please note, that the filename has to end with ‘role.xml’ and that the characters ‘<' and '>‘ have to be escaped (< and >).4. Now you have to deploy the XML file to your server. To do this, open the Visual Administrator, go to node server0->services->Configuration Adapter, and switch to edit mode. Then select the node cluster_data->server->persistent->com.sap.security.core.ume.service and press the Create button. In the pop-up window select file-entry and upload the file, you created in step 3 (see attached screenshot ‘upload.jpg’).5. Open the Exchange Profile (http://: /exchangeProfile). Select node RuntimeWorkbench and press ‘New Parameter’. Enter ‘com.sap.aii.rwb.server.auth.UME’ as name and ‘true’ as value and save your changes (see screenshot ‘profile.jpg’). After that you have to restart your server.6. Open the user administration (http://: /useradmin), group your actions to roles (if not already done in step 2) and assign the new role to your users and groups.
Please keep in mind that users which have not assigned any role for message monitoring permission, cannot perform any action on messages, once the Exchange Profile parameter is set.
You can avoid this by defining a default role containing the default permission values, e.g. ‘execute’, ‘display’ and ‘cancel’, and assign this role to all users.
You can include also default messages attributes for permission value ‘payload’ in this role, if payload of this messages should be displayed by all users.
Please note, that the standard roles have also to be assigned to your user or groups (e.g. the standard user group SAP_XI_MONITOR_J2EE).