29 janvier 2013

Paramètre "general/max_threads" de HR Query

A compter de HRv7.20.6, les paramètres de configuration "batch_query/max_running_threads", "batch_editing/max_running_threads" et "tp_query/max_running_threads" (paramètres techniques du module "HRD Query" dans l'objet topologie "HRS") ont été remplacés par un unique paramètre "general/max_threads" (dixit le PDF Editeur listant les évolutions de la release).




Ce paramètre définit le nombre maximal de tâches (sélection / extraction / mise en forme) que le serveur de query peut traiter simultanément.

Sa création est associée à un changement dans les mécanismes de parallélisation du dispatching des XML Data pour les états PDF, HTML, CSV pour tirer parti de toute la puissance de calcul des machine multi-cœurs.

La valeur de ce paramètre dépend des capacités physiques de la machine ainsi que du quota de puissance qui lui est alloué. Par défaut,la valeur de ce paramètre vaut "0" ce qui signifie "Autant de threads que la machine comporte de processeurs". Dans le cas contraire c'est le nombre spécifié qui sera pris en compte... En toute logique sur une machine hébergeant plusieurs environnements il faut limiter ce nombre.

Un second paramètre "general/threading_strategy" apparait. Il prend deux valeurs :
  • "performance" (valeur par défaut - utilisera le maximum de threads possible) 
  • "latency" (utilisera moins de threads pour pouvoir mieux répartir la puissance)

Dans le cas d'une valeur "performance", si une requête qui génère beaucoup de tâches parallèles est soumise en premier, celle-ci va monopoliser le serveur de query pendant tout le temps de son exécution. Les requêtes suivantes devront patienter en file d'attente.

A l'inverse si le paramètre est positionné à"latency", les threads seront alloués pour équilibrer les performances des tâches en parallèle. Ce mode a l'inconvénient de moins tirer bien parti des capacités de calcul de la machine. Sur un traitement particulier l'écart peut atteindre 25 à 30% - prévient l'éditeur.

28 janvier 2013

Déplacer les logs et les fichiers de travail de HRaSpace

Si vous consultez les fichiers web.xml des applications HRaSpace v7, vous noterez que les paramètres d'accès aux répertoires logs et works sont "variabilisés".

<param-name>com.hraccess.dir.conf</param-name>
<param-value>${com.hraccess.richclient.dir.conf}</param-value>


<param-name>com.hraccess.dir.logs</param-name>
<param-value>${com.hraccess.richclient.dir.logs}</param-value>


<param-name>com.hraccess.dir.work</param-name>
<param-value>${com.hraccess.richclient.dir.work}</param-value>


Il est donc possible de déplacer proprement ces fichiers logs et temporaires dans un répertoire spécifique. Pour ce faire il faut valoriser les variables en complétant la variable JAVA_OPTS - par exemple (pour Tomcat) dans le script catalina.sh ou setenv.sh :

JAVA_OPTS="$JAVA_OPTS""  -Dcom.hraccess.adminconsole.dir.logs=/hraref/hraspace/logs -Dcom.hraccess.portal.dir.logs=/hraref/hraspace/logs -Dcom.hraccess.hrconftool.dir.logs=/hraref/hraspace/logs -Dcom.hraccess.dms.dir.logs=/hraref/hraspace/logs -Dcom.hraccess.portlet.dir.logs=/hraref/hraspace/logs -Dcom.hraccess.selfservice.dir.logs=/hraref/hraspace/logs -Dcom.hraccess.richclient.dir.logs=/hraref/hraspace/logs"

La mise a jour nécessite un arrêt démarrage pour être prise en compte.

La nouvelle valeur est bien reportée dans la console :


NB : il est de la même manière possible de déplacer les répertoires "conf" - mais il y a quelques difficultés pour l'application hra-space - car pour jetspeed (le moteur du portail) certains liens restent positionnés en relatif sur "/conf".

22 janvier 2013

Page InstallManualApplet.html du client riche

Je suis tombé sur une page HTML supposée servir à récupérer l'applet HR Access sans avoir à se connecter (pour la distribuer dans les caches des JVM des postes clients) :

http(s)://<server>:<port>/hr-rich-client/InstallManualApplet.html

Ci dessous un exemple de page InstallManualApplet.html

<!--/* -----------------------------------------------------
*  WARANING : THIS FILE IS GENERATED, DO NOT UPDATE IT
* -----------------------------------------------------
 */-->
<HTML>
<BODY>
<APPLET CODE="com.hraccess.webclient.applets.AppletHRAccess" STYLE="display:none">
<PARAM name= "namespace" value="HRApplet720070071135">
<param name="useslibrary" value="HRApplet720070071135">
<param name="useslibrarycodebase" value="hrappleti.cab">
<param name="useslibraryversion" value="720070071135">
<PARAM Name="TOPICURL" VALUE="">
</APPLET>
</BODY>
</HTML>



Ensuite ... Cette page ne fonctionne pas (erreur Java - class not found) ... Et si je corrige value="hrappleti.cab" en value="hrapplet.jar" cela ne change rien ...

Pas le temps d'aller plus loin. Si vous avez des idées, je suis preneur.

10 janvier 2013

Error: OpenHRServer process $PID found, please stop it before.

Depuis HRv7 le script d'arrêt et de démarrage de OpenHR dispatcher.sh :
  • stocke le n° de processus de OpenHR dans $SIGACS/openhr/bin/.OpenHR.running,
  • contrôle la présence effective du processus Unix.
Donc normalement, si vous recevez ce message au démarrage de OpenHR, c'est que le dispatcher est déjà démarré.
Vous pouvez le contrôlez en tapant :  
ps -fu $LOGNAME | grep [o]penhr

C'est une (très) bonne chose, mais ce contrôle présente une erreur de syntaxe :
nb=`ps -ef | grep $PID | grep -c -v "grep"`

Le calcul qui est fait peut ramener des occurrences inopportunes :
  1. Si le PID de OpenHR est 525, ce grep va aussi comptabiliser les processus dont le numéro contient 525 (comme par exemple 6525 et 5259),
  2. Si le fichier .OpenHR.running est obsolète et que le numéro de processus qu'il contient a été réutilisé par le système (par exemple s'il existe un processus 525 désormais attribué à un processus de la base de données).

Je vous propose de remplacez cette ligne (présente deux fois dans le script) par :
nb=`ps -fp $PID | grep -c "openhr"`

8 janvier 2013

Micro Focus LMF - 004: You have exceeded the license limit for this product

Sur une même machine Unix, le nombre de compilations Cobol simultanées est limité par le nombre de clefs de licence de "Developement" achetées. Si ce nombre est dépassé, la compilation sort en erreur avec le message suivant :

Micro Focus LMF - 004: You have exceeded the license limit for this product.
No more licenses for this product are available.
All of the 0001 license units in the license database are in use.
Execution of this product has been terminated.
Contact your license administrator or Micro Focus product supplier to obtain additional license units.

Dans l'exemple ci dessus, la machine ne dispose que d'une clef. Donc sur la machine une seule compilation peut être exécutée à la fois.

Il est possible de demander la "mise en attente" de la compilation - ce qui évite de voir le traitement de génération sortir immédiatement en erreur. Ceci en positionnant la variable LMFWAIT : celle ci permet d'indiquer un nombre maximum de tentatives et un delai entre chaque tentative.

LMFWAIT=6,10
export LMFWAIT

Dans cet exemple, si la clef de compilation est déjà prise, le traitement fera 6 tentatives toutes les 10 secondes avant de sortir en erreur. Un message d'alarme est alors affiché :

Micro Focus LMF - 016: You have exceeded the license limit for this product. 
No more licenses for this product are available.
All license units in the license database are in use.
** Waiting for license unit to become available **
Contact your license administrator  or Micro Focus product supplier to obtain additional license units.

3 janvier 2013

Planifier un traitement par "crontab"

Sur les systèmes Unix les fichiers paramètres "crontab" servent à planifier des traitements réguliers (par exemple les arrêts/démarrages quotidiens ou la purge des fichiers obsolètes). Ils sont consultés et pris en charge par un processus système nommé "cron".

$  ps -ef | grep cron
    root  364580       1   0   Dec 28      -  0:05 /usr/sbin/cron 


Certains sites n'ayant pas d'outils d'ordonnancement peuvent aussi utiliser le "crontab" pour planifier les traitements fonctionnels (calcul de la paie, restitutions, interfaces ...).

Chaque utilisateur Unix peut créer sa crontab (sauf si l'administrateur en a bloqué l'usage - cf fichiers cron.allow et cron.deny de /var/adm/cron).

Syntaxe de la commande

crontab [ -e [UserName] | -l [UserName] | -r [UserName] | -v [UserName] | File ]

A noter : seul l'administrateur peut  accéder à la crontab d'un autre utilisateur.

Dans la pratique :
  • On se connecte avec le compte de l'utilisateur concerné,
  • On liste le contenu de son fichier de paramètre crontab par la commande "crontab -l",
  • On édite pour modification sa crontab par la commande "crontab -e", on fait la saisie sous "vi" et on l'enregistre par le ":wq" habituel - sinon ":q!" pour ne pas sauvegarder,
  • La mise a jour est prise en compte quand on quitte l'éditeur
  • Le système va par défaut sauvegarder la crontab dans un fichier sous /var/spool/cron/crontabs.

Format du fichier paramètre

Le format du fichier "crontab" est indiqué ci dessous.
Vous pouvez placer en entête de votre crontab ce pense bête :


# *     *     *   *    *        command to be executed
#
# |     |     |   |    |
# |     |     |   |    +----- day of week (0 - 6, Sunday=0)
# |     |     |   +------- month (1 - 12)
# |     |     +--------- day of month (1 - 31)
# |     +----------- hour (0 - 23)
# +------------- min (0 - 59)
#

(une ligne blanche ou commençant par # est ignorée)

Ainsi,
"0          8   *       *   1-5   command" exécutera la commande à 8h00 tous les jours ouvrés ,
"0,15,30,45 *   *       *   *     command" exécutera la commande tous les quart d'heure,
"0          8   1,10-12 *   *     command" exécutera la commande à 8h00 les 1, 10, 11 et 12 du mois.

Les champs "day of month" et "day of week" - s'ils sont tous deux alimentés - sont cumulatifs,

A noter : une commande est exécutée par "cron"
  • A partir d'un sous shell ouvert dans le répertoire $HOME du compte,
  • Le .profile doit être exécuté si vous souhaitez bénéficier des variables d'environnement (sinon seules quelques variables dont  HOME, LOGNAME, SHELL (=/usr/bin/sh), et PATH sont disponibles).
  • Certains caractères spéciaux doivent être "déspécialisés" pour être correctement interprétés. Ainsi pour suffixer un log par une date on utilisera : `date +\%Y-\%m-\%d-\%H.\%M.\%S`

Exemple

Soumission d'une NOY par le script spécifique sub_noy à 5h20 tous les lundi matin :

20 5 * * 1 ( . ${HOME}/.profile; sub_noy -p YIYZE -f ${FILE}/PSBBCG.ZE ) >> /hradev/hraccess/txt/log/cron.log 2>&1

Sauvegarder le crontab

Vincent nous a un jour édité le crontab en utilisant l'option "-r" ("read" s'est-il dit). L'option en question a détruit la crontab ("-r" signifie "remove" !) ... Pour prévenir de ces incidents, je vous engage a automatiser une copie de sauvegarde du crontab.

Exemple :
# Sauvegarde hebdomadaire du crontab à 5h00 chaque dimanche
00 05 *  *  0  ( . ${HOME}/.profile; crontab -l >> ${SIGACS}/param/crontab.SauvegardeHebdomadaire 2>&1) >> /hradev/hraccess/txt/log/cron.log 2>&1
 

# Sauvegarde mensuelle du crontab à 5h00 chaque 1er du mois
00 05 1  *  *  ( . ${HOME}/.profile; crontab -l >> ${SIGACS}/param/crontab.SauvegardeMensuelle    2>&1) >> /hradev/hraccess/txt/log/cron.log 2>&1