FileGatewaySendMessage calls FileGatewayCompleteDelivery service at the end of execution. As of this writing at SI 188.8.131.52, this service in the BP takes message ID, consumer file name, among other things. However, it turns out that these two parameters are ignored by the service (confirmed by IBM Engineering in the PMR).
Although we understand FG's design of using custom file layer for file content handling and custom delivery protocol for delivery, there are cases we have to use custom delivery protocol to do the file content handling.
Two main reasons for this:
1) FG is essentially synchronous design. The FG route service (in FileGatewayMailboxRouteArrivedFile BP) will wait for custom file layer to complete before moving on. When the custom logic takes time, such waiting clogs up the system available thread pools. It is very obvious in our performance testing when viewing the FG behavior in queuewather. Regardless how we tune the two FG polling time parameters, the thread-hogging behavior remains the same, causing many other jobs to queue up.
2) there is no way to change consumer file name in custom file layer. Whatever name we assign to the consumer file before exiting the custom file layer BP will be ignored by FG.
Above two reasons (among others) forced us to move complex logic to custom delivery protocol potion of FG. We hope FG changes its design to solve above thread-hogging issue (for example, changing custom file layer to asynchronous call from the FG route service and invent a wake-up-notification mechanism when custom processing is done). Before that happens, we request enhancement to FGCompleteDelivery service to honor the input parameters so that the FG_DELIVERY table record reflects the final consumer file name and message ID. After all, FileGatewaySendMessage BP source code does have these parameters passed in to the service, leading (or misleading in the current case) people to believe the service is already doing so.