Anomalie #14341
fermé[IxBus] Améliorer les logs techniques
Description
Le circuit de test est le suivant :
- dans MaarchCourrier :
j’accède au courrier que je veux envoyer.
Je choisi l'action envoyer au parapheur.
Je valide
Le document passe en "pièce jointe gelée".
-Dans IxBus :
Je reçois le document en tant que signataire.
Je le signe.
le script retrieveMailFromExternalSignatoryBook.sh qui exploite le fichier de config suivant remoteSignatoryBooks.xml est exécuté toutes les minutes.
Nous remarquons que les documents ne reviennent pas dans MaarchCourrier mais que les documents envoyés passe en "pièce jointe traitée".
Nous lançons le script manuellement, aucune trace.
Le fichier de log :
[2020-07-03 17:04:43] INFO 0 'Load xml config file:/var/www/html/MaarchCourrier/custom/cs_maarch_smo/modules/visa/batch/config/config.xml'
[2020-07-03 17:04:43] INFO 0 'Retrieve attachments sent to remote signatory book'
[2020-07-03 17:04:43] INFO 0 'Retrieve signed/annotated documents from remote signatory book'
[2020-07-03 17:04:44] INFO 0 'Retrieve mails sent to remote signatory book'
[2020-07-03 17:04:44] INFO 0 'Update res_attachment outgoing : 286. ExternalSignatoryBookId : 16651748'
[2020-07-03 17:04:44] INFO 0 'End of process'
[2020-07-03 17:04:44] INFO 0 '1 document(s) retrieved'
Pas de pièce jointe ajouté...
Fichiers
Mis à jour par Support Maarch il y a plus de 4 ans
- Statut changé de A qualifier à A traiter
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de A traiter à Etude planifiée
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de Etude planifiée à 17
- Assigné à changé de EDI PO à Ludovic ARAUJO
Sur le ticket ci-dessous, est-il possible d'avoir la version iXbus utilisée ?
Cela a-t-il déjà fonctionné où est-ce la première mise en service ?
Quel est le version tag de Maarch Courrier ?
Ces éléments permettront une prise en charge rapide de la demande.
Ce phénomène est souvent lié au paramétrage du XML.
Maarch Courrier est compatible avec la version Ixbus : API SOAP V3
https://docs.maarch.org/gitbook/html/MaarchCourrier/19.04/guat/guat_exploitation/retrieveFromExternalSignatoryBook.html
vérifier la balise applicationUrl dans la configuration du script
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- iXBusWeb (4.0.21.0)
- jamais mis ailleurs
- dernier tag à cette date
quelle balise faut il vérifier?
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- Statut changé de 17 à A traiter
- Assigné à changé de Ludovic ARAUJO à EDI PO
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de A traiter à Complément d'Informations
- Assigné à changé de EDI PO à Henri QUENEAU
Balise à vérifier :
vérifier la balise : <applicationUrl>http://localhost/maarch_v2/</applicationUrl>
Il semble que la version iXbus du client ne soit pas compatible avec les pré-requis Courrier (SOAP V3).
Il n'a jamais été mis en service chez le client ?
Vérifications à faire sur la balise (URL correct) avant d'envisager la suite. (portage v4 ixBus...)
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- Statut changé de Complément d'Informations à A traiter
- Assigné à changé de Henri QUENEAU à EDI PO
Pour information les documents partent bien dans ixbus mais ne reviennent pas dans maarch...
Lorsqu'on lance le script , les statuts des pièces jointes sont bien changés mais le pdf signé ne s'injecte pas dans maarch.
[2020-07-03 17:04:44] INFO 0 'Update res_attachment outgoing : 286. ExternalSignatoryBookId : 16651748'
Ceci montre bien que l'URL est la bonne.
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de A traiter à Etude planifiée
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Sujet changé de [IxBus] Les documents Ixbus ne remonte pas dans maarch à [IxBus] Les documents transmis ne sont pas réinjectés
Mis à jour par Florian AZIZIAN il y a plus de 4 ans
Non, ce message ne signifie pas que l'url est bonne.
Ce message indique seulement dans quelle partie on est.
De plus, ce message est affiché avant de faire l'envoi de la pj.
Et sachant que l'envoi de la pj se fait en REST dans une fonction à part, il est possible que l'envoi ne fonctionne pas sans faire planter le script.
C'est pour cela qu'il faut vérifier le paramétrage indiqué dans le message précédent.
Il faut bien mettre l'url complète comme si vous vous connectez à l'application. Par exemple : http://localhost/maarch_v2/cs_moncustom
Vous pouvez aussi voir les logs Apache, il y a peut être des informations
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de Etude planifiée à 17
- Assigné à changé de EDI PO à Henri QUENEAU
Mis à jour par Henri QUENEAU il y a plus de 4 ans
root@DINIZ:/var/www/html/MaarchCourrier/custom/cs_maarch_smo/modules/visa/batch/config# cat config.xml
<?xml version="1.0" encoding="utf-8"?>
<ROOT>
<CONFIG>
<MaarchDirectory>/var/www/html/MaarchCourrier/</MaarchDirectory>
<CustomId>cs_maarch_smo</CustomId>
<validatedStatus>EENV</validatedStatus>
<validatedStatusOnlyVisa>EENV</validatedStatusOnlyVisa>
<refusedStatus>REJ_SIGN</refusedStatus>
<validatedStatusAnnot>COU</validatedStatusAnnot>
<refusedStatusAnnot>RET</refusedStatusAnnot>
<applicationUrl>http://10.1.22.78/MaarchCourrier/cs_maarch_smo/</applicationUrl>
<userWS>superadmin</userWS>
<passwordWS>superadmin</passwordWS>
</CONFIG>
<LOG4PHP>
<enabled>true</enabled>
<Log4PhpLogger>loggerTechnique</Log4PhpLogger>
<Log4PhpBusinessCode>retrieveMailsFromSignatoryBook</Log4PhpBusinessCode>
<Log4PhpConfigPath>/var/www/html/MaarchCourrier/custom/cs_maarch_smo/apps/maarch_entreprise/xml/log4php.xml</Log4PhpConfigPath>
</LOG4PHP>
</ROOT>
root@DINIZ:/var/www/html/MaarchCourrier/custom/cs_maarch_smo/modules/visa/batch/config#
Mis à jour par Henri QUENEAU il y a plus de 4 ans
root@DINIZ:/var/www/html/MaarchCourrier/custom/cs_maarch_smo/modules/visa/batch/config# /usr/sbin/ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.1.22.78 netmask 255.255.255.0 broadcast 10.1.22.255
inet6 fe80::250:56ff:feac:7d2c prefixlen 64 scopeid 0x20<link>
ether 00:50:56:ac:7d:2c txqueuelen 1000 (Ethernet)
RX packets 73444926 bytes 21382401381 (19.9 GiB)
RX errors 0 dropped 22883 overruns 0 frame 0
TX packets 37670060 bytes 8634743298 (8.0 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19 memory 0xfd4a0000-fd4c0000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Boucle locale)
RX packets 23276065 bytes 7627531934 (7.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 23276065 bytes 7627531934 (7.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- Statut changé de 17 à A traiter
- Assigné à changé de Henri QUENEAU à EDI PO
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- Fichier Screenshot from 2020-07-17 17-03-07.png Screenshot from 2020-07-17 17-03-07.png ajouté
- Fichier Screenshot from 2020-07-17 17-07-48.png Screenshot from 2020-07-17 17-07-48.png ajouté
nouveau test fait
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de A traiter à Etude planifiée
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Assigné à changé de EDI PO à Maarch Courrier DEV TEAM
Mis à jour par Florian AZIZIAN il y a plus de 4 ans
- Statut changé de Etude planifiée à 17
- Assigné à changé de Maarch Courrier DEV TEAM à Henri QUENEAU
- Y-a-t-il la connexion ldap activée ?
- Peux-tu essayer avec un compte de webservice au lieu de superadmin ? (Ce compte de webservice doit appartenir à un groupe dont la clause est 1=1, sinon le document sera hors périmètre)
- Y-a-t-il des infos dans les logs générés par log4php ? Par défaut, c'est dans le fichier fonctionnel.log et/ou technique.log à la racine de l'application. (Cela dépend de la config dans log4php.xml)
- Y-a-t-il des messages lorsque tu lances le script à la main ?
- si les 4 points précédents ne donnent rien, tu peux mettre un var_dump($rawResponse);var_dump($error); à la ligne 198 du fichier modules/visa/batch/batch_tools.php
Mis à jour par Henri QUENEAU il y a plus de 4 ans
Florian AZIZIAN a écrit :
- Y-a-t-il la connexion ldap activée ?
Non- Peux-tu essayer avec un compte de webservice au lieu de superadmin ? (Ce compte de webservice doit appartenir à un groupe dont la clause est 1=1, sinon le document sera hors périmètre)
Déjà fait- Y-a-t-il des infos dans les logs générés par log4php ? Par défaut, c'est dans le fichier fonctionnel.log et/ou technique.log à la racine de l'application. (Cela dépend de la config dans log4php.xml)
non- Y-a-t-il des messages lorsque tu lances le script à la main ?
non- si les 4 points précédents ne donnent rien, tu peux mettre un var_dump($rawResponse);var_dump($error); à la ligne 198 du fichier modules/visa/batch/batch_tools.php
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- Statut changé de 17 à A traiter
- Assigné à changé de Henri QUENEAU à EDI PO
- Priorité changé de 0-Bloquant à 2-Sérieux
Je viens de faire une montée de version en 20.03.
Lorsque je passe le script, les logs sont beaucoup plus parlant et m'ont permis de résoudre le problème.
Le problème était que le chemin du docservers était mal renseigné pour les documents signés.
Ceci est vraiment génant lorsqu'on est en 19.04 car on a aucune log permettant de comprendre pq ça ne marche pas.
Il faudrait ajuster l'application afin que les logs soient plus parlant
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de A traiter à Etude planifiée
Mis à jour par Emmanuel DILLARD il y a environ 4 ans
- Sujet changé de [IxBus] Les documents transmis ne sont pas réinjectés à [IxBus] Améliorer les logs techniques
- Statut changé de Etude planifiée à R&D - A planifier
Mis à jour par Emmanuel DILLARD il y a environ 4 ans
- Statut changé de R&D - A planifier à Rejeté
- Assigné à changé de EDI PO à Ludovic ARAUJO
Logs améliorés en 20.03 et 20.10
Mis à jour par Emmanuel DILLARD il y a plus de 3 ans
- Projet changé de 298 à Backlog Courrier
- Version cible changé de 19.04 (Fin de vie) à 19.04 (Sécurité)