Maybe you could a job to select the db-table eh for all hanging jobs and send this with email. This is maybe only smart then where not so many "normal" hanging jobs an the afternoon ;-)
In a sqli-vara you could use this statement to select all jobs in the queue that have a breakpoint manually set in them:
select ejpp_ah_idnr runid, ejpp_object jobname from ejpp where ejpp_status = 1562;
Regards,
Toni
------------------------------
Administrator and Developer Jobautomation
BNP Paribas S.A. Niederlassung Deutschland
------------------------------
Original Message:
Sent: 07-05-2019 03:56 AM
From: Benedikt Weiler
Subject: Best practises on one time/ad hoc changes of scheduled workflows/tsasks
Hi,
Thanks for your replies.
Our process is running during the night and we have no 24/7 support.
If the something is going wrong we will see it in the morning when we are starting to work.
I just want to avoid such silly delays in the morning, by forgetting to enable for example the active flag again.
The only thing i have in mind currently is in case of ad hoc / onetime changes to duplicate the workflow at let the "original" workflow untouched.
But this is not really smart.
regards,
Benedikt
Original Message:
Sent: 07-05-2019 02:38 AM
From: Toni Waechter
Subject: Best practises on one time/ad hoc changes of scheduled workflows/tsasks
We use some kind of monitoring (select all active workflows in queue and compare their actual runtime with the average runtime for this workflow from uc4 plus 12 hours so not any shot workflow would alarm on a minimal runtime overdue).
But that is not perfect as we have some (few) workflows that change their runtimes pretty often.
On critical workflows with a known finishing time you can use the runtime overdue function in the workflow (or job) itself and let uc4 send you an email to inform for the overdue. We use this kind of "alarm" in a few workflows too.
------------------------------
Administrator and Developer Jobautomation
BNP Paribas S.A. Niederlassung Deutschland
Original Message:
Sent: 07-04-2019 04:52 AM
From: Benedikt Weiler
Subject: Best practises on one time/ad hoc changes of scheduled workflows/tsasks
Hi,
I am wondering if anyone else here has the same situation:
Example:
You need to set a break point in a scheduled workflow for any reason and afterwards you forget to remove the break point.
I had it yesterday and it ended up that files were downloaded but not imported in the system because of the break point. We have a delay now of 3-4 hours.
Is there any way/report to identify such cases?
In my former company i've set up a report (different scheduling system "Redwood") which was checking if something in the workflow is different as in the initial setup. If so, a report was generated and sent in the afternoon.
How do you deal those situations?
Thanks in advance for your input.
regards,
Benedikt