SAP im Redundanzbetrieb
Dieser Abschnitt ergänzt die allgemeine Redundanz-Dokumentation um SAP-spezifische Hinweise. Hintergrund ist, dass insbesondere SAP-Trigger im Redundanzbetrieb anders zu bewerten sind als rein lesende oder rein lokal ausgeführte Funktionen.
Warum SAP im Redundanzbetrieb besondere Aufmerksamkeit braucht
Im Redundanzbetrieb werden auch auf dem Sekundärsystem die beteiligten Plug-ins initialisiert. Bei SAP-Triggern kann das problematisch sein, wenn beide Systeme mit identischen Benutzerdaten arbeiten oder SAP-seitig nicht eindeutig festgelegt ist, welche OPC-Router-Instanz angesprochen werden soll.
Die Risiken liegen typischerweise in diesen Bereichen:
- parallele Initialisierung derselben SAP-bezogenen Komponenten auf Primär- und Sekundärsystem
- unklare Zuständigkeit beim Failover, wenn SAP nicht gezielt das aktive System adressiert
- schwer nachvollziehbare Seiteneffekte bei auslösenden SAP-Aktionen
Was grundsätzlich möglich ist
Die Redundanz des OPC Routers bleibt auch bei SAP-Szenarien grundsätzlich nutzbar. Kritisch sind jedoch vor allem Konstellationen, in denen SAP aktiv Trigger gegen den OPC Router auslöst und dabei keine saubere Trennung zwischen Primär- und Sekundärsystem besteht.
Verwenden Sie die Redundanz deshalb nicht nur als Infrastrukturthema, sondern prüfen Sie immer auch das konkrete Verhalten der projektierten SAP-Trigger im Failover-Fall.
Empfohlenes Vorgehen
1. Primärbetrieb zuerst vollständig testen
Richten Sie SAP-Plug-in, Trigger und beteiligte SAP-seitige Objekte zunächst so ein, dass der Primärdienst allein stabil funktioniert. Prüfen Sie insbesondere:
- Verbindungsaufbau und Authentifizierung
- korrekte Auslösung der projektierten Trigger
- Verhalten bei Wiederveröffentlichung und Neustart
2. Benutzer- und Berechtigungskonzept bewusst prüfen
Verwenden Sie identische Benutzerdaten nicht ungeprüft für beide OPC-Router-Instanzen. Wenn parallele Initialisierung oder konkurrierender Zugriff zu Konflikten führen kann, sollte das Benutzer- und Berechtigungskonzept entsprechend angepasst werden.
Dabei ist nicht nur relevant, ob die Anmeldung technisch funktioniert, sondern auch, ob SAP-seitig eindeutig erkennbar und steuerbar bleibt, welches System welche Aktion ausführt.
Für SAP-Trigger ist dabei insbesondere relevant, dass die beteiligten Instanzen nicht mit derselben Programm-ID betrieben werden. Verwenden Primär- und Sekundärsystem eine gemeinsame Programm-ID, kann SAP nicht zuverlässig unterscheiden, welche OPC-Router-Instanz angesprochen werden soll. Nutzen Sie daher pro Instanz eine eigene Programm-ID für RFC- und IDoc-Trigger, damit SAP gezielt den aktiven Dienst adressieren kann.
3. Failover gezielt in einer Testumgebung prüfen
Testen Sie den Wechsel vom Primär- auf den Sekundärdienst und den Rückwechsel ausdrücklich mit den tatsächlich verwendeten SAP-Triggern. Prüfen Sie dabei insbesondere:
- ob SAP nach dem Failover das richtige System erreicht
- ob Trigger weiterhin erwartbar ausgelöst werden
- ob es zu doppelten oder konkurrierenden Effekten kommt
- ob die SAP-seitig konfigurierte Programm-ID nach dem Failover weiterhin auf die gewünschte aktive Instanz zeigt
4. Triggerarten einzeln bewerten
Bewerten Sie RFC- und IDoc-basierte Trigger nicht pauschal als gleich. Je nach SAP-seitiger Konfiguration, Zieladressierung und technischem Benutzer können sich die Auswirkungen im Redundanzbetrieb unterscheiden.
Nutzen Sie daher die jeweilige Trigger-Dokumentation als technische Grundlage und ergänzen Sie sie immer um einen projektspezifischen Failover-Test.
Praktische Empfehlungen
- Verwenden Sie für produktive Szenarien nur Konfigurationen, die im Primärbetrieb und im Failover-Fall getestet wurden.
- Dokumentieren Sie SAP-seitig, welche Destinationen, Benutzer und Triggerfunktionen zur aktiven OPC-Router-Instanz gehören.
- Verwenden und dokumentieren Sie je OPC-Router-Instanz eine eigene Programm-ID für RFC- und IDoc-Trigger.
- Planen Sie Änderungen an SAP-Triggern so, dass das Verhalten nach Veröffentlichung und Dienstwechsel nachvollziehbar überprüft werden kann.