TI Error Behavior

[George Regateiro]

I have some questions on the behavior of TI during and error condition.

I have this code in the epilog tab that will kick off an email if a process errors

Code: Select all

if(long(GetProcessErrorFilename) > 0 );
errorlog = GetProcessErrorFileDirectory | GetProcessErrorFilename|';';
ExecuteProcess('Send_Error_Emails', 'errorlog' , errorlog);
endif;

Recently a processed errored because the ODBC could not opened and this code did not trigger and send me the email.

Is there any guidance out there for the behavior of TI in an error condition?

In my case I would have thought the email would still have been sent out since the epilog tab should have run and the there was a error log created. I know the code works since I received a log earlier this week at the same time that this occured.

[Michel Zijlema]

Hi George,

When a process encounters a major error (like an unavailable datasource), the process stops immediately - so the Epilog section will not be executed. Another thing is that, I think, the process errorfile and status will be available after finishing the whole process - so it will be impossible to retrieve this information on the Epilog tab of the process.

A way to get around this is by executing the process from another process and do the success/failure checks on the executed process in the initiating process.


Michel

[Renaud MARTIAL]

Hello George,

I recently had the same kind of behaviour, where a process A is calling a process B, which tried to access an inexistant subset.
Both processes (A and B) were stopped, and no error was returned despite the return code of ExecuteProcess( 'B) was tested.

I guess that when TM1 encounter an unexpected situation, it halts all the involved processes.

[addendum] ... so the solution proposed by Michel should'nt work

Regards,

Renaud.

[George Regateiro]

I think, the process errorfile and status will be available after finishing the whole process - so it will be impossible to retrieve this information on the Epilog tab of the process.
Michel

Michel, from what I have seen the physical file is not available until after the process has completed (unitl then there is the temp file denoted by the $) so for a minor error the TI will actually recognize that there was an error and you can check that condition within the process. What I do as a work around for the temp file is that I have a 30 second wait in my email exe so it gives the TI's enough time to complete the epilog tab and I attach the error log to the email.

Beyond the master calling process idea is there any other way to tell if a major error has occured?

[Mike L]

Beyond the master calling process idea is there any other way to tell if a major error has occured?

There is no way to try/catch a major error within the failing process itself because it has already aborted before it can execute any code to catch the error.

There are three conventional approaches to catching major errors: (1) catch it in a subsequent process queued in the same chore, (2) catch it in a parent process that executes the suspect process, or (3) catch it in a separate chore scheduled to run at a later time.

Status information can be communicated between processes using global TI variables or by writing to a control cube. At a minimum, each process could post that it started at the begining of its prolog and that it finished at the end of its epilog.

Perhaps if we ask nicely Cognos could provide a seperate "OnError" process tab in some furure release.... What I really want is some control flow scripting statements at the chore level, instead of just a primitive sequence of processes, but I am not holding my breath.

[Steve Rowe]

Mike L,

isn't

What I really want is some control flow scripting statements at the chore level, instead of just a primitive sequence of processes, but I am not holding my breath.

available to you via the ExecuteProcess command? This also passes the error code back to the calling process which gives you more options for error handling. IMO Chores are pretty much out of date except as a means to a schedule TIs.

Cheers,

[Mike L]

Yes, main-process calling sub-processes is the way to go. I am not holding my breath for a real job control language (JCL) for scripting chores. After all, that would be a giant leap backwards to the middle of the last century!

George was looking for alternatives to the ExecureProcess approach. The practical answer is: no, that is the way it is done. Yes, you may end up with a jumble of separate wrapper processes, stubs, & etc., but that is par for the course for a hybrid scripting/wizard framework.

[David Usherwood]

Prenez garde - I have heard (Steve R?) that heavy nesting of process has a nasty performance overhead - or were you able to get this addressed?

But yes, roll on a decent scripting environment. Applix (remember them) did put up a slide a year ago suggesting they were looking for an alternative, so (of course) I suggestd perl (the Swiss Army Chainsaw). Hyperion kind of did this, though in the end it came down to a set of libraries. Does give you all the openness you want. I can dream...

[hiits100rav]

Reviving this after a 8 years..

Since the code in the epilog doesn't execute, is there a way to identify the error log filename as GetProcessErrorFileName() would return blank in the parent process.

Thanks,
Saurabh