11 octobre 2023

Corriger les messages "QRKRN2023 Error while parsing data" ou les filtrer avec log4j StringMatchFilter

Vous avez peut être rencontré dans les logs de HRD Query ces messages :
WARN - QRKRN2023 Error while parsing date 58,50
ou
QRKRN3024 Element /RPT/GRP[@level='...']/.../DTL/FLD[@id='...'] has no matching element in the datamodel

Noter qu’il ne faut pas lire « QRKRN2023 Error while parsing date » mais « Error while parsing data » (faute de typo)

Ces dizaines de milliers de messages encombrent parfois les fichiers de logs et provoquent une surcharge d’écriture sur disque. D’autre part ces fichiers log étant à rotation (5 fichiers de 5 mo en standard) - leur remplissage rapide peut faire perdre des messages d’erreur importants plus anciens.

Pour supprimer ces messages il faut corriger les traitements d'édition concernés

En l’occurrence un champ numérique
  • Ne doit pas contenir d’espaces en début
  • Doit avoir un séparateur de décimales sous la forme d’un « . » et non d’une « , »
Dans l’attente d’une correction des éditions HR - et à titre de « solution temporaire », il peut être utile de mettre en place un filtrage des messages par log4j

Dans $SIGACS/query/conf/query_log.properties ajouter les lignes en rouge suivantes, puis redémarrer le serveur de Query batch :

# ========================
# logs configuration file
# ========================

#
# OFF < FATAL < ERROR < WARN < INFO < DEBUG < ALL.
#

log4j.rootLogger = info, consoleappender, fileappender
log4j.logger.com.hraccess = INFO, consoleappender, fileappender
log4j.additivity.com.hraccess = false

# =================================================================================

# By default, the activation of the debug mode causes :
# - The generation of EditingFileConnectorXXXXX.zip, BatchEditingConnectorXXXXX.zip
#   files in the logs directory.
# - The persistence of LYTXXXXX.tmp directories in the work directory
#
# To avoid this behaviour while activating the debug mode uncomment either of
# the following lines.
# =================================================================================

 

#log4j.logger.com.hraccess.log.hrjs.workfiles=off
#log4j.logger.com.hraccess.log.qrkrn.workfiles=off

 

# CONSOLE
log4j.appender.consoleappender=org.apache.log4j.ConsoleAppender
log4j.appender.consoleappender.target=System.out
log4j.appender.consoleappender.layout=org.apache.log4j.PatternLayout
log4j.appender.consoleappender.layout.ConversionPattern=%d{ISO8601} %X{runtime.context} %-5p %c{1} - %m%n

 

# MAIN LOG FILE
log4j.appender.fileappender=org.apache.log4j.RollingFileAppender
log4j.appender.fileappender.File=${hrjmods.log.dir}/qrsrv.log
log4j.appender.fileappender.MaxFileSize=5MB
log4j.appender.fileappender.MaxBackupIndex=5
log4j.appender.fileappender.layout=org.apache.log4j.PatternLayout
log4j.appender.fileappender.layout.ConversionPattern=%d{ISO8601} %X{runtime.context} %-5p - %m%n

# Filtres pour laisser passer QRKRN2023, QRKRN3024 puis autoriser DEBUG INFO WARN ERROR FATAL
log4j.appender.fileappender.filter.01=org.apache.log4j.varia.StringMatchFilter
log4j.appender.fileappender.filter.01.StringToMatch=QRKRN2023
log4j.appender.fileappender.filter.01.AcceptOnMatch=false
log4j.appender.fileappender.filter.02=org.apache.log4j.varia.StringMatchFilter
log4j.appender.fileappender.filter.02.StringToMatch=QRKRN3024
log4j.appender.fileappender.filter.02.AcceptOnMatch=false
log4j.appender.fileappender.filter.11=org.apache.log4j.varia.LevelMatchFilter
log4j.appender.fileappender.filter.11.levelToMatch=DEBUG
log4j.appender.fileappender.filter.11.AcceptOnMatch=true
log4j.appender.fileappender.filter.12=org.apache.log4j.varia.LevelMatchFilter
log4j.appender.fileappender.filter.12.levelToMatch=INFO
log4j.appender.fileappender.filter.12.AcceptOnMatch=true
log4j.appender.fileappender.filter.13=org.apache.log4j.varia.LevelMatchFilter
log4j.appender.fileappender.filter.13.levelToMatch=WARN
log4j.appender.fileappender.filter.13.AcceptOnMatch=true
log4j.appender.fileappender.filter.14=org.apache.log4j.varia.LevelMatchFilter
log4j.appender.fileappender.filter.14.levelToMatch=ERROR
log4j.appender.fileappender.filter.14.AcceptOnMatch=true
log4j.appender.fileappender.filter.15=org.apache.log4j.varia.LevelMatchFilter
log4j.appender.fileappender.filter.15.levelToMatch=FATAL
log4j.appender.fileappender.filter.15.AcceptOnMatch=true
# Filtre pour bloquer tous les messages qui ne sont pas déjà  autorisés
log4j.appender.fileappender.filter.20=org.apache.log4j.varia.DenyAllFilter

 

# THREAD APPENDER
log4j.appender.threadappender=com.hraccess.logging.ThreadFileAppender
log4j.appender.threadappender.Directory=${hrjmods.log.dir}
log4j.appender.threadappender.layout=org.apache.log4j.PatternLayout
log4j.appender.threadappender.layout.ConversionPattern=%d{ISO8601} %X{runtime.context} %-5p - %m%n


4 octobre 2023

eDSN - Erreur : la table d'historique contrat doit être initialisée

Suite à une recopie de données entre bases, eDSN ne démarre plus correctement. Dans les logs on trouve le message : 
Erreur : la table d'historique contrat doit être initialisée si la gestion intégrée des blocs 41 est activée (com.soprahr.edsn.historiquecontrat.cfg)

Pour recharger cette table il faut lancer la commande dsn:init-historique-contrat ou dsn:init-historique-contrat-ext... mais celle ci sera introuvable !? Ceci tient au fait que eDSN est en erreur ...

Les étapes consistent en effet à :
  1. Inhiber la gestion du bloc 41 avec la table historiquecontrat
  2. Redémarrer eDSN
  3. Recharger la table
  4. Réactiver la gestion du bloc 41 avec la table historiquecontrat
  5. Redémarrer eDSN
 
Pour inhiber (respectivement activer) l'option, éditer le fichier edsn-home/conf/com.soprahr.edsn.historiquecontrat.cfg et passer le paramètre enable à false (respectivement true)

Après redémarrage lancer la commande dsn:init-historique-contrat (la version dsn:init-historique-contrat-ext permet de paralléliser) en précisant les périodes de début/fin (respecter la profondeur de rappel en paie)

Dans mon cas la fermeture du VPN a interrompu un premier lancement. La table est donc partiellement alimentée. Il faut donc recommencer et répondre à la question « confirmez-vous … » en avant plan ...

Mais le traitement étant long, il vaut mieux le lancer en arrière-plan pour ne pas subir de nouvelle interruption.

Pour cela on crée un script lanceur à déclencher avec nohup &.  Le "echo oui" est chargé de répondre à la demande de confirmation ... !


init-histo.ksh 
{ echo "dsn:init-historique-contrat-ext -t 5 202208 202308" ; echo oui; } | /hr9dev/edsn-9.1.3/bin/client


nohup ksh init-histo.ksh > init-histo.log 2>&1 &
[1] 25100788


cat init-histo.log 

Espace DSN (9.1.3) - Environnement de Production : non
Apache Karaf Runtime (4.3.9)
...
edsn> dsn:init-historique-contrat-ext -t 5 202208 202308

L'historique des contrats est deja alimente. Confirmez-vous sa reinitialisation (les donnees actuelles seront perdues) ? (oui/non)

oui
Traitement de la periode 202208
Traitement de la periode 202209
Traitement de la periode 202210
Traitement de la periode 202211
Traitement de la periode 202212
Traitement de la periode 202301
Traitement de la periode 202302
Traitement de la periode 202303
Traitement de la periode 202304
Traitement de la periode 202305
Traitement de la periode 202306

Traitement de la periode 202307
Traitement de la periode 202308
Initialisation terminee
edsn>


Puis mise à jour de com.soprahr.edsn.historiquecontrat.cfg (enable = true) et redémarrage de eDSN.