Destinations-Objekt und Unit-Objekte erzeugen 

Verwendung

Destinations-Objekt und Unit-Objekte erzeugen

 

Voraussetzungen

Die Objekte destination repräsentieren jeweils genau ein Ausführungsziel oder eine Menge von Ausführungszielen. Mit Hilfe der Klassenmethoden der beiden Klassen CL_BGRFC_DESTINATION_OUTBOUND und CL_BGRFC_DESTINATION_INBOUND können Destinations-Objekte angefordert werden. Die Destination für Outbound muss dabei in der SM59 gepflegt sein und ein Ausführungsziel für den neuen bgRFC (t/qRFC) darstellen. Die Destination für Inbound muss in der Customizing-Tabelle xx gepflegt sein. Die Destination im Inbound-Fall entspricht dem Namen der Anwendung!

Ansonsten kommt es zur Ausnahme CX_BGRFC_INVALID_DESTINATION.

 Der Gültigkeitsbereich der Destinations-Objekte erstreckt sich über die gesamte Laufzeit des Programms.

 

Vorgehensweise

Eine automatische Registrierung von noch nicht registrierten Destinationen erschien kritisch, da eine unregistrierte Destination immer als „klassisch“ gekennzeichnet ist. Sollte diese unregistrierte Destination nun aus Versehen mit dem neuen bgRFC-API gefüllt werden, so muss bei einer automatischen Registrierung diese Destination erst wieder auf den bestehenden qRFC umgestellt werden, bevor sich das System wieder so verhält wie bisher. Das Umstellen von Destinationen stellt außerdem eine kritische Operation dar, insbesondere dann, wenn bereits Queues zu dieser Destination gefüllt sind oder die Destination bereits innerhalb eines internen Modus verwendet wird. Somit ist der neue bgRFC dann ebenso aktivierbar wie die Verwendung des neuen RFC-Protokolls.

Die Angabe der Destinationen NONE und SPACE wird nicht unterstützt. Innerhalb eines internen Modus wird für jedes Ausführungsziel genau ein Objekt erstellt, d.h. pro Ausführungsziel stellt destination ein Singleton dar.

Die beiden Interfaces IF_BGRFC_DESTINATION_OUTBOUND und IF_BGRFC_DESTINATION_INBOUND ermöglichen jeweils den Zugriff auf die notwendigen Methoden zum Anfordern von neuen Hintergund-Units. Die sich dahinter verbergenden Klassen sind für die Nutzung von t/qRFC nicht relevant und werden im folgenden UML-Diagramm nur der Vollständigkeit halber aufgeführt.

Grafik: Methoden für Destinationen

Über die Destinations-Objekte wird gesteuert, ob die Hintergrund-Unit im lokalen (Inbound) oder in einem entfernten System (Outbound) verarbeitet werden soll.

 

Ergebnis

Der Unterschied zwischen qRFC-Units und tRFC-Units ist die verlangte Quality-of-Service (Q-o-S). Bei qRFC ist es die Q-o-S exactly-once-in-order (EOIO) und bei tRFC ist es die Q-o-S exatlly-once (EO). Damit bei qRFC-Units die Reihenfolge garantiert werden und trotzdem eine Parallelisierung von unabhängigen Units erfolgen kann, wird die Abhängigkeit über Queues realisiert. tRFC-Units haben keine Queue-Zugehörigkeit und können immer parallel prozessiert werden.

 

 In einigen Fällen ist es notwendig, dass eine Unit an verschiedenen Destinationen versendet wird. Damit solche Units nicht mehrfach aufgebaut werden müssen, gibt es die Möglichkeit über die Methode CREATE_GROUP Destinationsgruppen anzulegen. Für die angegebenen Destinationen müssen die bei der Methode CREATE geforderten Eigenschaften erfüllt sein. Außerdem müssen alle in einer Destinationsgruppe zusammengefassten Destinationen das gleiche RFC-Protokoll verwenden. Ansonsten kommt es zu der Exception CX_BGRFC_INVALID_DESTINATION mit dem Textelement DIFFERENT_RFC_PROTOCOLS.