Inbound Scenarios

As with the outbound scenarios, the classic qRFC and the new bgRFC procedure coexist. Therefore, it is necessary to offer a migration path for inbound qRFC. This is closely linked to the prefix of queue names in inbound scenarios. As mentioned before, the table BGRFC_CUST_MGRA plays a vital role in the migration of inbound qRFC.

The migration of inbound qRFC units primarily involves the temporary synchronization of classic and new bgRFC units. At a defined moment, a check is made to see whether the classic queues contain units (or LUWs) that use queue names that must be used with the new procedure (in accordance with their prefixes). These prefixes are stored in the table BGRFC_CUST_MGRA.

As with the outbound scenario, appropriate locks are generated in the new queues; these are removed automatically. To enable this, special units are placed in the classic queues. The moment at which the system checks whether queue prefixes are used in both new and classic queues, is the moment in which a new prefix is registered in the table BGRFC_CUST_MGRA. This means that the table is maintained using a special transaction. An API is provided for program maintenance of the table BGRFC_CUST_MGRA.

Prefixes are also checked in the classic qRFC API; if they exist as bgRFC prefixes in the Customizing tables, a short dump with message type X is generated.