Destinations-Objekt und Unit-Objekte erzeugen 

Verwendung

Destinations-Objekt und Unit-Objekte erzeugen

 

Vorgehensweise

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 für die Outbound-Queue und CL_BGRFC_DESTINATION_INBOUND für die inbound-Queue können Destinations-Objekte angefordert werden. Die Destination für die Outbound-Queue muss dabei in der Transaktion SM59 gepflegt sein und ein Ausführungsziel für den Outbound bgRFC Typ t und Typ q darstellen. Die Destination für die Inbound-Queue muss in der Transaktion SBGRFCMAINIDST gepflegt sein. Falls die Destination nicht gültig ist, kommt es zur Ausnahme CX_BGRFC_INVALID_DESTINATION.

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

 

Für die Outbound-Queue erschien eine automatische Registrierung von noch nicht registrierten Destinationen kritisch, da eine unregistrierte Destination immer als „alt“ gekennzeichnet ist. Sollte diese unregistrierte Destination nun aus Versehen mit dem neuen API gefüllt werden, so muss bei einer automatischen Registrierung diese Destination erst wieder auf „alt“ 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 bgRFC Typ t und Typ q 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 Typ q und bgRFC-Units Typ t ist die verlangte Quality-of-Service (Q-o-S). Bei bgRFC Typ q ist es die Q-o-S exactly-once-in-order (EOIO) und bei Typ t ist es die Q-o-S exactly-once (EO). Damit bei bgRFC-Typ q-Units die Reihenfolge garantiert werden und trotzdem eine Parallelisierung von unabhängigen Units erfolgen kann, wird die Abhängigkeit über Queues realisiert. bgRFC-Typ t-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.