Connecting Multiple SAP Focused Run Systems
to One Managed System

The most common scenario, where you want to connect one managed system to multiple SAP Focused Run systems (FRUN DEV/QAS/PRD), is working out of the box, and we assume these SAP Focused Run systems can have the same authorization on the host of the managed system. This is not discussed here. In the following we describe this scenario as an extension of the existing guide “How to connect a customer system located in the SAP HANA Enterprise Cloud to an on-premise SAP Solution Manager”.

This Expert Portal page is intended to help you when you want to connect multiple SAP Focused Run systems to one managed system, but the SAP Focused Runs must have different authorizations on the operating system level. This can be the case because one SAP Focused Run is used for operation by the hosting provider, and the other is used by the hosting customer.

For example the hosting provider can be SAP HANA Enterprise Cloud (HEC) running SAP Focused Run and any HEC customer running its own SAP Focused Run. In this scenario the HEC is running its own OS scripts, which are not allowed to be executed by customers. Also, because of the standardized environment, customers are not allowed install to agents by themselves. However, this does not affect the configurations of different SAP Focused Run systems, their configurations are completely separated in Simple Diagnostics Agent (SDA) and CA APM Introscope.

SAP Focused Run is storing configuration data of the Simple Diagnostics Agent in subdirectories identified by the SAP Focused Run system ID, to separate the different configurations from different SAP Focused Run systems. If you plan to connect one Simple Diagnostics Agent (SDA) to multiple SAP Focused Run systems, it is mandatory that the different SAP Focused Run systems have different SIDs. For example, you connect DEV/QAS/PRD SAP Focused Run systems to the same managed system, or your Hosting Provider runs a SAP Focused Run system for system operations as well. Therefore, please choose the SAP Focused Run SID foresightful.

On this page we generalize this scenario by describing a Hosting Customer and any other Hosting Provider using a SAP Focused Run system. In the following sub-sections, we describe certain aspects to be considered, when using two SAP Focused Run systems in such scenario. The following figures show this scenario without firewalls, reverse proxies, and load balancers as they are not relevant for the actual discussion here.

SAP Host Agent

The following figure 1 is describing the scenario at hand in detail, already pointing out the security related details of the SAP Host Agent of the Managed System. Both partners share the same SAP Host Agent. The hosting provider has OS root authorization and full authorizations on the SAP Host Agents, whereas the customer is only using the functionalities of the Simple Diagnostics Agents (SDA) to enable all SAP Focused Run features. The Personal Security Environment (PSE) of the SAP Host Agent must trust both Certificate Authorities (CA), the Customer CA and the Hosing CA to enable encrypted communication with both clients. Encrypted communication is mandatory if one partner is using basic authentication, in this case with user sapadm. It is mandatory for the Hosting Customer to authenticate with a certificate, as this is the only way to limit the authorization to SDA. Client certificate check can be only be achieved as part of the TLS handshake when establishing the HTTPS communication.

As the full administration authorization on the OS level with user SAPADM is in our example only owned by the hosting provider. The customer in this case has only authorization to URI /lmsl/sda. Those authorizations are sufficient for all SAP Focused Run applications. For further details on setting up the certificate-based authorization, please check the security guide:

https://help.sap.com/viewer/6ba510f3be2945e19e497bfb1065b022/2.0/en-US/789188ebf9cc42d7b112cf31e6405f8d.html

Any deployment of customer OS scripts for SAP Host Agent “CustomOperations” need to be negotiated with the hosting provider script by script in case.

Figure 1: SAP Host Agent

Bytecode Agent

A CA APM ByteCode Agent for monitoring non-ABAP managed systems can only report to one APM Enterprise Manager. In the parallel operation scenario, described in figure 2, with multiple FRUN (or SAP Solution Manager) systems connected to one APM Enterprise Manager the Hosting Partners need to be aligned about the shared CA APM Enterprise Manager. The connection address for the CA Bytecode Agent, respectively the host:port where the CA APM Enterprise Manager is installed, need to be agreed by the partners. The ByteCode Agent can be installed by SAP Solution Manger, by the SDA preparation tools (FRUN) or manually. Every partner who wants to update the ByteCode Agent need to apply the aligned connection credentials for the host:port of the CA APM Enterprise Manager.

Since CA APM Enterprise Manager 9.7 with latest Management Modules, the CA APM can serve several FRUNs in parallel with subject to release restriction. Please find the relevant release notes in SAP Note 797147 – Introscope Installation for SAP Customers.

Figure 2: Bytecode Agent

Maintenance Planner

The Maintenance Planner in the SAP Support Portal can handle several SAP Focused Run systems as data sources (see also figure 3). Besides other features the Landscape Information Service in the SAP Support Portal only shows the latest complete technical system data to the Maintenance Planner. This way the partners do not need to consider which SAP Focused Run system (at the hosting customer and/or at the hosting provider) is sending the data.

It is enough that one SAP Focused Run system is sending the data, but also several data sources are accepted. The access to the data in the SAP Support Portal and the maintenance planner is granted by the S-User authorizations.

Figure 3: Maintenance Planner

Please find more more information:

EarlyWatch Alert (EWA)

SAP Focused Run does not provide the Session Workbench for EWA generation, therefore the data to generate the EarlyWatch reports are send to the SAP Support Backbone like shown in figure 4. This has the advantage, that you benefit always from the latest EWA content and can also make use of the SAP EarlyWatch Alert Workspace.

It is enough that one SAP Focused Run system is sending the data, but also several data sources are accepted. The access to the data in the SAP Support Portal and the maintenance planner is granted by the S-User authorizations.

Figure 4: EarlyWatch Alert (EWA)

System Landscape Directory (SLD)

If you plan your landscape, you also have to take care of a proper SLD DS Payload Distribution.