SAP SM59: Fernsysteme konfigurieren für NWBC & Fiori Launchpad

In modernen Unternehmenslandschaften ist die nahtlose Kommunikation und Navigation zwischen verschiedenen SAP-Systemen eine grundlegende Anforderung. Anwendungen müssen häufig Transaktionen in entfernten Systemen aufrufen, auf Web Dynpro-Anwendungen zugreifen, objektbasierte Navigation (OBN) oder Intent-basierte Navigation (IBN) zu externen Systemen durchführen oder einfach Daten von einem Remote-System lesen. Die zentrale Steuerung dieser Verbindungen erfolgt über die Transaktion SM59 in SAP, insbesondere durch die Definition von ABAP-Verbindungen (Verbindungstyp 3).

Während SM59-RFC-Ziele oft ausreichen, um eine Anforderung zu lösen, können in bestimmten Szenarien zusätzliche HTTP/HTTPS-Ziele für Remote-Systeme erforderlich sein – beispielsweise bei der Navigation zu einer Web Dynpro-Anwendung über HTTPS. Dieser Artikel konzentriert sich auf ABAP-basierte Anwendungsfälle und richtet sich an Anwendungsentwickler sowie Systemadministratoren, die mit dem NetWeaver Business Client (NWBC) und dem Fiori Launchpad arbeiten. Er beleuchtet die umfassenden Möglichkeiten von SM59 zur Gewährleistung einer robusten und sicheren systemübergreifenden Integration.

Unterstützte Shells für Remote-System-Konfigurationen

Die korrekte Auflösung der Remote-System-Konfiguration und die Verarbeitung der systemübergreifenden Navigation werden maßgeblich von der Shell gesteuert, die die Anwendung hostet. Für eine reibungslose Kommunikation sind Remote-System-Konfigurationen in den folgenden Shells unerlässlich:

NWBC for Desktop	NWBC for HTML	Fiori Launchpad
Remote-Ziele verwendet in: – Indexseite und Navigationsmenü-Links, die Anwendungen für Remote-Systeme zugänglich machen – OBN-Ziele – Quick Launch, der Links aus dem Navigationsmenü sammelt	NWBC HTML Ansicht zur Darstellung von Remote-Zielen Identisch wie für NWBC for Desktop	Remote-Ziele verwendet: – Bei der Navigation mit Kacheln, die auf Web GUI/Web Dynpro-Anwendungen verweisen, definiert im ABAP Report Launchpad (LPD_CUST) – Bei der Übergabe des Data Origin für SAP Fiori-Anwendungen über den Parameter sap-system

Anwendungsfälle für System-Aliase und RFC-Ziele

Um auf entfernte Systeme zu verweisen, können Sie den SM59-Namen (RFC-Destination-Name) oder den System-Alias verwenden. Der System-Alias ist die normalisierte/Basisform des SM59-Destination-Namens und wird an verschiedenen Stellen und in verschiedenen Diensten genutzt:

• Transaktion PFCG: Das Attribut Zielsystem eines Navigationsmenü-Eintrags kann einen System-Alias verwenden. Dies signalisiert, dass die Anwendung vom Remote-System aufgerufen werden soll, das durch den System-Alias spezifiziert ist.
  PFCG Konfiguration für Zielsystem in SAP SM59
• Transaktion LPD_CUST: Der obligatorische Parameter System-Alias ist im Bildschirm Launchpad-Rolle ändern zu finden. Die Anwendung soll das Remote-System aufrufen, das durch den System-Alias angegeben ist. Der System-Alias kann von der ABAP-Laufzeit (NWBC) oder von der Portal-Laufzeit aufgelöst werden.
  LPD_CUST Konfiguration für System-Alias in SAP SM59
• Fiori Launchpad Designer: Der System-Alias kann in der Konfiguration von Zielzuordnungen (Target Mappings) im Fiori Launchpad Designer für Anwendungstypen wie Transaktion, URL oder WebDynpro verwendet werden, um den Ursprung der Anwendung und der Daten zu definieren. Für SAP Fiori Apps, die LPD_CUST nutzen, kann der System-Alias direkt in LPD_CUST definiert werden (siehe oben). Der System-Alias kann entweder im dedizierten Feld System-Alias oder als Standardparameter sap-system im Abschnitt Parameter eingegeben werden (die Übergabe des Alias über den Parameter sap-system hat Vorrang vor der Definition im dedizierten Feld).
• Als dynamischer Parameter SYSTEM, wenn per OBN (PFCG-basiert) navigiert oder der Link im Report Launchpad (LPD_CUST) aufgelöst wird. Dieser wird als URL-Parameter übergeben, der benutzerdefinierte Werte, die in LPD_CUST oder PFCG definiert sind, überschreibt (z.B., ...?sap-client=001&sap-language=DE&SYSTEM=ERP1).
• Als dynamischer Parameter sap-system, übergeben innerhalb eines Intents (Intent-basierte Navigation im Fiori Launchpad -> ...#SalesOrder-display?sap-system=ERP1). Dieser Parameter überschreibt den in LPD_CUST definierten System-Alias-Parameter.
• Als Parameter für den System Alias Repository API Web-Service, implementiert für NWBC 5.0.

Namenskonventionen für SM59-Destinationen

Die SM59-Transaktion erlaubt keine Erstellung mehrerer Destinationen mit demselben Namen, selbst wenn die Verbindungstypen unterschiedlich sind. Um jedoch mehrere Destinationen mit demselben “Basisnamen” referenzieren zu können, wird ein Trick angewandt: Man verwendet mehrere SM59-Einträge mit demselben Basisnamen und einem angehängten Suffix (_RFC, _HTTP, _HTTPS), um die verschiedenen Verbindungstypen zu unterscheiden.

Zum Beispiel, wenn der Systemname XYZ ist, sollten die verschiedenen Destinationen wie folgt benannt werden:

• SM59-Namensauflösungssequenz für SAP GUI-Aliase: XYZ_RFC, XYZ
• SM59-Namensauflösungssequenz für HTTP-Aliase: XYZ_HTTPS, XYZ_HTTP, XYZ

Dieser Ansatz ermöglicht es, mehrere Verbindungen zu referenzieren, indem nur der Basisname (z.B. XYZ) übergeben wird. Die folgenden Suffixe können verwendet werden:

• _HTTP (XYZ_HTTP): Zur Definition von HTTP-Verbindungseinstellungen. Anwendbar für die Verbindungstypen G und H.
• _HTTPS (XYZ_HTTPS): Zur Definition von HTTPS-Verbindungseinstellungen. Anwendbar für die Verbindungstypen G und H.
• _RFC (XYZ_RFC): Zur Definition von RFC-/SAP GUI-Verbindungen. Anwendbar für Verbindungstyp 3.
• _BOE (XYZ_BOE): Zur Definition zusätzlicher HTTP-Verbindungen bei Verwendung von ABAP Launchpad Crystal Reports Links. Anwendbar für die Verbindungstypen G und H.

Für die Verbindungstypen RFC (3) und HTTP (H, G) kann das Suffix weggelassen werden (Basisname gleich SM59-Destination-Name), und die Laufzeit wird die Verbindungsdaten trotzdem korrekt auflösen. Dieser Fallback erlaubt die Wiederverwendung bestehender Definitionen ohne zusätzliche Konfiguration. Beachten Sie, dass, wenn Sie eine Destination vom Typ H/G mit einem Namen haben, der dem Basisnamen entspricht, diese für alle HTTP-basierten Verbindungen (_HTTP, _HTTPS und _BOE) herangezogen wird. Explizit definierte Destinationen mit Suffixen können Fallbacks natürlich überschreiben.

Referenzierung über System-ID und Client

Ab UI Add-On SP09 ist es auch möglich, ein System nicht nur über logische Aliasnamen, sondern auch über System-ID und Client zu referenzieren. Dieser Anwendungsfall ist relevant, wenn ein remote aufgerufener Dienst den Rückruf-Ort generiert: Der Remote-Server kennt den vom Aufrufer verwendeten Systemnamen nicht und kann nur seine eigene System-ID und den Client angeben. Wenn die Referenzierung über die System-ID erforderlich ist, muss die folgende Syntax verwendet werden:

sid(SYSTEMID[.CLIENT]) zum Beispiel: sid(U00.111) oder sid(U00)

Weitere Informationen zur Notation und Verwendung finden Sie in der jeweiligen Gateway-Dokumentation.

Die Syntax ist groß-/kleinschreibungsempfindlich. sid-Definitionen können in den folgenden Fällen verwendet werden:

• PFCG -> Feld Zielsystem
• LPD_CUST -> Feld System-Alias
• SYSTEM -> URL-Parameter für OBN/LPD_CUST-Linkauflösung (...?SYSTEM=sid(U00.111)...)
• sap-system -> Intent-Parameter im Fiori Launchpad (...#SalesOrder-display?sap-system=sid(U00.111)...)

Die Systemauflösungslogik ist wie folgt:

1. Suche in SM59-Destinationen nach einer expliziten Übereinstimmung, d.h. mit einem System-Alias, der dem String sid(SYSID.CLIENT) entspricht.
2. Falls nicht gefunden, parse den sid-String in System-ID und Client.
3. Suche in SM59 nach einer RFC-Destination, die der angegebenen SYSID mit dem spezifizierten Client (oder ohne, falls nicht angegeben) zugeordnet ist.
4. Ermittle den Basisnamen des System-Alias aus dem RFC-Destination-Namen (verwende ihn wie er ist oder entferne das Suffix _RFC).
5. Sammle Systemdaten über den System-Alias.

Um eine SM59-Destination über die SID + Client-Notation durchsuchbar zu machen, muss die Einstellung Lastausgleich der entsprechenden RFC-Destination auf Ja gesetzt und die Einstellungen des Zielsystems korrekt gepflegt werden. Da das Repository (SM59) mehrere Destinationen haben kann, die auf dieselbe SYSID + Client verweisen, wird der zuerst übereinstimmende Wert zurückgegeben.

Welche Verbindungstypen sind zu pflegen?

Verschiedene SM59-Destinationstypen unterstützen unterschiedliche Anwendungstechnologien. Es wird empfohlen, immer alle drei Verbindungstypen (_RFC, _HTTP, _HTTPS) zu pflegen, selbst wenn Sie sie aktuell nicht benötigen. Dies gewährleistet eine stabile Auflösung, auch wenn sich Ihre Anwendungstechnologie in Zukunft ändern sollte.

Wo sind Destinationen zu definieren?

Die Auflösung der SM59-Destination oder des System-Alias vom logischen Namen zu den Destinationdetails erfolgt auf dem System, mit dem die Shell (Client, z.B. FLP, NWBC, EP) verbunden ist. Im Falle von FLP ist dies ein Front-End-Server (nicht ein Backend). Daher müssen alle unten genannten Artefakte auf diesem System erstellt werden.

Es gibt Anwendungsfälle, in denen Backend-definierte Systeme weiterhin im FLP verwendet werden können (Navigation über OBN, absolute Navigation, LPD_CUST), aber dies funktioniert nur, wenn der Legacy- zu IBN-Modus aktiviert ist und ABAP FLP verwendet wird (cFLP wird noch nicht unterstützt).

Definition der RFC-Verbindung

Beim Pflegen der RFC-Verbindung können Sie entweder Lastausgleich auswählen oder direkte Einstellungen angeben (= Lastausgleich AUS + Zielhost-Adresse). Wenn der Lastausgleich in der RFC-Verbindungsdefinition deaktiviert ist, stellen Sie sicher, dass Ihre Verbindung für alle Versionen von NWBC for Desktop und alle Versionen der NWBC-Serverlaufzeit verwendet werden kann. Wenn Sie den Lastausgleich über die RFC-Verbindungseinstellung implementieren möchten, müssen Sie NWBC 5.0 zusammen mit der Serverlaufzeit für SAP NetWeaver User Interface Services auf User Interface Add-On 1.0 for SAP NetWeaver SPS 09 oder SAP NetWeaver 7.4 mit der Softwarekomponente SAP_UI SPS08 betreiben. Die Referenzierung über System-ID und Client wird nur unterstützt, wenn der RFC Lastausgleich aktiviert ist.

Technische Einstellungen (Lastausgleich)	Technische Einstellungen (Direkt)
Technische Einstellungen einer SM59 RFC-Verbindung ohne Lastausgleich– Zielhost kann vom SM51 Host übernommen werden. – Instanz-Nr. kann aus der SAP Logon Verbindungsdefinition übernommen werden. Weitere Details siehe unten.

Anmeldung & Sicherheit	Anmeldung & Sicherheit (SNC)
Anmelde- und Sicherheitseinstellungen für SM59 RFC-Verbindung mit SNC– SNC-Einstellungen können aus der entsprechenden SAP Logon-Verbindung übernommen werden. Partner entsprechen dem SNC-Namen und QoP den Sicherheitseinstellungen.

Definition der HTTP-Verbindung

Technische Einstellungen

Anmeldung & Sicherheit

– HTTP-Host und Port können in der Transaktion SICF des entsprechenden Systems gefunden werden. – Sie können ein Pfad-Präfix verwenden, um einen festen Präfix-Pfad für ALLE Ihre Webadressen zu definieren. Zum Beispiel, wenn Sie nur mit UI5 arbeiten: /sap/bc/ui5_ui5/, aber in den meisten Fällen sollte dies leer bleiben.

Anmelde- und Sicherheitseinstellungen für SM59 HTTP-Verbindung– Lassen Sie Sprache leer, wenn Sie die Sprache der aufrufenden Anwendung verwenden möchten. – Ein generischer Benutzer wird noch nicht unterstützt, daher können Sie hier keinen Benutzer und kein Passwort fest codieren. – Stellen Sie sicher, dass der Mandant, den Sie in allen Verbindungstypen definiert haben, derselbe ist. Wenn der Mandant nicht angegeben ist, wird der Mandant der aufrufenden Anwendung hinzugefügt. – Bei HTTP-Verbindungen muss SSL auf Inaktiv gesetzt sein.

Definition der HTTPS-Verbindung

Technische Einstellungen

Anmeldung & Sicherheit

Anmelde- und Sicherheitseinstellungen für SM59 HTTPS-Verbindung– Lassen Sie Sprache leer, wenn Sie die Sprache der aufrufenden Anwendung verwenden möchten. – Ein generischer Benutzer wird noch nicht unterstützt, daher können Sie hier keinen Benutzer und kein Passwort fest codieren. – Stellen Sie sicher, dass der Mandant, den Sie in allen Verbindungstypen definiert haben, derselbe ist. Wenn der Mandant nicht angegeben ist, wird der Mandant der aufrufenden Anwendung hinzugefügt. – Bei HTTPS-Verbindungen muss SSL auf Aktiv gesetzt sein. Stellen Sie sicher, dass Sie den HTTPS-Port im Feld Service-Nr. auf der Registerkarte Technische Einstellungen eingegeben haben.

Wie finden Sie Systemeinstellungen?

HTTP Hosts und Ports

Um die HTTP-Host- und Portinformationen eines Remote-Systems zu finden:

• Rufen Sie im Remote-System die Transaktion SICF auf und drücken Sie F8.
• Klicken Sie in der Anwendungs-Toolbar auf die Schaltfläche Host- und Portinformationen.

SICF Transaktion	Host- und Portinformationen
SICF Transaktion zur Anzeige von Services

RFC Lastausgleichsdaten

Die Daten zur Konfiguration der RFC-Destination können in den Eigenschaften der entsprechenden Verbindung gefunden werden, die im SAP Logon (oder im NWBC 5.0 System Selector) definiert ist:

• Einstellungen für den Lastausgleich finden Sie auf der Registerkarte Verbindung der SAP Logon-Verbindung.
• SSO-Einstellungen finden Sie auf der Registerkarte Netzwerk.

SAP Logon Systemeinstellungen (Verbindung)	SAP Logon Systemeinstellungen (Netzwerk)
SAP Logon Netzwerkeinstellungen für SNC in SM59 RFC

NWBC 5.0 System Selector	SM51 Serverliste
NWBC 5.0 System Selector für SAP GUI Verbindungen

System-Alias nicht aufgelöst?

Wenn die Laufzeit die durch den System-Alias bereitgestellte Systemkonfiguration nicht bestimmen kann, verwendet sie das lokale System (relativer Pfad zur Anwendung) und übergibt den nicht aufgelösten System-Alias-Parameter (SYSTEM oder sap-system) zur weiteren Verarbeitung an die Anwendung. Wird ein dynamisch übergebener System-Alias (als URL- oder Intent-Hash-Parameter) aufgelöst, wird der URL/Intent-Parameter aus der Parameterliste gelöscht und nicht an die Anwendung weitergeleitet.

Wenn die Anwendung auf ein Remote-Ziel über einen System-Alias verweist, versucht sie normalerweise, auf den Ursprung des Ziels zu zeigen. Es gibt zwei Arten von Ursprüngen:

• Datenursprung (Data Origin): Zeigt auf den Speicherort der Daten, die von der Zielanwendung verwendet/konsumiert werden, und gibt an, von welchem Ort die Daten geladen werden sollen. Für SAP UI5-Anwendungen ist dies ein Backend-System, das OData-Dienste implementiert.
• Anwendungsursprung (Application Origin): Zeigt auf den Speicherort der Anwendungsquellen und gibt an, von welchem Ort die Anwendung selbst geladen werden soll. Für SAP UI5-Anwendungen ist dies der Front-End-Server.

Der Anwendungsursprung kann derselbe sein wie der Datenursprung; Beispiele hierfür sind SAP GUI- und Web Dynpro-Anwendungen. Für SAP UI5-Anwendungen wird der SAP GUI-, Web Dynpro- oder URL-System-Alias, der zur Auflösung mit dem sap-system-Parameter übergeben wird, in allen Fällen als Datenursprung behandelt. Er sollte nicht für andere Zwecke verwendet werden. Es ist noch nicht möglich, den Anwendungsursprung explizit zu übergeben. Stattdessen löst das Fiori Launchpad den Anwendungsursprung basierend auf der wahrscheinlichsten Standardeinstellung auf:

• SAP UI5-Anwendung: FLP-Ursprung (Front-End-Server) wird ebenfalls als Anwendungsursprung angenommen.
• SAP GUI, Web Dynpro und URL: System-Alias (Datenursprung) wird ebenfalls als Anwendungsursprung angenommen.

System-Alias-Zuordnung (Mapping)

In einigen Fällen ist es sinnvoll, eine Indirektion in den System-Alias-Zuordnungen zu verwenden und mehrere System-Aliase auf einen anderen umleiten zu können. Es gibt verschiedene Möglichkeiten, wie eine solche System-Alias-Zuordnung erfolgen kann:

• PFCG: Wenn Sie System-Aliase zu Anwendungen in PFCG zuordnen, können Sie die Datenbanktabelle SSM_RFC verwenden (aufrufbar über die dedizierte Pflegeansichtstransaktion SM30_SSM_RFC).
  PFCG SSM_RFC Tabelle zur System-Alias-ZuordnungSSM_RFC ist mandantenunabhängig, und Sie können keine mandantenabhängigen System-Alias-Zuordnungen konfigurieren. Rekursive Zuordnungen werden nicht unterstützt. Die Tabelle SSM_RFC ist seit langem verfügbar und kann auf den meisten SAP_BASIS-Releases verwendet werden.
  SM30 SSM_RFC Ansicht für System-Alias-Mapping
• ABAP Report Launchpad (LPD_CUST): Ab SAP_BASIS 730 können Sie die System-Alias-Zuordnung im ABAP Report Launchpad konfigurieren. Die Zuordnung ist Launchpad-Rollen-/Instanz- und mandantenabhängig. Es gibt keine Möglichkeit, System-Aliase global für alle Launchpad-Instanzen umzuzuordnen, und Sie können nur System-Aliase zuordnen, die im ausgewählten Launchpad verwendet werden.
• Fiori und NWBC: Mit UI Add-on V2 steht eine neue Funktionalität zur Verfügung, die es Ihnen ermöglicht, die System-Alias-Zuordnung für alle Anwendungsfälle zu konfigurieren, die innerhalb von UI2 NWBC (NetWeaver Business Client for UI Add-on) und Fiori Launchpad (PFCG, LPD_CUST, Fiori Launchpad Designer) ausgeführt werden. Die Zuordnung kann in der DB-Tabelle /UI2/SYSALIASMAP (oder über die Pflegeansicht /UI2/V_ALIASMAP in Transaktion SM30) definiert werden.
  SM30 /UI2/V_ALIASMAP Ansicht zur System-Alias-Zuordnung in Fiori und NWBCDie Zuordnung ermöglicht die Definition globaler oder mandantenabhängiger Zuordnungen (für globale Zuordnungen muss das Mandantenfeld leer bleiben). Die mandantenabhängige Definition hat Vorrang vor der globalen Definition.
• Fiori und Gateway: SAP Gateway bietet ebenfalls eine Möglichkeit, System-Aliase zu definieren und somit eine Indirektion zwischen dem für die Navigation verwendeten logischen Namen und dem in SM59 definierten realen Destination-Namen zu pflegen. Die Konfiguration der System-Aliase in GW kann mit der Transaktion /IWFND/ROUTING aufgerufen werden.
  Gateway System-Aliase Konfiguration im Fiori LaunchpadWeitere Details finden Sie in der Gateway-Dokumentation: SAP Gateway Foundation => Anlegen eines SAP-Systemalias.
  Wichtig: System-Aliase, die in Fiori (FLP)-Umgebungen verwendet werden sollen, müssen konsistent für Gateway und NWBC definiert werden. D.h. dieselben Aliase in der Ansicht /UI2/V_ALIASMAP und in der Transaktion /IWFND/ROUTING, andernfalls ist keine flüssige Navigation zwischen SAP UI5- und klassischen UI-Anwendungen (GUI-Transaktionen und WebDynpro) möglich.

Konfiguration der “stillen” Systemanmeldung (Single Sign-On)

Nachdem die System-Aliase korrekt gepflegt und die Navigation zwischen Host- und Remote-Systemen überprüft wurde, stellt sich die Frage, wie die “stille” Anmeldung eines Benutzers während der Navigation konfiguriert werden kann, ohne dass Anmeldeinformationen erneut eingegeben werden müssen.

HTTP-Verbindung

Wenn der Benutzer zu einer Web-basierten Anwendung navigiert, reicht es aus, wenn ein Single Sign-On (SSO) etabliert ist und der Benutzer ein Client-Zertifikat installiert hat. Die Anmeldung am Remote-System erfolgt dann durch den Browser unter Verwendung der installierten Client-Zertifikate. Wenn man sich mit einem Benutzer anmelden möchte, für den kein Client-Zertifikat installiert ist, ist ein manueller Anmeldevorgang erforderlich (und der Browser sollte so konfiguriert sein, dass immer ein Client-Zertifikat-Popup angezeigt wird).

RFC-Verbindung

Wenn der Benutzer zu einer nativen Anwendung (SAP GUI for Windows) navigiert, ist zusätzlich zur Konfiguration von Single Sign-On eine zusätzliche Konfiguration notwendig. Zunächst muss ein Client verwendet werden, der die Übertragung der Anmeldedaten vom Host-System an ein Remote-System unterstützt, z.B. der NetWeaver Business Client (NWBC). Details zur Einrichtung der Authentifizierung mit NWBC finden Sie hier: Authentication and Single Sign-On with NWBC.

Zweitens müssen Sie Ihre Systeme so einrichten, dass sie die Übertragung von Anmeldedaten von einem Host-System an ein Remote-System ermöglichen.

Handelt es sich um eine ABAP-basierte Landschaft, finden Sie Details hier: Using Logon Tickets with AS ABAP.

Im Wesentlichen besteht die Konfiguration aus zwei Teilen:

• FÜR DAS HOST-SYSTEM: Konfigurieren des ABAP-Servers zum Ausstellen von Anmeldetickets, indem der Profilparameter login/create_sso2_ticket = 2 gesetzt wird (mit Transaktion RZ10).
• FÜR DAS REMOTE-SYSTEM: Konfigurieren des ABAP-Servers zum Akzeptieren von Anmeldetickets, indem der Profilparameter login/accept_sso2_ticket= 1 gesetzt wird (mit Transaktion RZ10).

Schließlich muss auch eine Vertrauensbeziehung zwischen beiden Servern hergestellt werden, was auf verschiedene Weisen geschehen kann, wie hier beschrieben (unter Verwendung der Transaktionen SSO2 oder STRUST).

Mixed Content: Herausforderungen bei der Protokollintegration

Manchmal erhalten Sie eine Browser-Meldung: “Diese Anfrage wurde blockiert; der Inhalt muss über HTTPS bereitgestellt werden.” Das Problem hierbei ist, dass Sie Ihre Hauptanmeldung (FLP, SAP BC) über eine HTTPS-URL gestartet haben, das Remote-System jedoch über eine HTTP-URL integriert und angesprochen wird. Die Meldung würde erscheinen, wenn eine Ihrer Apps auf eine Ressource von einer HTTP-Destination verweist oder die Shell den Remote-Inhalt über ein IFrame einbettet und eine Verbindung zum Remote-System über HTTP herstellt.

Der einzige Weg, diese Meldung zu vermeiden, ist die Verwendung von HTTPS für jede URL. Das bedeutet, dass Sie für alle verbundenen Backend-Systeme auch eine HTTPS-Verbindung pflegen müssen.

Wenn Sie problemlos mit gemischtem Inhalt arbeiten können, ist dies nur bei SAP BC (NWBC for Desktop) der Fall. SAP BC verwendet kein Framing für den Start von WebDynpro oder GUI-Transaktionen (wenn im NWBC-Verbindungsmodus ausgeführt) und verwendet kein Framing, wenn es im FLP-Verbindungsmodus ausgeführt wird und GUI-Transaktionen nativ in SAP GUI for Windows startet.

Bestehende Dokumentation und weitere Ressourcen

Für detailliertere Informationen und weiterführende Anleitungen können Sie die offizielle SAP-Dokumentation konsultieren:

• Configuring remote systems to be used in NetWeaver Business Client (NWBC)
• Configuring of remote systems to be used in ABAP Report Launchpad (LPD_CUST)

Erforderliche SAP Notes

Für eine optimale Funktionalität und Fehlerbehebung sind folgende SAP Notes relevant:

• 2318483 – Support of native SAP GUI transactions in Business Client 6.0 with Fiori Launchpad Connect…
• 2313296 – Fix for ABAP Launchpad to ITS URL migration
• 2279202 – UI2: HTTP connection for system alias not found

Allgemeine Anforderungen

Um die in diesem Artikel beschriebenen Funktionen vollumfänglich nutzen zu können, sind bestimmte Systemvoraussetzungen zu erfüllen:

• UI Add-On SP09 (Unterstützung des sid-Formats und Lastausgleichs in NWBC 5.0).
• Zur Integration von Inhalten aus anderen Systemen unter Verwendung der Eigenschaft Zielsystem in PFCG benötigen Benutzer Anzeigeberechtigung für SM59 im Backend (NWBC 5.0).

Fazit

Die korrekte Konfiguration von Remote-Systemen über die Transaktion SM59 ist ein Eckpfeiler für eine effiziente und reibungslose systemübergreifende Kommunikation und Navigation in SAP-Umgebungen wie dem NetWeaver Business Client und dem Fiori Launchpad. Von der sorgfältigen Benennung der Destinationen über die Auswahl der passenden Verbindungstypen bis hin zur Implementierung von Single Sign-On und der Berücksichtigung von System-Alias-Zuordnungen – jeder Schritt trägt zur Stabilität und Benutzerfreundlichkeit Ihrer SAP-Landschaft bei.

Die kontinuierliche Pflege dieser Einstellungen und die Beachtung der neuesten SAP Notes stellen sicher, dass Ihre Anwendungen stets optimal auf entfernte Systeme zugreifen können. Wir hoffen, dieser Leitfaden hat Ihnen wertvolle Einblicke in die Leistungsfähigkeit und die Best Practices rund um Sap Sm59 gegeben. Vertiefen Sie Ihr Wissen und optimieren Sie Ihre SAP-Systemintegration, um das volle Potenzial Ihrer Unternehmensanwendungen auszuschöpfen.