!--a11y-->
Verarbeitung von no_send-Units 
Alle mit dem Flag no_send geschriebenen Units müssen manuell wieder ausgelesen und gestartet werden.
Es wird davon ausgegangen, dass die Units eines NO_Send Szenarios immer für entfernte Systeme bestimmt sind! Da aus diesem Grund ein entfernter Aufruf möglich sein muss, wird die Schnittstelle über remote-fähige Funktionsbausteine bereitgestellt und nicht über ABAP-Objects Klassen. Dies schließt nicht die interne Verwendung von ABAP-Objekts aus. Ein weiterer Grund für die Bereitstellung der Funktionsbausteine anstelle von Klassen ist der Bedarf, die Methoden aus Non-ABAP Systemen (z.B. C-Programme) aufzurufen.
Der unten aufgeführte Funktionsbaustein ermittelt eine Zahl von Units, die parallel ausgeführt werden können, ohne Abhängigkeitsregeln zu verletzen. Das heißt, dass dieselben Regeln angewendet werden, wie in Inbound- und Outbound-Scheduler von qRFC. Abhängige Units werden erst geliefert, wenn Vorgänger-Units erfolgreich zurückgemeldet wurden und keine Sperre vorliegt.
Der Funktionsbaustein
CALL FUNCTION
'QRFC_GET_RUNNABLE_UNITS'
EXPORTING
* NO_STATUS_UPDATE =
destination
= 'my_destination'
max_units
= 100
IMPORTING
qrfc_units
= unit_tab
unit_states
= state_tab.
liefert die nächsten max_luws Units der Destination destination. Ist max_units kleiner oder gleich 0, so werden alle Units dieser Destination zurückgegeben.
Das Löschen/Rückmelden von no_send-Unit Einträgen geschieht mittels des Funktionsbausteins:
CALL FUNCTION
‘QRFC_CONFIRM_UNITS’
EXPORTING
unit_states
= state_tab.
Wenn die Units erfolgreich zurückgemeldet werden, dann werden sie gelöscht. Die Daten werden vorerst nur logisch gelöscht. Das Physische Löschen der Daten in der Datenbank erfolgt immer asynchron.
Wenn Fehler aufgetreten sind, dann werden sie
mit dem Tabellen-Parameter unit_error übergeben. Dies sorgt für ein Sperren
der betroffenen Units incl. der Hinterlegung des Sperrgrundes und der
Fehlerursache.