Great question. The parameters of the ATCRecieve file rule are:
- Prefix - the attachment variable holding the input data (from the request - DATAFILE)
- AttachmentVariable - The attachment variable to hold the extract file location (EXTRFILE)
- FileName - The path and naming convention for the extract file.
- Disposition (optional) - use "keep" to prevent the received file from being deleted (this is used for debugging).
The purpose of this rule is to receive a file from a request and dump it to disk. The path/filename of the file is stored in the attachment variable that is the second parameter (EXTRFILE). So, you could simply remove this rule and supply an EXTRFILE attachment variable with a path and filename of your extract data and not send it via the queue. You would have to ensure that the file is present and accessible to the IDS process, and you are also responsible for cleaning up the file after it is no longer needed. The only change to make this work is one of these options:
- Comment-out the ATCReceiveFile rule in your request type. Place a semicolon to the left of "function", e.g.
- Or, pass the EXTRFILE=\\mypath\EXTRabc123.xml attachment variable and do not pass the DATAFILE=xxx attachment variable.
My suggestion is the latter, since it will support both uses. If the file is attached as DATAFILE, it will still work - but if the path/filename is passed as EXTRFILE, the ATCReceiveFile rule will simply do nothing.
I am trying to experiment with this, utilizing option 2. My new Message looks like:
<?xml version="1.0" encoding="UTF-8"?>
but it is still trying to create the file and use that:
DM11084: Error in EXTInitXtr(): Unable to GENOpenExtFile(<\\mypath\extr9114e0da-f9ec-99bc-025a-0b73daf8e175-0-ids-1-.xml>,).