One receive port triggering another?

We are receiving data files from mainframes which are not locked as they grow or are being transferred. To signal completion of the file transfer, the mainframe writes out a trigger file (signalling its done).

Naming convention is <filename>.dat and <filename>.trg

How can I use a messaging only solution for picking up the data file With 2 receive ports, the first one has the file mask set to <filename>.trg. Once it find the trigger file, we can be sure the <filename>.dat has stopped growing and ready for pick up. So bascially the first receive port should trigger the second one.

Its an interesting challenge to wire up messaging only solution with no Orchestrations for this

I want to do this the quick and dirty way - without even an Orchestration - which is relatively easy with a convoy on the <filename> only.

A custom file adapter is the most difficult way to do this. I want a solution I can implement within 2 hours. Sometimes (in production) speed is necessary.

Kent Weare wrote:

I had a similar requirement for dealing with files written from SAP. We have "work" files and "signal" files that are stored in 2 different directories. When the .sig file is written, that is the trigger that the work file is available for pick up via BizTalk. Since SAP runs on Unix we were using the FTP Adapter. We looked into a Non-Sequential Convoy but we could not guarentee that the work file would get picked up before the signal file. We also toy'd with the idea of having a receive location polling for the just the .sig file, when the .sig file was consumed, we would connect using .Net using an FTP class and rename the work file so that it could be consumed by this Non-Sequential Convoy orchestration. What we settled on was a Unix script that would run every five minutes. The unix script would look in the sig folder for any sig files. When it found one it would then look for it's counterpart in the "work" folder. When it found the work file it would append ".BIZ" to the work file name. We then just built receive locations that looked for specific .BIZ files. This was was probably the simpliest way to get around this. This may not be your desired solution, but hopefully it provides you with a few more options

It is more sofisticated then simple orch activated by .sig file (this takes < 2hrs development also ). The reason was we also have the pattern for this "script activating orchestration" (it takes < 1 hr development ).