Problem
You are experiencing troubles with automatic tasks which are triggered with timers in the process Engine.
Troubleshooting
There are a few things you can check yourself, to make sure everything is configured the way it should.
Blueriq implementation of Quartz
First of all, we’re going to look into the Blueriq part of Quartz. With a few questions we will have the necessary checks to make sure Quartz is working or not.
Our assumption on your situation: The timers are not triggered.
- Do you have 1 DCM Project, or do you have multiple projects?
- Mulitple projects
- Is the timer not working for multiple projects
- Each project needs to be started manually. This have to be done once when using quartz in database. Also you have to start projects manually when creating new projects or running on new servers.
- When having Quartz running in memory you need to manually start all projects after each restart of the server.
- One project
- Make sure you started the project.
- When having quartz for multiple projects, you can see the registered timer triggers in the database table: QRTZ_TRIGGERS. For each DCM project there should be a trigger in this table.
- Is the timer not working for multiple projects
- Mulitple projects
So, this was the first Blueriq part. You now know your configuration should work in theory. If the triggers are still not working, we’re going to look into quartz settings.
Quartz Settings
Timestamp
When debugging the quartz settings, we have to make use of timestamps. These timestamps are in milliseconds. To see what exact date/time this is, you can make use of https://www.timestampconvert.com/ .
In the previous step we made sure there are triggers available in the database. When they’re available, but still won’t work it’s time to check the following:
- In the QRTZ_TRIGGERS table, make sure the NEXT_FIRE_TIME is in the future.
- For a correct working trigger the TRIGGER_STATE should be WAITING
- When the NEXT_FIRE_TIME is in the past, the trigger is not working. You can delete this trigger from the database by removing the row from this table. if you do this you need to recreate the trigger. For this you need to restart the Blueriq Runtime, once the Runtime is started again, start a flow for this project. After this you should see the timer again in the QRTZ_TRIGGERS database table.
- You can also check LAST_FIRE_TIME. This will tell you if the trigger indeed fired.
If you performed these steps and you were positive on all above questions, we can now be sure that Quartz is working and firing triggers like it should.
Blocked triggers
When the TRIGGER_STATE is BLOCKED, this means that a previous instance of the job started by the trigger is still running. Once this job finishes, Quartz will set the trigger state to WAITING.
Blueriq Logging Quartz
The fact that Quartz is triggering timers doesn’t mean your issue is solved. Therefore we’re going to see if we can find a cause for the issue.
The first step is to adjust the logging level. Be careful adjusting the logging level may result in a large amount of log. This is a temporary setting so we can debug. This has to be adjusted to normal levels as soon as possible.
To adjust the logging level, you have to open the application.properties and add the following line in the logging section: logging.level.com.aquima.interactions.process.impl.ProcessEngine = DEBUG
*
*Make sure ProcessEngine is in CamelCase.
- After adjusting the loglevel, check the NEXT_FIRE_TIME.
- When the trigger is fired, that timestamp should be the LAST_FIRE_TIME.
- Lookup the exact timestamp from the LAST_FIRE_TIME.
- Open the log, and search for the timestamp of the LAST_FIRE_TIME.
- At that exact same time, you should be able to see some logging about Quartz.
- Loading * cases with timers
- Finished loading
- Evaluation of * cases Starting
- Evaluation of * cases completed.
- If the amount of cases is zero, then Quartz is working as it should, but while you expected cases to be triggered, In fact there aren’t any
- If, however there are cases starting, but none completed, or some completed, but you see nothing happening, there’s something wrong.
At this point, when you are sure somethings wrong, we can try to help you and see what the problem is.
If there are no cases starting, you should look into your model and analyze why you were expecting cases to be triggered.