Bonjour,
J’ai paramétré trois relances toutes les minutes (pour test) sur une alerte configuré sur une transition d’état. Le premier déclencheur d’alerte fonctionne correctement, mais pas les autres.
Paramétrage de l’alerte :
Le délai entre 2 relances ne peut pas être inférieur au délai de la cron.
et elle n’a lieu que si les états n’ont pas changé entre temps.
D’après la cron c’est obligatoirement une heure entre chaque passage sinon ce serait un polling trop important d’aller chercher toutes les minutes s’il y a des états en retard.
Essayez avec 60 ou 120 minutes entre chaque relance.
Dans des cas d’usage normaux, on en fait 1 par jour pendant N jours.
Sinon il y a un hook getDeadlineDate dans l’objet métier qui permet de dire quand il faut faire la relance, par défaut c’est en fonction de la date de dernière mise à jour + délai de la relance paramétré, mais il y a des cas où on veut par exemple dire “une semaine avant une date d’échéance du dossier”.
Bonjour,
malgré le fait d’ajouter une relance >60 min, cela ne fonctionne pas …
on dirait que l’alerte ne capte pas l’objet sur lequel il faut appliquer la relance, d’après les logs :
2021-10-22 14:13:09,070|SIMPLICITE|ERROR||http://demo.simplicite.io:20128||ECOREDB001|system|com.simplicite.util.engine.ProcessLoader|query||Error SQL query: select usr_email from m_user where row_id=''
java.sql.SQLDataException: data exception: invalid character value for cast in statement [select usr_email from m_user where row_id='']
at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
at org.hsqldb.jdbc.JDBCPreparedStatement.<init>(Unknown Source)
at org.hsqldb.jdbc.JDBCConnection.prepareStatement(Unknown Source)
at org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.prepareStatement(DelegatingConnection.java:742)
at org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.prepareStatement(DelegatingConnection.java:742)
at com.simplicite.util.engine.DBAccess.query(DBAccess.java:615)
at com.simplicite.util.engine.DBAccess.query(DBAccess.java:413)
at com.simplicite.util.engine.ProcessLoader.loadAlert(ProcessLoader.java:751)
at com.simplicite.bpm.ProcessusDirect.loadAlert(ProcessusDirect.java:157)
at com.simplicite.objects.System.BPMState.manageDeadlineState(BPMState.java:103)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:4151)
at com.simplicite.util.engine.ObjectDirect.invokeAction(ObjectDirect.java:658)
at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:2080)
at com.simplicite.util.ScriptedObjectDB.invokeAction(ScriptedObjectDB.java:888)
at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:2048)
at com.simplicite.objects.System.CronTable.forceExecute(CronTable.java:65)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:4151)
at com.simplicite.util.engine.ObjectDirect.invokeAction(ObjectDirect.java:658)
at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:2080)
at com.simplicite.util.ScriptedObjectDB.invokeAction(ScriptedObjectDB.java:888)
at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:2048)
at com.simplicite.webapp.tools.JSONServletTool.action(JSONServletTool.java:1849)
at com.simplicite.webapp.ObjectJson.action(ObjectJson.java:678)
at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:643)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:89)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
Si le nom du champ dans la requête SQL est correct, visiblement l’instance “alert_xxx”, qui sert à l’envoi de d’alerte de votre objet, n’a effectivement pas le record en mémoire (remplacé par rien).
On va inverser certains traitements qui avaient été optimisés car le prepareSQL qui remplace les host values arrive sûrement trop tôt dans le processus.
Une façon de forcer le chargement en mémoire en attendant le correctif est d’implémenter le hook getDeadlineDate qui sert à donner la date d’expiration métier (par défaut, c’est la date dernière mise à jour update_dt + le délai du timeout du statut) :
public Date getDeadlineDate(String rowId, String state, String update_dt, int timeout) {
// Force a select to prepareSQL
select(rowId); // or selectWithoutFilters(rowId, false)
// default update_dt + timeout
return super.getDeadlineDate(rowId, state, update_dt, timeout);
}
pas sûre de comprendre.
Je dois appeler ce hook dans le script de l’objet métier pour forcer la relance de mon alerte par mail ?
j’ai l’impression que ça n’a rien avoir ?
Il suffit d’ajouter le code fournit dans l’objet métier qui utilise l’alerte.
Sinon passez à la version 5.1.11 qui a changé l’ordre des substitutions avec les valeurs de l’objet.
