The receiver, which may be WBI-C supplied or user provided, receives a request from an initiating partner. It:
Next it creates the WBI-C specific headers (the BCGHeaders) and sets them on the request document by calling the setAttribute method for each header.
The receiver calls preProcess on the Receiver Framework. The Framework executes the handlers, either Connect supplied or user defined, that have been specified for this target via the Console, in the order they are shown in the Console configuration screen. The request document is passed as input to the first handler, and then the returned processed document is fed as input to the next handler, and so on. The document is processed.
The receiver calls syncCheck on the Receiver Framework. The Framework iterates through the list of handlers (WBI-C and/or user supplied) defined for this transport and target. When it finds a handler that can manage the document, it executes sync check. In the case of a blocking synchronous request, it returns 'true'.
The receiver calls process on the Framework by passing it the target type, the request document, and an empty response document that it has created.
The Framework adds two attributes to the BCG headers on the request document: RESPONSE_URL and REPLY_TO_MSG_ID. RESPONSE_URL contains a WBI-C internal Sync response servlet URL and REPLY_TO_MSG_ID contains the request document's UUID.
The Framework creates the necessary BPE input files in the sync_in directory. It then calls waitForSyncResponse on SyncEngine, which will get notified when the Sync servlet receives the response from DeliveryManger (the component that includes Senders.)
A WBI-C internal process reads the files from the sync_in directory, creates the business document object, and non-repudiates the data. It logs the document and related information into the activity table, and writes the business document into the BPE synchronous inbound queue.