First I'll explain the context, because maybe I'm not doing it in the right way.
We have an ERP developed using Oracle Forms 6i (yes, is really old). It has forms and reports. Reports have such complex queries that when run with ample dates the output is available only after an hour or more, so these reports are scheduled in the Task Manager. The task invokes a .bat, the .bat invokes Forms Runtime (a .exe), Forms Runtime runs a form and this form runs a report. I'm not going through why all of this. The point is that this tasks are scheduled in a Windows XP and I want to move these to one of our servers (I'm trying to make this work in Server 2012R2).
After some attempts and research I decided to move from .bat scripts to powershell. I've got the ps1 running but I have some issues I don't know how to solve: 1- Scheduled task that invokes PS1 script runs for a second and ends after forms/reports end their execution. 2- Scheduled task stays in "running" after forms/reports end.
My PS1 script is something like this:
param (
[Parameter(Mandatory=$true)]
[alias ("form")]
[string]$formulario = $(throw "-form parametro obligatorio.")
)
try
{
BEHAVIOUR 1
Start-Process -FilePath "C:\orant\BIN\ifrun60.EXE" -WorkingDirectory <SOMEPATH> -ArgumentList "$formulario <oracle_conn_credentials>"
BEHAVIOUR 2
Start-Process -FilePath "C:\orant\BIN\ifrun60.EXE" -WorkingDirectory <SOMEPATH> -ArgumentList "$formulario <oracle_conn_credentials>" -Wait
}
catch
{
LogWrite "ERROR."
LogWrite $Error[0]
}
Where:
- $formulario is input param like \blah\blah\blah\.fmx
- LogWrite is a function I use to log the execution, not needed in this case as this function is fully tested
- The line with "Behaviour 1" is the line that produces the scheduled task to end too soon. I suppose it's because I'm using Start-Process and this starts a new independent thread. This took me to the next point:
- The line with "Behaviour 2" is the line that makes scheduled task to never end. It's like the previous line but added a "-Wait" so the powershell script waits for the process to end.
In both situations, also, I've seen that Reports Runtime process never ends though reports are correctly generated. This could be the reason for script does not end, but script is runing Forms Runtime, and Forms Runtime is the one invoking Reports Runtime. By the moment that all reports have ended, Forms Runtime finishes but nor Reports Runtime nor Powershell processes end.
I hope I've explained it clearly enough. If there's no solution, any workaround would be highly appreciated.
EDIT: OK, I've discovered several things... First, I've found the way to powershell to behave more or less like I want. And this is achieved using Start-Process -PassThru
. It would be something like:
$proceso = Start-Process -FilePath "C:\orant\BIN\ifrun60.EXE" -WorkingDirectory <SOMEPATH> -ArgumentList "$formName <oracle_conn_credentials>" -PassThru
$handle = $proceso.Handle
$proceso.WaitForExit();
I've got this solution after reading third answer to this question: https://stackoverflow.com/questions/10262231/obtaining-exitcode-using-start-process-and-waitforexit-instead-of-wait Fine, now my process ends so scheduled task also ends. BUT, a subprocess remains running forever. Reports Runtime opens a console that lets you know if a report is running and shows a log of executed reports. Usually this console is ignored and it's window closed when exiting from the report (manually, with a click in the upper right X). But since report is generated from scheduled task without a user interface (in task manager you can see it's run with session_id = 0 which means no human interface), this console can't be manually closed and process remains untill you kill it. So the question now has changed: is there a way to identify this subprocess? Remember: task scheduler runs powershell script, ps runs oracle forms and oracle forms runs oracle reports. I need to identify this oracle reports process. Bear in mind that I plan to run this with several forms/reports and that there can be 2 instances of this running at the same time, with the same user.