Andrew's suggestion is a good one that I have had success with in the past. The DFII session is the 'master' which starts the external tcl/wish process using ipcBeginProcess() . At this point you can choose either synchronous or asynchronous communication depending on your needs.
For example, with synchronous communication, you start the external script, wait for it to complete (effectively blocking the DFII session) and then the user can continue working after the external script is done.
With asynchronous communication you run the external script and effectively the communications occur in the background. This might be a little more complex but it gives greater flexibility. You define a data handler and an error handler, for example, to handle messages coming from the external process on stdout and stderr respectively. This also means that the DFII session will not be blocked, it can be used for other things while the 'slave' script is processing.
This method will allow you flexibility to automate things on the DFII side also, for example, when something arrives from the script on the data handler, it can process the data according to what you want to do. For example, you might have:
msg: "Missing data, try again"
So depending on the first item, the action might be to print a message, or to execute an action. You have control over the format and the communication "protocol" so make it fit your needs, the above is just a suggestion.
Hope this helps!