RFC-Destinationen für synchrone Methodenaufrufe (SAP-Bibliothek

RFC-Destinationen für synchrone Methodenaufrufe

Verwendung

Ab R/3 Release 4.0 können Sie auch synchrone Schnittstellen in ALE-Verteilungsszenarien nutzen.

Bei diesen Schnittstellen handelt es sich entweder um BAPIs oder um Dialogmethoden. In jedem Fall handelt es sich um eine Objektmethode aus dem BOR, die als API-Methode gekennzeichnet ist und durch einen RFC-fähigen Funktionsbaustein implementiert wird. Dieser Funktionsbaustein wird dann per synchronem RFC gerufen.

Sie können festlegen, welche RFC-Destinationen für verschiedene synchrone Methodenaufrufe verwendet werden sollen.

Um eine Kompatibilität zu vorangehenden Releases zu gewährleisten, wird die Standard RFC-Destination für BAPI-Aufrufe auch für den Aufruf der folgenden RFC-fähigen Funktionsbausteine verwendet, die nicht einer Objetktmethode im BOR zugeordnet sind:

COHR_ORDER_CONF_MAINTAIN_RFC
COHR_ORDER_CONF_GET_RFC
COHR_ORDER_CONF_DETAILS_RFC
RP_REMITTANCE_ACKNOWLEDGEMENT
HRTIM_AA_DOC_SHOW

Vorgehensweise

RFC-Destinationen für synchrone Methodenaufrufe können Sie über den R/3-Einführungsleitfaden pflegen:

Basis
Application Link Enabling (ALE)
Sender und Empfängersysteme vorbereiten
Systeme im Netzwerk konfigurieren
Synchrone Verarbeitung

Folgende Arten von RFC-Destinationen können Sie pflegen:

Die Standard RFC-Destination für BAPI-Aufrufe verwendet eine fest eingetragene Benutzerkennung, die im Server-System vom Typ CPIC ist und nur über die Berechtigungen verfügt, die BAPI-Aufrufe über ALE durchzuführen. Die dazu notwendigen Berechtigungen sind allesamt unkritisch. Daher sind über diese Benutzerkennung keine unbefugten Zugriffe möglich.
Die Standard RFC-Destination für Dialog-Aufrufe verwendet eine fest eingetragene Benutzerkennung, die im Server-System vom Typ DIALOG ist und nur über die Berechtigungen verfügt, die Dialog-Aufrufe über ALE durchzuführen. Die dazu notwendigen Berechtigungen sind allesamt unkritisch. Daher sind über diese Benutzerkennung keine unbefugten Zugriffe möglich.

Einzelheiten zu Dialogmethoden finden Sie im ALE-Programmierleitfaden unter Integration von Dialogschnittstellen.

Für spezielle Methoden (BAPIs oder Dialogmethoden), die vor unbefugtem Zugriff geschützt werden müssen, wird auf dem Client-System eine eigene RFC-Destination angelegt.
Die Voraussetzung dafür ist, daß das Client-System auf dem Server-System als Trusted System eingetragen ist (siehe Remote Communications, Trusted System: Vertrauensbeziehungen zwischen R/3-Systemen).
In dieser RFC-Destination wird keine Benutzerkennung und auch kein Kennwort eingetragen. Diese RFC-Destination wird den abzuschottenden Methoden zugeordnet. Für die Anmeldung am Server-System wird dann die aktuelle Benutzerkennung auf dem Client-System verwendet. Die Methode kann nur gerufen werden, wenn der Benutzer eine Berechtigung dafür hat (Berechtigungsobjekt S_RFCACL).

Im Einzelfall kann eine andere Zuordnung erforderlich sein.

Beispiel

Das ALE-Szenario besteht aus zwei Systemen:

Im System AC gibt es 200 Online-Benutzer, darunter einen mit der Benutzerkennung CEO.

Das System AC soll im System HR einige Methoden synchron aufrufen.

Nur dem Benutzer CEO soll es erlaubt sein, die Methode Document.Display "remote" im System HR aufzurufen.

Im System HR gibt es nur einen Online-Benutzer mit der Benutzerkennung CEO.

Die folgenden Methoden sollen vom System AC synchron aufgerufen werden:

Document.ReadInfo (synchrones BAPI, wird über RFC gerufen)

Document.Check (synchrones BAPI, wird über RFC gerufen)

Document.Display (Dialogmethode, wird nur von Benutzer CEO über RFC gerufen)

Benutzerstammsätze

Im System HR wird neben dem Benutzer CEO ein Benutzer ALE_AC angelegt.

ALE_AC ist vom Typ CPIC, also kein Dialog-Benutzer. Benutzer des Typs CPIC können generell keine Dialogtransaktionen starten. ALE_AC erhält nur die Berechtigungen, die den Remote-Aufruf der Methoden Document.ReadInfo und Document.Check ermöglichen.

RFC-Destinationen

In beiden Systemen wird der Profilparameter auth/rfc_authority_check für die RFC-Berechtigungsprüfung gesetzt. Dadurch wird bei jedem eingehenden RFC eine Berechtigungsprüfung auf die Funktionsgruppe des gerufenen Funktionsbausteins durchgeführt (Berechtigungsobjekt S_RFC).

System HR:

Im System HR wird das System AC als Trusted System eingerichtet.

In den vom Trusted System gelieferten Daten werden Systemname, Mandant, Benutzername und andere optionale Daten gesucht und gegen die Feldwerte des Berechtigungsobjekts S_RFCACL geprüft.

System AC:

Im System AC sollen zwei RFC-Destinationen angelegt werden, die beide den gleichen Applikationsserver des Systems HR beinhalten:

HR_DOC

Für diese Destination sind die Benutzerkennung ALE_AC und ein Kennwort zu hinterlegen.

HR_BLANK

Dieser Destination wird keine Benutzerkennung zugeordnet.

RFC-Destinationen für Methoden

Im System AC wird HR_DOC als Standard-RFC-Destination für synchrone BAPI-Aufrufe aus dem System HR eingetragen.

Für Aufrufe der Methode Document.Display des Systems HR wird die RFC-Destination HR_BLANK eingetragen.

Ergebnis

Durch dieses Vorgehen erreichen Sie folgende Ergebnisse:

Ein gut abgeschirmtes Empfangssystem HR.
Das Kennwort des Benutzers CEO wird nicht übertragen.
Keine unnötigen Online-Benutzer im System HR.
Da keine Standard RFC-Destination für Dialogaufrufe hinterlegt wurde, ist Document.Display die einzige Dialogmethode, die vom System AC aus gerufen werden kann.
Bei einem Release-Wechsel kann es nicht vorkommen, daß ungewollt Methoden im System HR aufgerufen werden. Die Berechtigungen der Benutzer im System HR lassen dies nicht zu.

Weitere Informationen

Bei einem asynchronen Aufruf eines BAPIs wird die RFC-Destination in der Partnervereinbarung für den zugehörigen Nachrichtentyp hinterlegt.

Einzelheiten zur Destinationspflege und zu Trusted Systems finden Sie in der Dokumentation Remote Communications:

Entfernte Destinationen pflegen

Trusted System: Vertrauensbeziehungen zwischen R/3-Systemen