!--a11y-->
Inbound-Szenarien 
Wie bei den Outbound-Szenarien koexistieren das klassische qRFC und das neue bgRFC-Verfahren. Daher ist es notwendig, für Inbound qRFC einen Migrationspfad anzubieten. Dieser ist bei den Inbound-Szenarien eng mit dem Präfix von Queue-Namen verbunden! Wie bereits erwähnt spielt die Tabelle BGRFC_CUST_MGRA eine Rolle bei der Migration von Inbound-qRFCs.
Bei der Migration von Inbound-qRFC Units geht es primär um eine zeitlich begrenzte Synchronisation von klassischen und neuen bgRFC-Units. Zu einem festgelegten Zeitpunkt wird überprüft, ob in den klassischen Queues Units (bzw. LUWs) vorhanden sind, die Queue-Namen verwenden, die mit einem Präfix beginnen, welcher ab sofort mit dem neuen Verfahren verwendet werden soll. Diese Präfixe sind in der Tabelle BGRFC_CUST_MGRA hinterlegt.
Wie im Outbound-Szenario werden entsprechende Sperren in den neuen Queues erzeugt, welche automatisch entfernt werden. Hierfür wird jeweils eine spezielle Unit in die klassischen Queues gestellt. Der bereits erwähnte Zeitpunkt, zu dem überprüft wird, ob es eine Überschneidung der Verwendung von Queue-Präfixen in neuen und klassischen Queues gibt, ist der Moment, in dem ein neuer Präfix in der Tabelle BGRFC_CUST_MGRA registriert wird. Daher wird die Pflege der Tabelle über eine spezielle Transaktion bereitgestellt. Es wird zusätzlich ein API zur Verfügung gestellt, um die Pflege der Tabelle BGRFC_CUST_MGRA programmatisch zu machen.
Präfixe werden auch im klassischen qRFC-API überprüft und falls Sie als bgRFC Präfix in den Customizing Tabellens existieren, wird ein Kurzdump mit der Message Type x ausgelöst.