FileEvent: Monitoring failed !EVNT executions

[Daniel Dahlke]

Currently i'm looking for a solution to monitor failed !SCRIPT executions of an file event. Maybe someone has already a solution or hint how i can monitor these.

A file event is setup to monitor a directory for files. If more than x files are  found, the execution of !SCRIPT is triggered to handle the processing of these files.
But if there is a misspelled script variable or some other error within the uc4 script the execution of EVNT! fails.
For example:

:set &A# = sub(&B#,1)

simple using &B# without defining it anywhere

How can i monitor these failed executions and trigger the execution of a different object, for example CALL object, when this happens?
I already tried to define to execute an object under general->runtime-->execute an alternative object... if Return code is not 0. But it is not executed.
I guess it is meant for the SCRIPT instead of !SCRIPT part of the file event or the Returncode is zero also the exection fails.

I also tried to find a solution to check the state of the last executed !EVENT with a parallel periodic running SCRI object, but i didn't found a solution to get execution details for the childs of an file event.

Maybe someone of you will have an idea.

[Joel Wiesmann]

Hi Daniel

To get the childs of an event you can make use of an SQL VARA (/ SQLi) on the AE database.

This will read all active evens and get it's child executions. Make sure you replace the client number (here 9000) with a variable/substitution for your client number (i.e. &$CLIENT#)

with events as (
select 
  eh_ah_idnr as event_runid,
  eh_name as event_name
from eh
where 1=1
and eh_client = 9000
and eh_otype = 'EVNT'
)
select event_name, event_runid, ah_idnr as subprocess_runid, ah_status as subprocess_status
from events
join ah on ah_parentact = events.event_runid

You can narrow down the results further by filtering for status >=1800 & < 1900, activation/start time, object names etc. or you can just have one generic SCRI-monitoring object, polling the VARA for records to report.

In general, I would suggest that you limit your event process logic to the activation of another workflow. There you can then handle any other logic within the workflow tasks that are generated at runtime.

------------------------------
☎️ Swisscom Automation/AI Engineer & 🧙 PEM Creator

Online Automic Training 24/7:
https://membership.philippelmer.com/ (deutsch)
https://pemautomic.com (english)
------------------------------