Système de Gestion des Cartes : Différence entre versions

De Wiki_DR13
Aller à : navigation, rechercher
(Problème d'accès à HNO)
(Personne non trouvée dans unicampus)
 
(14 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 70 : Ligne 70 :
 
   table site de la base Campus, ex: site=1 pour le site RDM. Si la colonne uniteFixe n'est pas renseignée, mettre le codeUnite de l'unité.
 
   table site de la base Campus, ex: site=1 pour le site RDM. Si la colonne uniteFixe n'est pas renseignée, mettre le codeUnite de l'unité.
 
  * dans la table unite_fixes, changer le champ siteUnite par le sigle du site, ex: siteUnite=RDM .
 
  * dans la table unite_fixes, changer le champ siteUnite par le sigle du site, ex: siteUnite=RDM .
 +
 +
 +
=== Résolutions problèmes ===
 +
 +
==== Personne non trouvée dans unicampus  ====
 +
 +
Unicampus s'appuie sur les données de la table Personnel. Si la personne n'est pas trouvée dans unicampus, il faut d'abord vérifier qu'elle est bien dans la table Personnel du serveur secu-cab.
 +
* elle est présente, il faut alors vérifier la communication entre le serveur sécu et unicampus
 +
* elle n'est pas présente, il faut alors vérifier les données de Reseda sur le serveur newMysql de la délégation.
 +
 +
Sur la base de données Reseda :
 +
* vérifier les données de la personne et ses implantations. Si la personne a un statut CCD ou autre à durée déterminée, il faut que la date de fin soit renseignée, sinon l'info sera filtrée par les scripts et ne passera pas dans la table Personnel du serveur Secu-CAB.
 +
* Il arrive que pour certaines populations l’information passe mal entre Sirhus et reseda. IL faut alors aller voir le RH pour faire corriger la donnée.
 +
 +
==== Problème d'accès à HNO ====
 +
 +
Pour avoir accès à l'interface HNO sur DUO, il faut avoir une carteCMS valide.
 +
 +
Il se peut qu'une personne possède deux entrées dans la base de données Reseda dont une à une date de suppression logique (suite à du nettoyage DSI).
 +
 +
Cela se traduit par deux entrées dans la table Personnel sur le serveur Secu-CAB-DB. En général l'entrée qui renseigne le numéro de la carte correspond à l'idResedaPersonne de l'enregistrement possédant la date de suppression.
 +
 +
Avant d'engager toute modification, vérifier que la personne est toujours dans l'unité à laquelle correspond la carteCMS. Pour cela :
 +
 +
* Aller sur la base de données reseda sur NewMySql (si possible par un phpmyadmin).
 +
* Vérifier les deux entrées dans la table "personnes" (repérer l'idReseda valide et celui qui possède la date de suppression logique)
 +
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
 +
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
 +
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
 +
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
 +
* Sur l'enregistrement de la table "personnel" dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
 +
* Supprimer l’enregistrement doublon de la table "personnel" qui ne possède pas de carte.
 +
* Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche de la civilité du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.
  
 
=== Contacts ===
 
=== Contacts ===
 
  
  
Ligne 173 : Ligne 205 :
 
sur secu-CAB-DB (10.13.102.8) :  
 
sur secu-CAB-DB (10.13.102.8) :  
  
  00 6 * * 0-6 /etc/scripts/scriptResedaCarte.sh >> /etc/scripts/logCarte
+
  00 6 * * 0-6 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarte
  
  20 13 * * 1-5 /etc/scripts/scriptResedaCarte.sh >> /etc/scripts/logCarteMidi
+
  20 13 * * 1-5 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarteMidi
  
 +
  * le script appelle une commande symfony dont les sources sont dans le répertoire /opt/scripts/carteSecu (On met à jour le code grâce à un dépôt git venant de gitLab).
 +
  * la commande s'appelle cartecms:importReseda2Carte .
 +
  * Ce script permet de copier les infos utiles de la base de données Reseda qui se trouve sur le serveur 10.13.102.9 et va importer les données dans la table carteCMS.Personnel du serveur secu-CAB-DB.
  
le script se décompose en deux partie:
 
 
  importReseda2Carte.php
 
  Permet de copier les infos utiles de la base de données Reseda qui se trouve sur le serveur 10.13.102.9 et va importer les données dans la table carteCMS.Personnel du serveur secu-CAB-DB.
 
 
 
fonctionLadap2Carte.php
 
Permet de renseigner la fonction adminlabo depuis l'annuaire ldap vers la base carteCMS.Personnel
 
  
 
Le SGC utilise la base carteCMS comme sources de données
 
Le SGC utilise la base carteCMS comme sources de données
  
 
+
// a supprimer
 
Il existe aussi le script /etc/scripts/importReseda2Carte_manuel.php qui permet d'importer une catégorie de personnel. Il faut éditer le fichier et commenter et décommenter ce que l'on veut.
 
Il existe aussi le script /etc/scripts/importReseda2Carte_manuel.php qui permet d'importer une catégorie de personnel. Il faut éditer le fichier et commenter et décommenter ce que l'on veut.
  
==== Import application cartes ====  
+
==== Génération cartes pour gardien ====  
  
 
+
C'est l'application carte Multiservice de Duo qui va créer les enregistrements pour la base carteCMS
https://duo.dr13.cnrs.fr/cartecms/index
+
 
+
* https://duo.dr13.cnrs.fr/cartecms/index
 
+
*  -> menu administration -> générer...
L'application va aller enregistrer directement les infos dans la base carteCMS avec comme tag  
+
* cela permet de générer un lot de carte, il faut avoir des droits spécifiques pour accéder à ce menu, généralement réservé au SSI.
 +
* L'application va aller enregistrer directement les infos dans la base carteCMS avec comme tag  
 
  provenanceDonneesIndividuelles = LOCAL
 
  provenanceDonneesIndividuelles = LOCAL
  
Ligne 277 : Ligne 305 :
  
 
Pas encore en service !
 
Pas encore en service !
 
 
 
 
 
=== Résolutions problèmes ===
 
 
==== Problème d'accès à HNO ====
 
 
Pour avoir accès à l'interface HNO sur DUO, il faut avoir une carteCMS valide.
 
 
Il se peut qu'une personne possède deux entrées dans la base de données Reseda dont une à une date de suppression logique (suite à du nettoyage DSI).
 
 
Cela se traduit par deux entrées dans la table Personnel sur le serveur Secu-CAB-DB. En général l'entrée qui renseigne le numéro de la carte correspond à l'idResedaPersonne de l'enregistrement possédant la date de suppression.
 
 
Avant d'engager toute modification, vérifier que la personne est toujours dans l'unité à laquelle correspond la carteCMS. Pour cela :
 
 
* Aller sur la base de données reseda sur NewMySql (si possible par un phpmyadmin).
 
* Vérifier les deux entrées dans la table "personnes" (repérer l'idReseda valide et celui qui possède la date de suppression logique)
 
* Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
 
* Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
 
* Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
 
* S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
 
* Sur l'enregistrement dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
 
* Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet carte Personnels, cliquer sur la petite fiche à gauche du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.
 

Version actuelle datée du 5 mars 2024 à 16:14

Divers[modifier]

Administration local des cartes visiteurs[modifier]

https://duo.dr13.cnrs.fr/cartecms/index


Les PC d’édition doivent être sur le réseau src-cab-gestion


Nouvelle unité Reseda[modifier]

Lorsqu'une nouvelle unité Reseda est créée, le script quotidien Reseda va la créer dans la table reseda.unites, reseda.implantations_unites 
et la table unites_fixes. 
Il faut renseigner le champ site dans la table reseda.implantations_unites (mettre l'id du site qui se trouve dans la table campus.site), 
vérifier que le champ uniteFixe contient bien le même id que le champ idResedaUnite. 
Et dans la table reseda.unites_fixes mettre le codeSite de la table campus.site dans le champ siteUnite

Ajout unité spécifique[modifier]

Il se peut que le STL demande de rajouter un sigle unité, souvent parce qu'une nouvelle société doit entrer sur le campus. Et on veut leur donner un badge.
* Faire préciser pour quel campus si ce n'est pas fait.
* Aller sur la base de données reseda sur le serveur MySQL de la délégation, actuellement IP 10.13.102.9
* Sur la table unites_fixes, rechercher les unités dont l'idResedaUnite commence par 999999% 
  (on doit avoir la liste des unités fictives que l'on a créé pour la gestion des cartes)
* SELECT * FROM `unites_fixes` WHERE `idResedaUnite` LIKE '999999%'
* Rajouter l'unité en décrémentant de 1 l'idResedaUnite du plus petit. 
* Champ à renseigner : idResedaUnite, codeUnite (pas d'espace), intituleUnite, sigleUnite, siteUnite (ADV/RDM/BAILLARGUET)
  delegationRegionale_code = 13, date_insert = date du jour

Changement de code unité[modifier]

Lors d'une re-codification d'un code unité, on peut faire un traitement en masse pour que les cartes d'accès restent valides. Pour cela, il faut vérifier dans la base de données Reseda sur le serveur NewMysql que les champs sigleUnite et sigleUnite de la unites_fixes sont bien renseignés.

* lancer la commande requête sql sur le serveur sécurité (via phpmyadmin), là où se trouve la table personnel qui contient les cartes, cela mettra à jour les informations de la carte actives.
  UPDATE `personnel` p1
  JOIN `personnel` p2 ON p1.`idResedaPersonne`= p2.`idResedaPersonne`
  SET p1.`etatPersonnel`=p2.`etatPersonnel`, p1.`presenceUnite`= p2.`presenceUnite`, p1.`codeUnite`=p2.`codeUnite`, p1.`fonction_libelle`=p2.`fonction_libelle`, p1.`fonction_code`=p2.`fonction_code`, p1.`dateFinImplantation`=p2.`dateFinImplantation` 
  WHERE p1.`codeUnite`='UPS3035' AND p2.`codeUnite`='UAR3035' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL
 p1.`codeUnite`='AncienCode'
 p2.`codeUnite`='NouveauCode'
* Il faut ensuite supprimer les doublons par la requête : 
 DELETE t1 
 FROM `personnel` AS t1, `personnel` AS t2
 WHERE t1.id > t2.id
 AND t1.`idResedaPersonne` = t2.`idResedaPersonne`
 AND t1.`codeUnite` = t2.`codeUnite`
 AND t1.`codeUnite` = 'UAR3035'
 AND t1.`categorie_code` != 'CARTE_V'
 t1.`codeUnite`='NouveauCode'
 la requête supprime le doublon qui a l'id le plus élévé.
* Si l'unité a des cartes de catégorie CARTE_V, il faut lancer la requête suivante :
 UPDATE `personnel` SET `codeUnite`='UAR3725' WHERE `codeUnite`='UMS3725' AND `categorie_code`= 'CARTE_V'
 UAR3725 -> nouveau Code
 UMR3725 -> ancien code

Changement de site pour une unité[modifier]

Lorsqu'une unité change de site (typiquement unité Balard), il faut changer l'affectation de site dans la base de données Reseda (serveur Mysql)

* dans la table Reseda implantations_unites, changer le champ site par l'id du site qui se trouve dans la 
  table site de la base Campus, ex: site=1 pour le site RDM. Si la colonne uniteFixe n'est pas renseignée, mettre le codeUnite de l'unité.
* dans la table unite_fixes, changer le champ siteUnite par le sigle du site, ex: siteUnite=RDM .


Résolutions problèmes[modifier]

Personne non trouvée dans unicampus[modifier]

Unicampus s'appuie sur les données de la table Personnel. Si la personne n'est pas trouvée dans unicampus, il faut d'abord vérifier qu'elle est bien dans la table Personnel du serveur secu-cab.

* elle est présente, il faut alors vérifier la communication entre le serveur sécu et unicampus
* elle n'est pas présente, il faut alors vérifier les données de Reseda sur le serveur newMysql de la délégation.

Sur la base de données Reseda :

* vérifier les données de la personne et ses implantations. Si la personne a un statut CCD ou autre à durée déterminée, il faut que la date de fin soit renseignée, sinon l'info sera filtrée par les scripts et ne passera pas dans la table Personnel du serveur Secu-CAB. 
* Il arrive que pour certaines populations l’information passe mal entre Sirhus et reseda. IL faut alors aller voir le RH pour faire corriger la donnée.

Problème d'accès à HNO[modifier]

Pour avoir accès à l'interface HNO sur DUO, il faut avoir une carteCMS valide.

Il se peut qu'une personne possède deux entrées dans la base de données Reseda dont une à une date de suppression logique (suite à du nettoyage DSI).

Cela se traduit par deux entrées dans la table Personnel sur le serveur Secu-CAB-DB. En général l'entrée qui renseigne le numéro de la carte correspond à l'idResedaPersonne de l'enregistrement possédant la date de suppression.

Avant d'engager toute modification, vérifier que la personne est toujours dans l'unité à laquelle correspond la carteCMS. Pour cela :

  • Aller sur la base de données reseda sur NewMySql (si possible par un phpmyadmin).
  • Vérifier les deux entrées dans la table "personnes" (repérer l'idReseda valide et celui qui possède la date de suppression logique)
  • Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
  • Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
  • Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
  • S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
  • Sur l'enregistrement de la table "personnel" dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
  • Supprimer l’enregistrement doublon de la table "personnel" qui ne possède pas de carte.
  • Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche de la civilité du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.

Contacts[modifier]

HOTLINE : 02.47.92.90.32

et demander l’ouverture d’un incident « Monécarte ».


Gestionnaire de tickets :

[1]

Log : 34032
Mot de passe : XY1JO3


Technicien SAV, passer par les tickets, uniquement en cas de problèmes :

Clément Wigy
Technicien Support 
4 avenue Jean Monnet - 37160 Descartes
Tel: +33 (0)2 47 92 90 32 
 
clement.wigy@capmonetique.com - www.capmonetique.com


Installateur : CAP MONETIQUE

Technicien : 
Sébastien Arnault
Chargé de projet
4 avenue Jean Monnet - 37160 Descartes
Tel: +33 (0)2 47 91 85 87 - Mob : +33 6 (0)11 29 97 68
sebastien.arnault@capmonetique.com - www.capmonetique.com


Commercial :
Sylvain Févrilliez
Responsable secteur Grand Est – Enseignement Supérieur
4 avenue Jean Monnet - 37160 Descartes
Tel: (+33) 2 47 91 47 50 - Mob : (+33) 6 99 06 48 43
sylvain.fevrilliez@capmonetique.com - www.capmonetique.com

Consommables :

A utiliser de préférence :

Sylvie Méreau <sylvie.mereau@capmonetique.com>

Ruban Primacy YMCKO, 5 panneaux. Kit de nettoyage Primacy


Urgence rubans livré le lendemain mais il vaut mieux passer par monecarte si pas urgent :

http://www.cardalis.fr/evolis-primacy-simplex-et-primacy-duplex/1561-ruban-evolis-primacy-couleur-ymcko-300-cartes.html 


Protèges cartes :

http://www.cardalis.fr/porte-badges-souples/1444-porte-badge-souple-transparent-bandeau-transp-double-perforation.html


CROUS :

Emmanuelle Ricard
Chargée de mission inter-universitaire-Crous 
Carte étudiant électronique Languedoc-Roussillon
Crous de Montpellier
2 rue Monteil CS 85053 34 093 Montpellier cedex 5
04 67 41 50 66 / 06 78 44 19 05

CNOUS (gestion des numéros IZLY):

Sylvain Cammas
Responsable du département Monétique
Cnous
15, rue Guillaume VII le Troubadour – 86022 Poitiers
05 49 60 88 05 / 06 80 90 62 32

IZLY[modifier]

  • Nous gérons la numérotation nationale des numéros de carte IZLY : voir SSI/CMS/CNOUS
  • Nous avons 3 SAM CNOUS
  • Le fichier de lecture de la SAM est aussi dans SSI/CMS/CNOUS


Nous ne faisons qu’envoyer les nom prénom et numéro de carte au CNOUS, les indices sont ensuite synchronisés par le SSI de la DR11.

En cas de soucis, voir dans cet ordre :

  1. Monecarte
  2. DR11
  3. CNOUS


Connecteurs[modifier]

Import RESEDA vers base carteCMS[modifier]

sur secu-CAB-DB (10.13.102.8) :

00 6 * * 0-6 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarte
20 13 * * 1-5 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarteMidi
 * le script appelle une commande symfony dont les sources sont dans le répertoire /opt/scripts/carteSecu (On met à jour le code grâce à un dépôt git venant de gitLab).
 * la commande s'appelle cartecms:importReseda2Carte .
 * Ce script permet de copier les infos utiles de la base de données Reseda qui se trouve sur le serveur 10.13.102.9 et va importer les données dans la table carteCMS.Personnel du serveur secu-CAB-DB.


Le SGC utilise la base carteCMS comme sources de données

// a supprimer Il existe aussi le script /etc/scripts/importReseda2Carte_manuel.php qui permet d'importer une catégorie de personnel. Il faut éditer le fichier et commenter et décommenter ce que l'on veut.

Génération cartes pour gardien[modifier]

C'est l'application carte Multiservice de Duo qui va créer les enregistrements pour la base carteCMS

* https://duo.dr13.cnrs.fr/cartecms/index
*  -> menu administration -> générer...
* cela permet de générer un lot de carte, il faut avoir des droits spécifiques pour accéder à ce menu, généralement réservé au SSI.
* L'application va aller enregistrer directement les infos dans la base carteCMS avec comme tag 
provenanceDonneesIndividuelles = LOCAL

Export vers le contrôle d'accès[modifier]

Il y à 3 connecteurs d'exports vers le controle d'accès :

C:\Program Files (x86)\Monecarte\ConnecteurAEOSP\AEOSProcess.exe

Connecteur d'export des personnels (permanents / non premanents / retraités)

Il est lancé automatiquement toutes les 30 minutes


C:\Program Files (x86)\Monecarte\ConnecteurAEOSV\AEOSProcess.exe

Connecteur d'export des visiteurs

Il est lancé automatiquement toutes les 30 minutes


C:\Program Files (x86)\Monecarte\ConnecteurAEOS_Cartes_Visteurs\AEOSProcess.exe

Connecteur d'export des carte visiteurs sans nom.

Il faut le lancer manuellement.


Les logs des connecteurs sont dans E:\Logs


Pour les 3 connecteurs, ils vont aller vérifier sir il faut exporter les carte dans la table AEOS. Si le flag export est a 0, le script va pousser la carte et rebasculer le flag à 1.

Les connecteurs insèrent ensuite les données sur le serveur AEOS dans la table import. Il faut vérifier le champ status en cas de soucis, il doit être à OK. SI pas OK, voir le champ errorcode. Attention, il n'y a pas de contrôle automatique !


Erreurs connues :

  • -1 : ne doit plus se produire, erreur de longueur de champ dans la base ou problème d'ecriture. Voir le champs status pour plus de détail (c'est assez explicite)
  • 33 : mise en opposition d'une carte pas encore insérée dans le système : RAS ne pas en tenir compte


Export vers la base de données carteCMS[modifier]

C:\Program Files (x86)\Monecarte\ConnecteurDatabaseProcess\DatabaseProcess.exe

Lancé automatiquement 2 fois par jour.

Permet de récupérer les infos de numéro Nedap + numéro de carte + Id de la base CMS et de les ajouter a notre base de données (10.13.102.8)


Mise à jour depuis la base carteCMS[modifier]

C:\Program Files (x86)\Monecarte\SynchroPersonProcess\SynchroPersonProcess.exe

Lancé automatiquement 2 fois par jours

Le script va aller verifier si la base carteCMS a été mise a jour. En cas de MAJ, elles sont répercutées vers le SGC puis vers AEOS avec les scripts précédents.

Les carte visiteurs et les retraités ne sont pas mis a jour car nous n'avons pas d'infos sur leur départ.


Export CNOUS[modifier]

C:\Program Files (x86)\Monecarte\Connecteur CNOUS\CnousProcess.exe


Pas encore en service !


Opposition CNOUS[modifier]

C:\Program Files (x86)\Monecarte\CnousOppositionProcess\CnousOppositionProcess.exe

Pas encore en service !