30 juillet 2014

Livrer le nombre d'occurrences des Host tables d'une information (radicaux des tables en plate forme physique)

 Depuis HRv9, l'objet plate forme physique permet de spécifier le nombre d'occurrences des HOST-TABLES de chargement de ZX (cf "chargement-du-prdb-par-host-tables") :



On peut en retrouver les valeurs en base dans la table PP30 :

SQL> select * from PP30 where NBOCCR > 0 and CDPLPH in (select CDPLPH from PP10 where CDCPOM = '1');

CDPLPH   CD CD RDTABL   PR SU PR SU PR SU PR SU TIMODI                  NBOCCR
-------- -- -- -------- -- -- -- -- -- -- -- -- ------------------- ----------
PPCLIUNO ZX                                     2013-04-22-18.20.34        150
PPCLIUNO ZX 5C                                  2013-04-22-18.20.54       3500
PPCLIUNO ZX 8K                                  2013-08-21-15.15.37        999


Lors des générations, cette valeur impacte la macro BGVHV2. Ci dessous un extrait du programme BEB :
000875 01 HTB-CLZX5C PIC S9(4) COMP.                                    BGVHV2
000876 01 HTB-CLZX5C-MAX VALUE 3500  PIC S9(4) COMP.                    BGVHV2
000877 01 HTB-ZX5C.                                                     BGVHV2
000878  02 HTB-ZX5C-NUDOSS OCCURS  3500 PIC S9(9) COMP.                 BGVHV2

...

Pour livrer ces valeurs, il faut exporter l'objet information concerné. Ci dessous un extrait du fichier d'export de l'information ZX5C : 
grep PP30 PSBBC101
0017INZX5C    PP307.0000000PPCLIUNOZX5C                        2013-04-22-18.20.543500  *



Si vous constatez que le nombre d'occurrences est absent du fichier, demandez un correctif à l'éditeur.

24 juillet 2014

SQLPlus : influence du parametre cursor_sharing sur l'affichage des champs caractères

Vu sous Oracle 11.2.0.3  :
La longueur des champs caractères affichée sous SQLPlus peut varier en fonction du paramètre de session cursor_sharing :
  • cursor_sharing = exact
  • cursor_sharing = force

SQL> alter session set cursor_sharing = exact ;
Session altered.

SQL> select 'constant1', 'constant2' from dual ;
'CONSTANT 'CONSTANT
--------- ---------
constant1 constant2


SQL> alter session set cursor_sharing = force ;
Session altered.
SQL> select 'constant1', 'constant2' from dual;
 
'CONSTANT1'                      'CONSTANT2'
-------------------------------- --------------------------------
constant1                        constant2

SQL> show parameter cursor_sharing
NAME           TYPE   VALUE
-------------- ------ --------
cursor_sharing string force

 

Merci Didier pour cette analyse.

22 juillet 2014

BU2-BBAD0015-ERREUR D'ACCES (TABLE RELATIONNELLE) : EN10/INSERT/9I/9Z/000000000020101

Ce message d'erreur peut apparaître lors d'un chargement d'objets par la chaine RB4 quand le groupe d'appartenance de l'objet est absent.

Pour la plupart des objets, les données de description sont stockées dans une arborescence de tables. Par exemple les objets "Groupes de Traitements" sont stockés en table TR10, les "Traitements" en table TR20, etc... Et il existe des contraintes de "Clef étrangère" entre ces tables.

Ainsi, si l'on cherche à charger un Traitement dont le groupe n'existe pas, on obtiendra une erreur SQL du type "Parent Key not found".

Pour certains objets, la description des données est stockée dans des tables "banalisées" (GO**, EN**, LB**, RC**, FQ** ...). Les relations entre tables sont alors gérées par des triggers. Le code retour SQL Oracle 20101 correspond à une erreur émise par le Trigger.

Par exemple en fin de prod/ddl/TZ7.sql on trouve :

...
    IF P_RECONNU = 0 THEN
      RAISE_APPLICATION_ERROR(-20102,'UNKNOWN HR ENTITY TYPE');
    END IF;
    IF P_COMPTEUR = 0 THEN
      RAISE_APPLICATION_ERROR(-20101,'HR INTEGRITY ERROR');
    END IF;



Pour débloquer l'import, déterminer l'objet posant problème et importez (sinon créez manuellement) l'objet groupe manquant.

Si l'objet groupe fait partie de l'export, cela signifie que les objets n'ont pas été exportés dans le bon ordre. Demandez un patch à l'éditeur.

19 juin 2014

Utiliser une clef SSH pour se connecter avec Putty, Filezilla

L'utilisation des clefs SSH permettent de remplacer l'authentification par mot de passe demandée par le serveur Unix/Linux. Pour ceci chacun doit se créer sa propre clef, puis le gestionnaire du compte Unix/Linux doit la référencer dans la liste des clefs autorisés.

A noter :
  • En fait chacun se crée un "couple" de clefs :
    • Une est dite "privée". Elle ne doit rester strictement la propriété de son créateur. Elle sert notamment à chiffrer les communications,
    • La seconde est dite "publique". Son propriétaire la transmet à ses "interlocuteurs". Elle sert à authentifier le propriétaire des clefs et à déchiffrer ses communications.
  • Ce système peut aussi servir entre deux applications,
  • Le bon fonctionnement de l'authentification par clef dépend de son paramétrage par l’administrateur Unix/Linux (/etc/ssh, droits d'accès)

Création des clef

  • Télécharger PuttyGen.exe
  • Exécuter PuttyGen
  • Choisir (par exemple) un type de clef RSA et une longueur de clef de 2048 bits :

  • Cliquer sur "Generate" et déplacer la souris pour générer une clef aléatoire,

  • Une fois la clef calculée, indiquez en commentaire vos nom et prénoms. Pour des raisons de sécurité (vol de votre clef privée), il est conseillé de paramétrer un mot de passe pour pouvoir utiliser la clef. Ceci est facultatif.

  • Sauvegardez les clefs, par exemple sous le nom :
    • Prénom_NOM.pub pour la clef publique
    • Prénom_NOM.ppk pour la clef privée

A noter : sur une machine Unix ou Linux la création de la clef peut être réalisée en mode commande.
Par exemple : ssh-keygen -t rsa -b 2048 -C "Nom Prenom" -f Prenom_NOM

Paramétrage sur le serveur

  • Transmettre la clef publique à l’administrateur pour qu’il la place dans le fichier « $HOME/.ssh/authorize_keys » du compte ciblé
 A noter : les droits Unix/Linux sur le répertoire ".ssh" et le fichier "authorized_keys" doivent être restrictifs sans quoi les autorisations ne seront pas prises en compte.

Paramétrage sur le micro

  • Pour Putty indiquez l’emplacement de la clef privée dans Connection / SSH / Auth « Private key file for authentication »



  • Pour Filezilla indiquez l’emplacement de la clef privée dans Edition / Paramètres / Connexion / SFTP « Ajouter une clef privée »

Test de connexion


login as: hradev
 

Authenticating with public key "Digix"
Passphrase for key "Digix":
-------------------------Avis aux utilisateurs----------------------------------
Tout acces non autorise sur ce systeme est passible de poursuites.
--------------------------------------------------------------------------------
hr9dev@srvlnx001:/home/hradev>

12 juin 2014

Créer un "DIRECTORY" Oracle en référençant le code instance

Ci dessous un script SQL qui crée dans la base Oracle un "DIRECTORY" nommé HR_FILE pour les outils d'export import "Data Pump".

La plupart du temps le chemin contient le nom de l'instance, ce qui nécessite de variabiliser l'ordre de création.

Ici Gabriel récupère ce nom dans une variable "SID" qu'il réutilise lors du "CREATE" :

COLUMN INSTANCE NEW_VALUE SID NOPRINT
SELECT SYS_CONTEXT('USERENV','DB_NAME') AS INSTANCE
FROM DUAL
/
CREATE DIRECTORY HR_FILE AS '/oracle/&SID./exports'
/



11 juin 2014

Un effet de bord de la "Timezone" Linux sur les dates saisies dans HRCT


Sur certains environnements les utilisateurs nous ont signalés que les dates saisies via interface web de HRCT sont altérées (stockées en base à J – 1 : par exemple un utilisateur qui saisit 01/03/2014 retrouvera en base 28/02/2014). Hors pour d'autres environnements hébergés sur d’autres serveurs, la saisie est correcte.

Après contact avec l’éditeur, celui-ci nous suggère de contrôler les TimeZone des machines incriminées.

Si la commande « date +%Z » affichait le même résultat, les commandes suivantes indiquaient effectivement des différences :
  • Sur une machine correcte :
hr-configuration-tool-web-smartgwt.log: user.timezone=Europe/Paris

ls -l /etc/localtime
-rw-r--r-- 1 root root 2945 29 oct. 2013 /etc/localtime

  • Sur une machine incorrecte :
hr-configuration-tool-web-smartgwt.log: user.timezone=GMT
 

ls -l /etc/localtime
-r--r--r-- 1 root root 5890 6 sept. 2013 /etc/localtime


Après correction du /etc/localtime par l'administrateur Unix, le comportement de HRCT est redevenu normal.

PS : La date HRCT passait à J-1 car  01/03/2014 moins une heure donne 28/02/2014:23:00 - puis l'heure est tronquée.


Autre option, à tester : ajouter l'option "-Duser.timezone=Europe/Paris" à la ligne de commande Java de Tomcat.