You are not logged in.
Bonjour,
La réponse existe dans le forum puisque jm.cierniewski le dit lui même (http://glpi-project.org/forum/viewtopic.php?id=2575) mais ça fait deux heures que je triture la fonction recherche dans tous les sens, j'ai appris pas mal de trucs intéressants mais je ne trouve pas la réponse à ma question... Je commence à désespérer de déterrer ce post. Quelqu'un pourrait-il me guider jusqu'à ce graal qu'est la solution pour pouvoir importer/synchroniser plusieurs GLPI sur un seul OCS? Ce serait super cool, merci.
D'ailleurs, ne serait-il pas possible que l'information d'état (synchronisé, à synchroniser, "nouveau") OCS soit contenu dans une relation de la base de GLPI et pas dans OCS? C'est peut-être compliqué, voire impossible, mais j'avais pensé naïvement (je suis géologue, pas informaticien, mes compétences sont plus que limitées sur le sujet...) qu'il serait préférable de ne pas agir sur la base de données d'une autre application?
a+
Oliver
P.S. merci pour GLPI et tout le travail que représente ce projet, merci, merci, merci!
Oliver - GLPIen curieux, voire même étrange
Dev : GLPI 0.84.5, Debian jessie/sid.
Prod : GLPI 0.83.8, CentOS 6.5
Offline
Ah, je crois avoir trouvé : http://glpi-project.org/forum/viewtopic.php?id=3432 (je savais qu'il fallait que je pose la question pour trouver la réponse tout de suite derrière... )
Le souci, c'est que je n'ai pas accès à un outil d'admin sql sur le serveur OCS (je n'ai pas de compte sur la machine et il n'y a pas de phpmyadmin ou autre interface web).
Dommage, je vais peut-être devoir me restreindre à un seul GLPI
Par contre, ma deuxième question reste entière. Si quelqu'un peut m'expliquer pourquoi ça fonctionne comme ça et si ça peut se changer, je serai reconnaissant
a+
Oliver - GLPIen curieux, voire même étrange
Dev : GLPI 0.84.5, Debian jessie/sid.
Prod : GLPI 0.83.8, CentOS 6.5
Offline
Oui tu as raison, sauf que :
Si la table de liaison était côté GLPI, OCS serait obligé d'écrire dedans. Donc le problème resterait entier.
++
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Ah d'accord. Effectivement, vu comme ça, c'est évident Merci.
Question subsidiaire : pourquoi OCS devrait-il écrire dans les tables de GLPI?
Pour la synchronisation, ne pourrait-on pas avoir une table côté GLPI qui contienne la date d'inventaire d'OCS? (ou même utiliser le champ déjà présent dans GLPI en mode OCSNG). Une simple comparaison entre les attributs de cette table de GLPI et la table de date d'inventaire dans OCS devrait permettre de déterminer si il faut mettre à jour ou non; ou alors je raconte de grosses âneries mais ça, ce ne serait guerre surprenant.
a+
Oliver - GLPIen curieux, voire même étrange
Dev : GLPI 0.84.5, Debian jessie/sid.
Prod : GLPI 0.83.8, CentOS 6.5
Offline
Parce que l'information principale utilisée pour la synchro, c'est le CHECKSUM qui indique quelles parties de l'inventaire on changées.
OCS le positionne pour indiquer un changement
GLPI traite les parties modifiées
GLPI remet à zéro pour ne pas traiter 2 fois les mêmes parties.
Sans cette "optimisation", la synchronisation serait beaucoup plus longue.
++
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
D'accord. Je comprends mieux.
Merci beaucoup pour ces explications
a+
Oliver - GLPIen curieux, voire même étrange
Dev : GLPI 0.84.5, Debian jessie/sid.
Prod : GLPI 0.83.8, CentOS 6.5
Offline