sM-Client Projekt

sM-Client Projekt
Projet sM-Client
Manuel d’exploitation
Version finale
CSI / OFAS eAVS/AI
Version:
5.0.8
Publication Date:
24 octobre 2014
sM-Client Projekt
Version finale
Manuel d‘exploitation
COPYRIGHT
© Copyright - 2014 Cambridge Technology Partners. All Rights Reserved.
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system or translated
into any language in any form by any means without the written permission of Cambridge Technology Partners
SA.
While every precaution has been taken in the preparation of this document, Cambridge Technology Partners
assumes no responsibility for errors, omissions, or for damages resulting from the use of the information herein.
Products or corporate names may be trademarks or registered trademarks of other companies and are used
only for the explanation and to the owner's benefit, without intent to infringe.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
2 / 39
Projet sM-Client
Version finale
Manuel d’exploitation
SOMMAIRE
1
OBJET DU DOCUMENT .............................................................................................. 8
2
APERÇU GENERAL .................................................................................................... 9
2.1
2.4
2.5
ARCHITECTURE DU SYSTEME ET INTERFACES ................................................................................................. 9
2.1.1
Architecture du système ............................................................................................................ 9
2.1.2
Interfaces ................................................................................................................................. 10
INSTALLATION ET CONFIGURATION REQUISE – SERVEUR ............................................................................... 14
2.2.1
Recommandation concernant la configuration mémoire ......................................................... 15
TUNING...................................................................................................................................................... 16
2.3.1
Polling Intervall ......................................................................................................................... 16
2.3.2
sM-Client Queue ...................................................................................................................... 16
2.3.3
Stuck Message Detector .......................................................................................................... 17
INSTALLATION ET CONFIGURATION REQUISE – CLIENT .................................................................................. 17
APERÇU DES ENVIRONNEMENTS DEVELOPPEMENT, TEST ET PRODUCTION INSTALLES ..................................... 17
3
EXPLOITATION ......................................................................................................... 18
3.1
3.2
3.7
3.8
DEMARRAGE ET ARRET DE L’EXPLOITATION .................................................................................................. 18
EXECUTION ET SURVEILLANCE DE L’EXPLOITATION (MONITORING) ................................................................. 18
3.2.1
Monitoring centralisé ................................................................................................................ 19
3.2.2
Server Monitoring ..................................................................................................................... 19
3.2.3
Vérification du traitement correct des messages ..................................................................... 19
3.2.4
Backup et Recovery ................................................................................................................. 20
3.2.5
Détenteurs, responsables et contacts ..................................................................................... 22
3.2.6
Heures de service .................................................................................................................... 22
INDICATEURS DE PERFORMANCE (KPI) ........................................................................................................ 22
RESTRICTIONS CONNUES ............................................................................................................................ 23
ARCHIVAGE ET SUPPRESSION DE DONNEES ................................................................................................. 23
NOUVELLES VERSIONS ET MISES A JOUR ...................................................................................................... 23
3.6.1
Nouvelles versions de client sM............................................................................................... 23
3.6.2
Mise à jour du repository .......................................................................................................... 24
3.6.3
Mise à jour des plug-ins ........................................................................................................... 24
PLUSIEURS CLIENTS SM OU COMMUNICATIONS SUR UN ADAPTATEUR SEDEX.................................................. 24
PLUG-INS ................................................................................................................................................... 27
4
CONSIGNES DE SECURITE ..................................................................................... 28
5
TESTBED ................................................................................................................... 29
5.1
TESTER AVEC TESTBED .............................................................................................................................. 29
5.1.1
Simuler l’expéditeur pour tester la réception ........................................................................... 29
5.1.2
Simuler le destinataire pour tester l’envoi ................................................................................ 30
6
ANNEXE ..................................................................................................................... 31
6.1
LISTE DES MESSAGES LOG.......................................................................................................................... 31
2.2
2.3
3.3
3.4
3.5
3.6
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
3 / 39
Projet sM-Client
Version finale
Manuel d’exploitation
6.2
6.3
6.1.1
Message Handler ..................................................................................................................... 31
6.1.2
Case postale ............................................................................................................................ 32
6.1.3
Service formulaire .................................................................................................................... 32
6.1.4
Général .................................................................................................................................... 32
LISTE DES CODES DE STATUT ..................................................................................................................... 35
ENVOI D’EMAIL EN CAS D’ERREUR ................................................................................................................ 37
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
4 / 39
Projet sM-Client
Version finale
Manuel d’exploitation
TABLEAU DES ILLUSTRATIONS
Figure 1 – Architecture de référence ..................................................................................................................9
Figure 2 – Interfaces vers l’adaptateur ............................................................................................................ 10
Figure 3 – Interfaces vers les applications métiers ......................................................................................... 11
Figure 4 – Exemple d’interfaces externes ....................................................................................................... 12
Figure 5 - Mandants multiples ......................................................................................................................... 13
Figure 6 – structure interne du sM-Client ........................................................................................................ 14
Figure 7 – Plusieurs clients sM ........................................................................................................................ 25
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
5 / 39
Projet sM-Client
Version finale
Manuel d’exploitation
GESTION DES DOCUMENTS
Historique
Version
Modifié
Description
Date
Validé
01
Martin Liebrich
Elaboration, chapitrage et première version
14.08.2009
SM
02
Martin Liebrich
Compléments suivant le retour d'information
24.08.2009
SM
03
Stefan Malär
Adaptations et chapitrage du
l’utilisateur/manuel d’exploitation
31.08.2009
ML
10
Stefan Malär
Version finale
31.08.2009
ML
11
Sylvain
Berthouzoz
Mandants multible, Backup et Recovery
17.03.2010
CW
12
Sylvain
Berthouzoz
Sylvain
Berthouzoz
Recommandation au sujet de la mémoire requise
19.01.2011
SM
Détails au sujet de la mémoire
03.02.2011
SM
14
Sylvain
Berthouzoz
Liste des code de statut
07.06.2011
CW
15
Sylvain
Berthouzoz
Installations Serveur, mesure
Envoi d’email en cas d’erreur
11.01.2012
CW
16
A. Rapanaro
3.6.3 Mise à jour des plug-ins
3.8 Plug-ins
18.01.2012
CW
17
S. Berthouzoz
3.2.2 Limitations des backups
22.02.2012
CW
18
S. Berthouzoz
3.2.1 monitoring platform
26.09.2012
CW
19
S. Berthouzoz
Input AWK
29.09.2012
CW
20
Andreas Dejung
Neue JMS-Extension Zustände
Informationen hinzugeführt
50
Andreas Dejung
Informationen für Release 5.0 hinzugefügt
15.04.2013
501
S Berthouzoz
Feedback RC2, RC3
24.07.2013
507
S Berthouzoz
Informationen für Release 5.0.7 hinzugefügt (2.2,
2.3.3)
20.03.2014
508
S Berthouzoz
Aktualisierung
Arbeispeicher
(2.2.1),
Informationen für Release 5.0.8 hinzugefügt (2.2,
2.3.3)
27.06.2014
S Berthouzoz
Kapitel 3.2.3 Überprüfung des korrekten
Verarbeitung, Infos für Anmeldung an der
Monitoring Platform im Kap. 3.2.1, Log 3.2.2
17.10.2014
13
manuel
de
de
sécurité
und
Log
16.01.2013
Références
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
6 / 39
Projet sM-Client
Version finale
Manuel d’exploitation
ID
Nom
Version
Document
01
Design technique
5.2
Technisches_Design_sM-Client_v5.2.pdf
02
Manuel d’installation
5.0.1
Installations-Handbuch_sM-Client_v5.0.1.pdf
03
Load Tests Resultats
1.0
Load Tests Resultate.pdf
04
05
06
07
08
09
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
7 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Objet du Document
1 OBJET DU DOCUMENT
Ce manuel d’exploitation sert de document de base pour les manuels d'exploitations des participants. Il
comprend les informations techniques usuelles nécessaires à l’exploitation ainsi que des „best practices“.
Ce manuel est importante source d’information pour appuyer l’exploitation quotidienne par des
descriptions détaillées et l’explication de toutes les étapes active et proactives pour maintenir le système
en marche et pour éviter des arrêts (pannes) non prévus. Il décrit des cas d’exploitation particuliers
comme p.ex. la reprise de l’exploitation après des arrêts prévus ou non prévus, la préparation d'arrêts
planifiés dans des fenêtres de maintenance, la recherche de pannes et la correction de pannes de toutes
les étapes de travail actives et proactives (p.ex. extension de Hardware / Software et de licences)
pour assurer les performances nécessaires malgré l’agrandissement et l’utilisation accrue du système.
Ce manuel décrit également l’utilisation de Testbed, lequel permet de tester un environnement sans
devoir utiliser un adaptateur sedex.
.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
8 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
aperçu général
2
APERÇU GENERAL
Décrit les relations techniques générales du système et offre un aperçu général à l’exploitant.
2.1 Architecture du système et interfaces
2.1.1 Architecture du système
Le diagramme suivant montre l’architecture de référence du client sM.
sM-Client Package
Cluster
Hornet Q
2.2.14
JBoss AS 4.2.3
GA
Lokale Disk/
NAS
MySQL 5.1
GA
Figure 1 – Architecture de référence
Suivant l’installation, JBoss doit être remplacé par un autre serveur d’application (par exemple Apache
Tomcat), et MySQL par d’autres banques de données. Il est également possible d’utiliser en plus un
LDAP ou AD.
Le code client sM Core tourne sur le serveur d'application.
HornetQ est l’implémentation JMS utilisée par le sM-Client, aussi nommée sM-Client Queue dans le
présent document
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
9 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
aperçu général
Les données de base nécessaires à l’exploitation du client sM sont stockées dans la banque de
données. Les données de traitement pour les messages sont également stockées dans la banque de
données (voir chapitre 3.5.
Le disque local ou le NAS est utilisé pour la sauvegarde temporaire des messages lors de leur passage
dans le système. Les messages JMS de la Queue de HornetQ sont aussi sauvegardés sur le disque local
ou le NAS. Un éventuel Backup est également enregistré ici.
Si un LDAP / AD est utilisé, celui-ci contient les données utilisateur et de login. Sinon, elles sont stockées
dans la banque de données.
Autres informations sur l’architecture du système dans le chapitre 2 du document "Design technique
client sM".
2.1.2 Interfaces
Un aperçu général peut être tiré des diagrammes suivants.
Fachapp.
oder
externe
Triage
sM-Client
IF
Meldung
Eingang
Quittung
Eingang
Meldung
Ausgang
sedex Adapter
Figure 2 – Interfaces vers l’adaptateur
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
10 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
aperçu général
Ablage
Meldung
Eingang
Fachapp.
oder
externe
Triage
Meldung
Ausgang
sM-Client
Gesendet
Gescheitert
IF
sedex Adapter
Figure 3 – Interfaces vers les applications métiers
Les répertoires doivent être adaptés aux besoins individuels de l’exploitant. En principe il est prévu de
créer un répertoire par application métier ou triage externe. Un exemple est montré ci-dessous.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
11 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
aperçu général
Figure 4 – Exemple d’interfaces externes
Les interfaces sont décrites en détail dans le chapitre 4 du document "Design technique client sM".
A partir de la version 2.0.x, il est possible d’installer plusieurs mandants avec un seul serveur
d’application, cela signifie que l’on peut exécuter plusieurs instances du client sM sur le même serveur.
Reportez vous au manuel d’installation pour l’activation et la configuration des mandants. Le diagramme
suivant illustre ce principe :
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
12 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
aperçu général
Figure 5 - Mandants multiples
Chaque mandant dispose de sa propre configuration et de sa propre structure de répertoire.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
13 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
aperçu général
sM-Client
Fachapp.
oder
externe
Triage
IF
sM-Client
Queue
sM-Client
Core
IF
sedex Adapter
Figure 6 – structure interne du sM-Client
A partir de la version 5.0, le sM-Client est divisé en deux processus. Le sM-Client Core est comme
auparavant un serveur d’application basé sur JBoss AS ou Tomcat. Le processus sM-Client permet
l’emploi des extensions JMS et est basé sur HornetQ.
2.2 Installation et configuration requise – Serveur
Les conditions requises pour installer et exploiter le client sM (y compris le Testbed) sont les suivantes.
Les versions supportées des différents composants sont listées dans le document de design technique :

JBoss (voir plateforme de référence) ou Apache Tomcat

MySQL (voir plateforme de référence), Oracle, MSSQL

JDK

1 Go de libre sur le disque dur pour l’application

Installation minimale locale pour une utilisation simple utilisateur (Desktop, seulement pour les
tests) :
o
2 Go de mémoire Memory (1.25 Go libre pour l‘application)
Configuration JVM pour sM-Client Core (JBoss):
-Xms512m -Xmx1024m -XX:MaxPermSize=512m
Configuration JVM pour sM-Client Queue (HornetQ):
-Xms256m –Xmx256m
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
14 / 39
sM-Client Projekt
Version finale
Installations-Handbuch

aperçu général
Installation minimale pour l’expoitation (serveur) :
o
4Go de mémoire (3 Go de libre pour l‘application)
Configuration JVM pour sM-Client Core (JBoss):
-Xms512m -Xmx2816m -XX:MaxPermSize=512m
Configuration JVM pour sM-Client Queue (HornetQ):
-Xms256m –Xmx256m

Pour Windows il est recommandé d’utiliser les même valeurs pour MinHeapSize et MaxHeapSize
pour éviter le swapping de mémoire, par example :
set JAVA_OPTS=%JAVA_OPTS% -Xms1024m -Xmx1024m -XX:MaxPermSize=512m
Le disque dur et la mémoire sont les conditions minimales pour l’exploitation d’un ordinateur individuel
exécutant un seul mandant. Pour l’exploitation d’un centre de calcul il est nécessaire de prévoir des
conditions requises plus importantes, en particulier la mémoire.
De plus, les interfaces de répertoires nécessitent de la place de stockage sur un support adéquat (disque
dur, NAS) suivant la taille et le volume des messages.
L’installation et la configuration sont décrites dans le document "Manuel d’installation client sM".
Des mesures de sécurité supplémentaires pour un serveur accessible sur internet sont contenues dans le
document suivant http://community.jboss.org/wiki/SecureTheJmxConsole.
Une vue d’ensemble des tests de montée en charge se trouve dans le document « Load Tests
Resultats » [03]
2.2.1 Recommandation concernant la configuration mémoire
Différents facteurs influencent la quantité de mémoire employée. Les facteurs sont le nombre de
mandants, la taille des messages à traiter, la taille des messages à imprimer ainsi que l’utilisation ou non
du service de formulaire
Les recommandations minimales suivantes (3 Go libre pour l’application) permettent l’exploitation dans
les conditions suivantes :
-
Un seul mandant actif
-
Message dont la taille au format XML fait moins de 100Mo (Beaucoup de ces grands messages à
traiter en même temps peuvent par contre causer un ralentissement du traitement des messages)
-
Messages dont le fichier XML fait moins de 2Mo peuvent être imprimé, ou exporter comme PDF.
-
Le service de formulaire peut être employé
-
Jusqu’à 100 000 messages JMS dans sM-Client Queue
Plusieurs mandants
Lors de l’exploitation de plusieurs mandants, les recommandations suivantes doivent être prise en
compte. Ces recommandations supposent que les mandants ne sont pas tous employés à pleine charge
au même moment.
-
Pour les deux premiers mandants supplémentaires, ajouter 1Go (0.5Go sans service de formulaire)
par mandant
-
Pour les mandants suivants, ajouter 0.5Go (256Mo sans service de formulaire) par mandant
Example
de
configuration
pour
3Go + 2 x 0.5Go + 7 x 250Mo = 5.75Go
10
mandants
sans
service
de
formulaire :
-Xms1024m -Xmx5632m -XX:MaxPermSize=1024m
Messages plus grand
En principe, il est possible d’envoyer de plus grands messages avec plus de mémoire. Ainsi on peut
envoyer des messages deux fois plus grands avec deux fois plus de mémoire.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
15 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
aperçu général
Les valeurs données correspondent à une marge de sécurité, il est en théorie possible de traiter des
messages de n’importe quelle taille, mais il n’est pas garanti que cela fonctionne sans problème. Il faut
aussi tenir compte du fait que des messages de plusieurs centaines de Mo peuvent occasionner des
problèmes au niveau de la vitesse d’accès au disque.
La configuration de sM-Client Queue est indépendante du nombre de message.
Impression de messages et génération de PDF
Avec plus de mémoire, il est aussi possible d’imprimer et de générer un PDF pour de plus grand
messages. Avec 2.75Go des messages jusqu'à 4Mo XML peuvent être imprimés le fichier PDF peut être
généré.
Exemple de configuration avec 2.75Go : -Xms1024m –Xmx3584m -XX:MaxPermSize=756m
La limite pour l’impression et la génération de PDF sont configurés dans le fichier config.properties.
Par défaut : print.message.smaller=2048
Attention au fait que des messages de 4Mo génèrent environ 700 pages, ce qui peut poser problème lors
de l’impression.
Configuration de sM-Client Queue
Pour la configuration de HornetQ, des valeurs minimales sont utilisées. Ces dernières peuvent être
adaptées si besoin. Par principe, plus il y a de message JMS dans la Queue, plus il faut de mémoire.
Tous les messages JMS ne sont pas gardés en mémoire, mais pour des raisons de performances, il est
recommandé de définir la mémoire de manière à ce que tous les messages JMS puissent être
enregistrés en mémoire. Le stockage des messages JMS sur le disque est désactivé par défaut. Veuillez
aussi à ne pas confondre les messages JMS avec les messages sM-Client. Les messages JMS ne
contiennent qu’une référence sur un message sM-Client et de ce fait a une taille de seulement quelques
octets.
Tuning
2.3
2.3.1 Polling Intervall
config.properties


filechange.listener.interval: Temps entre chaque lecture des dossiers Inbox, receipts et Outbox
o La valeur par défaut est de 15 secondes
message.batch.pickup.size: Nombre de messages traités par dossier en un passage.
o Valeur par défaut est de 50 (soit 50 fichiers depuis Inbox, 50 de Receipts, 50 de Outbox)
Idéalement tous les fichiers devraient être traité durant un passage, soit durant
[filechange.listener.interval] secondes. Par exemple: avec message.batch.pickup.size=10, soit 10
messages im Outbox, 10 quittances Sedex, 10 messages dans Sedex Inbox)Beispiel:
filechange.listener.interval=120
Le traitement d’un message dure entre 3 et 5 secondes :
30 x 3 = 90 Sekunden bis 30 x 5 = 150 Sekunden
Ainsi le traitement peut rester dans l’intervalle de 120 secondes et les messages suivants seront lu à la
fin du traitement ou après filechange.listener.interval=120 secondes.
2.3.2 sM-Client Queue
Les paramètres suivants de message-handler-[domain].properties peuvent être utilisés pour définir le
type de queue employé pour le traitement des messages (voir aussi [02])

Créé le:
max.num.msg
24 octobre 2014
von Cambridge Technology Partners © 2013
16 / 39
sM-Client Projekt
Version finale
Installations-Handbuch



aperçu général
max.num.msg.pdf
Messages groupés avec plus de messages internes que max.num.msg seront traités dans la
queue standard, les autres dans la queue priority. (pour la validation)
max.num.msg.pdf a la même signification pour la génération du PDF.
max.size
max.size.pdf
Messages ou la taille des messages XML dépasse max.size seront traités dans la queue
standard, les autres dans la queue priority. (pour la validation)
max.size.pdf a la même signification pour la génération du PDF.
Pour décider du traitement dans la queue standard, le sM-Client vérifie d’abord le nombre de messages,
puis la taille de ces derniers.
sM-Client peut traiter un message par queue en même temps.
2.3.3 Stuck Message Detector
Les paramètres suivant de global-config.properties servent à configurer le StuckMessageDetector. Ce
dernier permet de retraiter les éventuels messages bloqués.





stuck.retry.time.offset.minutes
stuck.retry.big.msg.minutes
stuck.job.interval.minutes
stuck.retry.max.amount
stuck.retry.small.msg.size
jms.sender.timeout.hours dans message-handler-[domain].properties doit
stuck.retry.big.msg.timeout dans global-config.properties gesetzt werden.
être
plus
grand
que
ATTENTION: jms.sender.timeout.hours est configuré en heures et stuck.retry.big.msg.timeout en minutes
IMPORTANT : Les valeurs par défaut prédéfinis ne doivent pas être modifier lors d’une utilisation
normale.
Ces valeurs prédéfinis ne devraient être modifiées que dans des circonstances particulières et après
discussion avec le support sM-Client
2.4 Installation et configuration requise – Client
Clent sM est conçu comme une application basée sur le Web. Pour le client on utilise donc un navigateur
Web (Internet Explorer 6+, Firefox 2+). On suppose qu’un tel programme navigateur est déjà installé sur
l’ordinateur client.
L’interface Web du client sM n'impose pas de conditions particulières au navigateur ni à la capacité de
performance de l'ordinateur Comme pour le service formulaire on utilise AJAX, on recommande d’utiliser
Firefox 3+, IE7 ou IE8 dans le mode compatibilité. Un ordinateur ordinaire du marché doit être suffisant
pour utiliser le GUI.
2.5 Aperçu des environnements développement, test et
production installés
A compléter par l’exploitant.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
17 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
3 EXPLOITATION
3.1 Démarrage et arrêt de l’exploitation
Conditions pour le démarrage ou le redémarrage de l’exploitation
L’installation et la configuration sont décrites dans le document "Manuel d’installation client sM".
Première démarrage de l’exploitation
Avant le premier démarrage de l’exploitation, il est nécessaire de s’assurer que toutes les configurations
aient été faites comme décrit dans le "Manuel d'installation client sM".
Démarrage et arrêt normal
Si client sM a été installé avec Start-Script, une procédure de démarrage et d’arrêt est à disposition
(répertoire $INSTALL_PATH/scripts/windows|linux – start_smclient.bat|.sh resp. stop_smclient.bat|sh).
Si le client sM a été installé comme service, le service respectif peut être démarré ou arrêté.
Interruption d’exploitation planifiée (arrêt et redémarrage)
Les mêmes possibilités d’arrêt et de démarrage sont possibles pour les interruptions d'exploitation
planifiées que celles décrites plus haut.
Interruption d’exploitation non planifiée (panne du système)
Après une panne il faut s’assurer que les processus du serveur JBoss, HornetQ et de la banque de
données MySQL ne tournent plus. Ils doivent être éventuellement terminés avec les outils adéquats.
Si la fonction Backup était activée avant l’arrêt, il est possible d’effectuer une restauration comme décrite
dans le chapitre 4.4 du document "Manuel d’installation client sM".
Traitement postérieur et travaux de clôture:
Si des travaux de clôture sont nécessaires après arrêt de l’exploitation, ils doivent être indiqués ici. Ceci
peut par exemple concerner le traitement des supports de données.
3.2 Exécution
et
(monitoring)
surveillance
de
l’exploitation
Décrit les mesures pour le bon fonctionnement et la surveillance de l’exploitation.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
18 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
3.2.1 Monitoring centralisé
Dès le 01.01.2013 la plateforme smc-monitoring.ctp-consulting.com sera mise en place et enverra
chaque jour à tous les participants inscrits un message de monitoring. L’exploitant pourra donc voir sur
cette plateforme si son adaptateur sedex et/ou son sM-Client est atteignable. La disponibilité des autres
participants inscrits peut aussi être consultée sur la plateforme via un tableau de bord.
De façon à ce que ces messages de monitoring ne perturbent pas l’exploitation courante, il est
nécessaire de définir une règle de triage pour placer ces messages de monitoring dans un dossier
spécifique. (Voir le manuel d’installation au chapitre 4.2.3 pour les détails techniques de configuration)
Si ces messages ne sont pas placés dans un dossier spécifique, il convient de les ignorer. Les messages
de monitoring sont de types :

Type de message 2991 pour les participants BSV

Type de message 3991 pour les participants SSK
Si malgré la règle de triage un message de monitoring aboutit dans un dossier standard du sM-Client, ce
message doit être ignoré. Cela peut arriver dans le cas d’une quittance de protocole d’un message de
monitoring intransmissible et qui serait dans le dossier failed_to_transmit.
La plateforme de monitoring envoie un email à chaque participant, lorsque son adaptateur Sedex et/ou
sM-Client n’est pas atteignable, ce n’est qu’à ce moment qu’il est nécessaire de contrôler le déroulement
des messages de monitoring sur le serveur local (soit le serveur de l’exploitant).
L’accès à la plateforme de Monitoring n’est possible qu’après inscription auprès de Support-SMClient@ctp.com avec mention de votre sedexId ainsi que d’une adresse email, laquelle recevra les
notifications de la plateforme de Monitoring.
3.2.2 Server Monitoring
Le client sM enregistre toutes les données intéressantes pour le monitoring dans le fichier Log. La
configuration du Log est décrite dans le manuel d’installation au chapitre 4.2.4.1.1 « Log ». Il est
recommandé de conserver les fichiers de Logs pour une période minimale de 6 mois. Les différents
messages sont décrits en annexe 6.1 de ce document.
Le client sM donne périodiquement un message de fonctionnement (message i-0500) pour chaque
mandants. L'exploitant peut vérifier à l’aide de ce message si le client sM fonctionne.
Es ist möglich, eine Email Zu schicken im Fall von einem Fehler, siehe Anhänge.
La vérification de ce Log doit être décrite par l’exploitant.
Le client sM enregistre chaque étape de processus pour les messages dans la table Message. Les
différents codes et messages sont décrits en annexe 6.2 de ce document.
3.2.3 Vérification du traitement correct des messages
Pour vérifier le traitement correct d‘un message, vous disposez des possibilités suivantes :

Vérification
du
statut
dans
le
suivi
d‘audit:
Les statuts suivant repésentent un traitement réussi d‘un message (il y a un statut général et un par
domaine).Les messages, qui restent pendant plusieurs jours en cours de traitement ont un statut
différent et doivent être vérifiés plus en détail.

Créé le:
Statuts „Traitement terminé avec succès (Réception)“:

message-handler-ech0058v4 receive ended

message-handler-receive process ended

message-handler-moved message

message-handler-eschkg receive ended
24 octobre 2014
von Cambridge Technology Partners © 2013
19 / 39
sM-Client Projekt
Version finale
Installations-Handbuch

message-handler-end elm receive
Statuts „Traitement terminé avec succès (Envoi)“:


Exploitation

message-handler-end elm send

message-handler-send process ended

message-handler-eschkg send ended

message-handler-moved to sent

message-handler-ech0058v4 send ended
Pour être sûr qu’aucun message n’est en cours de traitement, il faut aussi vérifier les dossiers
suivants :

Failed_to_transmit, Failed_to_send, Failed (voir Error! Reference source not found. ainsi
que le manuel d’installation au chap. 4.2.1 „Configuration des dossiers des interfaces“ et
4.2.2.3 „message-handler.properties“): Les messages se trouvant dans ces dossiers
représentes ont subi une erreur de traitement et doivent être examinés plus en détails (p.ex.
au moyent du suivi d’audit, des fichiers de Logs et des fichiers d’erreurs éventuels contenus
dans le message).
Le dossiet temporaire ne devrait pas contenir de fichiers vieux de plus de 30 jours (sedex-Timeout): Par
défaut,
le
dossier
temporaire
est
celui
du
système
d’exploitation
(C:\Users\'username'\AppData\Local\Temp sous Windows7 et /tmp sous Linux). Ce dossier peut aussi
être configuré ailleurs, comme décrit dans le manuel d’installation.
3.2.4 Backup et Recovery
Limitations lors de la sauvegarde
La fonction de backup intégré du sM-Client n’est prévue que pour des petites quantités de messages (<
10000 entrées dans la table Message) autrement il est recommandé d’utiliser une solution de backup
externe (par example mysql dump)
Limitations lors de la sauvegarde avec plusieurs mandants

Il est possible de faire une sauvegarde simple de la base de donnée (BD sans les processus, avec
les fichiers) ainsi qu’une sauvegarde complète de la base (BD avec les processus). La restauration
de la sauvegarde peut se faire par l’administrateur correspondant au mandant. Pour une utilisation
du sM-Client avec un seul mandant, aucun changement n’est donc à signaler

Si plusieurs mandants sont configurés, il faut tenir compte des points suivants :
o
La sauvegarde simple peut être configuré par mandant et restauré par l’administrateur du
mandant
La sauvegarde complète fonctionne pour la base de donnée dans son ensemble, soit pour tout les
mandants gérés par le sM-Client. C’est pourquoi il ne faut activer la sauvegarde complète que pour un
seul mandant ET ce mandant ne doit pas exécuter la sauvegarde au même moment que les autres. (= il
faut une valeur différente pour time.of.day.for.backup) ni dans le même répertoire. Après une restauration
complète de la base de donnée (qui a lieu en dehors de l’application sM-client), tous les administrateurs
doivent restaurer les fichiers depuis l’interface. Cela pour autant que ces mandant aient activés la
sauvegarde simple (sinon aucun fichier ne peut être restaurés). Le sM-Client ne fait aucune vérification à
ce sujet.
Backup pour sM-Client Queue
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
20 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
Le système sM-Client Queur (HornetQ) utilise un stockage persistant pour la gestion des Queues. Les
informations sont stockées dans le système de fichier. sM-Client Core peut renvoyer les messages JMS
en attente, de telle façon que le traitement puisse reprendre sans qu’une backup des messages JMS ne
soit nécessaire. Un backup des messages JMS aurait de plus aucun sens au vue de la faible durée de
vie des messages JMS ; un backup devrait être fait après chaque traitement d’un message JMS, ce qui
arrive toutes les quelques minutes.
3.2.4.1Backup
Le mécanisme du backup permet de sécuriser les données suivantes :

backup.enabled : Messages (fichiers et table message, inclus les audits), configurations et
référentiels (système fichier)

backup.fullDB.enabled : Informations de traitement, Audit Trail, éventuellement les utilisateurs
(entrées banque de données)
Le mécanisme du backup prévoit que les données soient déplacées en paquet, à un moment et dans un
répertoire définis (à configurer dans config.properties). Il est judicieux de ne pas placer le répertoire sur la
même machine. Localement, il est de la responsabilité de l’exploitant de sécuriser et de mettre à jour le
backup.
Le backup peut être configuré avec config.properties. Les possibilités de configuration suivantes sont
disponibles :

backup.enabled – active ou désactive le backup

backupDirectory – répertoire dans lequel le backup est enregistré

time.of.day.for.backup – heure à laquelle le backup est effectué

backup.fullDB.enabled – backup complet (MySQL DB-Dump) activé ou désactivé.
L’emplacement du backup complet peut être configuré dans le script backupBatch (par exemple
MySQLSmClientBackup.bat)
Le client sM effectue ensuite lui-même le backup en fonction de la configuration. La logique du backup
doit être simple, car sinon il est possible que des données soient perdues entre le backup et la panne. Si
le backup est enregistré sur le même support que le Filesystem et la banque de données, il est possible
qu’un backup soit complètement perdu. Il est donc fortement recommandé d’enregistrer le backup sur un
autre disque physique.
Si une conservation ou un visionnement des backups individuels est souhaité, c'est à l'exploitant de s'en
assurer.
Un enregistrement redondant des données est recommandé pour augmenter la sécurité (banque de
données et répertoires).
3.2.4.2 Restore (restauration)
Le backup peut être restauré par l'administrateur technique, sous l’entrée de menu Backup de l’interface
utilisateur.
Il faut également noter que lors de la restauration de la banque de données, les données existantes sont
supprimées.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
21 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
Le Restore peut être fait individuellement pour le système fichier et pour les entrées de la banque de
données. Pour éviter une incohérence (la banque de données et le système fichier ne correspondent
pas), le Restore devrait toujours être fait complètement. Les incohérences sont signalées par des
messages d’erreur dans le journal ou par l’affichage du message dans la case postale, comme par
exemple "Le message a été supprimé et n’est plus disponible" ou "Une erreur est survenue lors de la
suppression".
Si une incohérence est permanente, elle doit être corrigée par l’administrateur :

Le message correspondant peut être cherché dans Audit Trail à l’aide des attributs connus (p.ex.
messageId, type, expéditeur). Le lieu de stockage prévu et le nom y sont indiqués.

Les messages d’erreur correspondant peuvent également être trouvés dans le Log.

Sur le système fichier il est possible de vérifier si le message n’est vraiment plus disponible.

Si c’est le cas, l’administrateur peut chercher le fichier avec le nom et, s'il existe, le copier dans le
dossier adéquat.

Si le message n’existe plus, il est éventuellement possible de vérifier dans le backup si le fichier
s’y trouve encore.

Si l’incohérence ne peut être corrigée de cette manière, il est nécessaire de placer l’entrée dans
le tableau message de la banque de données, sur currentStateMsg "mailbox permanently
deleted".
Si des fichiers sont trouvés dans le système fichier et ne sont plus affichés sur l’interface, il est également
possible de les rechercher dans Audit Trail. La correction est analogique, le fichier devrait être déplacé à
l’endroit adéquat ou supprimé manuellement de la banque de données.
Pour trouver des incohérences après restauration, l’exploitant peut effectuer les vérifications suivantes :
Lors d’une restauration des données uniquement, il est possible de trouver dans Audit Trail toutes les
données qui ont été modifiées après le moment de la restauration du backup ; et si elles ne sont plus
cohérentes avec le système fichier, l’incohérence peut être corrigée selon description ci-dessus.
Lors d’une restauration de la banque de données uniquement, il est possible de trouver dans le système
fichier toutes les données qui ont été modifiées après le moment de la restauration du backup ; et si elles
ne sont plus cohérentes avec la banque de données, l’incohérence peut être corrigée selon description
ci-dessus.
3.2.5 Détenteurs, responsables et contacts
Un support est disponible pendant la phase pilote à l’adresse e-mail suivantes :
support-sm-client@ctp-consulting.com
Les autres contacts, responsabilités et déroulements doivent être décrits par le PL ou l’exploitant
respectif.
3.2.6 Heures de service
A compléter par l’exploitant
3.3 Indicateurs de performance (KPI)
Indicateurs de performance relatifs à l’utilisation – serveurs qui doivent être gérés par l’exploitant.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
22 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
3.4 Restrictions connues
Il n’y a pas de restrictions fonctionnelles.
Il n’y a pas de restrictions techniques.
Il n’y a pas de restrictions concernant la capacité.
3.5 Archivage et suppression de données
Comme le client sM est une interface, ou Middleware, il n’offre pas de fonctions pour l’archivage ou la
suppression de données.
Les données ne doivent pas s'accumuler dans les répertoires interfaces en exploitation normale, car
celles-ci sont chaque fois récupérées et traitées par un système. Ceci doit être vérifié périodiquement.
Une grande accumulation de données peut indiquer un problème du système général.
Le client sM utilise des répertoires internes pour les fichiers temporaires. Ces fichiers sont supprimés par
le client sM lui-même. Ceci doit également être vérifié périodiquement. Une grande accumulation de
données indique un problème avec le client sM.
Les répertoires pour les messages échoués (failed resp. failed_to_send, failed_to_transmit) doivent être
vérifiés régulièrement. Failed_to_send et failed_to_transmit contiennent des messages qui ont échoués
lors du processus d’envoi. Ces messages peuvent être vérifiés sur la case postale, mais doivent être
supprimés manuellement du répertoire. Les messages qui ont échoués lors du processus de réception
sont déposés dans failed. Ce répertoire n’est pas affiché dans la case postale et doit être traité hors du
client sM (manuellement ou par une autre application).
Dans la banque de données, il faut s’attendre à une forte augmentation du volume de données dans les
tableaux Message et smAudit. Ces données peuvent être supprimées ou archivées après traitement
(statut „Permanently Deleted“ ou „Message Sent“ dans le tableau Message). il faut alors s’assurer que les
messages soient supprimés ou archivés de manière cohérente dans les deux tableaux.
Les tableaux smUser, smRole, smUser_smRole, smMandant et configuration contiennent des données
de base. La croissance ici devrait être minime.
Fichiers Log et fichiers erreurs
Gestion de capacité
Enregistrement de la capacité et surveillace
Révision régulière de l’utilisation de la capacité
Intervention corrective pour éliminer l’usage incorrect
Planification de la capacité
3.6 Nouvelles versions et mises à jour
3.6.1 Nouvelles versions de client sM
En cas d’une nouvelle version du client sM celui doit être réinstallé. Les directives respectives sont livrées
avec la nouvelle version.
Pour installer une nouvelle version le client sM doit être arrêté, c.-à-d. la banque de données, le serveur
d’application et HornetQ doivent être arrêtés selon la procédure. L’installation peut alors s'effectuer selon
les indications données.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
23 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
Il est recommandé de sauvegarder la banque de données et les répertoires afin de ne pas les écraser
pas mégarde.
3.6.2 Mise à jour du repository
Les mises à jour du stockage sont distribuées aux participants via sedex par des messages. Les valeurs
suivantes peuvent être paramétrées dans le fichier de configuration config.properties.

update.message.types: Configuration du type de message qui reçoit le message de mise à jour.
Paramétré sur 2990 pour eAVS/AI, sur 3999 pour CSI.

autoupdate: oui ou non ; si oui, le stockage est automatiquement actualisé après réception du
message de mise à jour ; si non, la mise à jour doit être confirmée par un administrateur.

time.of.day.for.update: Heure du jour à laquelle la mise à jour doit être effectuée (que la mise à
jour se fasse automatiquement ou non.
Si autoupdate est sur "non", le message w-0423 apparaît dans les fichiers Log. L’exploitant peut
surveiller cette entrée Log pour informer un administrateur client sM, afin que ce dernier confirme la mise
à jour. L’administrateur peut se connecter dans le client sM et confirmer la mise à jour à l’aide d'un
bouton dans la configuration technique.
Une mise à jour manuelle est possible en supprimant le contenu du répertoire repository, ensuite
décompresser la nouvelle version dans le dossier repository, puis relancer le serveur JBoss.
3.6.3 Mise à jour des plug-ins
Normalement les plug-ins sont livrés avec un nouveau repository et ils se trouvent dans le repertoire
"plugins/".
Par default ce répertoire est scanné au fin de contrôler si des plug-ins ont été installés ou mis à jour, mais
il est possible d'en configurer un autre (cf. Manuel d'installation au chapitre 4.2.24).
Les plug-ins peuvent être installés ou mis à jour pendant le fonctionnement du sM-Client, mais pour les
effacer il est nécessaire de redémarrer l'application.
3.7 Plusieurs clients sM ou communications sur un
adaptateur sedex
Si plusieurs clients sM (ou plusieurs mandants) ou différentes communications accèdent sur le même
adaptateur sedex, il faut s’assurer que chaque client ne puisse accéder qu’à ses propres données dans
l’interface de l’adaptateur.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
24 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
sM-Client 1
sM-Client 2
Meldung
in Arbeit
Meldung
in Arbeit
Meldung
Eingang
Quittung
Eingang
Meldung
Ausgang
sedex Adapter
Figure 7 – Plusieurs clients sM
Le client sM peut être configuré en conséquent par Triage dans le fichier rule.xml. Cela permet aussi de
s’assurer qu’aucun message d’un autre type de communication ne soit accédé.
A noter qu’un message envoyé simultanément au deux clients sM n’est traité qu’une fois par un
adaptateur. Après 5 jours le deuxième message est également traité si l’autre client sM est inactif
pendant toute cette durée. Dans ces cas il est recommandé que les messages pour le client sM, qui hors
service sont sauvegardés provisoirement ailleurs, lui soient remis dès que celui-ci est à nouveau en
service.
Il y a deux possibilités pour utiliser sM-Client Queue avec plusieurs sM-Client Core :

Chaque sM-Client Core gère son propre sM-Client Queue, dans ce cas il faut veiller à ce que les
différents ports n’entrent pas en conflit.

Un seul sM-Client Queue pour tous les sM-Client Core, dans ce cas il faut veiller à ce que le nom
des Queues soient uniques dans la configuration des sM-Client Core
Explication pour l’usage des règles
L’élément <triage> comprend un nombre au choix d’éléments <rule>. Les règles sont traitées à la suite,
dans lesquelles elles apparaissent. Les règles spécifiques doivent donc être tout en haut.
Pour cette configuration on utilise le Use Case „adapter“.
<rule> contient dans Use Case „adapter“:
<criteria> - critères de la règle qui sont analysées
<useCase> - adaptateur
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
25 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
<criteria> peut vérifier les valeurs suivantes dans „adapter“
<messageType>
<recipientId>
Toutes ces valeurs se réfèrent à la valeur correspondante dans le message
Les combinaisons de valeurs suivantes sont possibles pour <criteria>
aucune -> règle par défaut (n’est justement pas utilisée dans ce cas)
<messageType>
<recipientId>
<messageType> et <recipientId>
Exemple règles adaptateur
Voici quelques exemples d’application des règles adaptateur, si plusieurs clients sM ou applications sont
connectés à un adaptateur.
Cette règle permet de saisir tous les messages de type 3001 envoyés au destinataire T6-900014-2:
<rule>
<criteria>
<recipientId>T6-900014-2</recipientId>
<messageType>3001</messageType>
</criteria>
<useCase>adapter</useCase>
</rule>
Cette règle permet de saisir tous les messages de type 3002 :
<rule>
<criteria>
<messageType>3002</messageType>
</criteria>
<useCase>adapter</useCase>
</rule>
Cette règle permet de saisir tous les messages envoyés au destinataire T6-900014-1:
<rule>
<criteria>
<recipientId>T6-900014-1</recipientId>
</criteria>
<useCase>adapter</useCase>
</rule>
Avec deux adaptateurs, un utiliserait p.ex. la règle adaptateur avec recipientId est T6-900014-1 et l’autre
la règle adaptateur avec recipientId est T6-90014-2. Chaque adaptateur ne traite ainsi que les messages
qui lui sont destinés.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
26 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Exploitation
3.8 Plug-ins
Les plug-ins se trouvent par default dans le répertoire "plugins/". Dans le cas d'une installation de
plusieurs mandants et repository ceci n'est pas optimal, car plusieurs répertoires devraient être scannés
pour des mises à jour des plug-ins qui, souvent, contiennent les mêmes fichiers. Il est donc possible de
spécifier un chemin absolu, qui serait en commun entre les différents mandants.
plugins.dir=/chemin/vers/plugin/repertoire
Une autre raison qui justifierait l'emploi d'un répertoire commun dans le cas de mandants multiples est
d'avoir un endroit centralisé pour le stockage des plug-ins, ce qui permettrait de garantir une meilleure
consistance. Tous les mandants pourraient donc utiliser les mêmes versions des plugins en cas de mises
à jour.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
27 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Consignes de sécurité
4 CONSIGNES DE SECURITE
Décrit les consignes et mesures pour garantir la sécurité nécessaire. Ceci comprend l’infrastructure,
l’organisation et le personnel ainsi que les prévoyances en cas de catastrophe et les assurances.
Sauvegarde des données
Le client sM n’effectue pas de sauvegarde à long terme des messages. Seules les données sur les
messages son enregistrées dans la banque de données, mais pas les messages mêmes. Des mesures
de sécurité particulières pour une sauvegarde à long terme de données sensibles ne sont donc pas
nécessaires.
Protection de la banque de données
L’accès direct à la banque de données doit être limité aux administrateurs, afin que l’état du client sM ne
soit pas corrompu ou rendu incohérent par des modifications non intentionnelles ou délibérées dans la
banque de données.
Protection des messages de sM-Client Queue
sM-Client Queue contient uniquement des références sur les messages sM-Client en cours de traitement,
mais pas de messages Sedex en tant que tel. Pour cette raison, il n’est pas nécessaire de prendre des
mesures de sécurité particulières pour un enregistrement de données sensible.
Protection des répertoires
Le client sM utilise des interfaces de répertoires pour la communication avec l’adaptateur sedex et les
applications métier. Ces interfaces doivent également être protégées d’un accès externe, afin de ne pas
corrompre par inadvertance ou intentionnellement l’état du client sM. Il faut toutefois s’assurer que le
client sM ainsi que l’adaptateur sedex ou l’application métier respective possèdent les droits d’accès
nécessaires.
Le client sM utilise également un répertoire interne temporaire. Seuls le sM-Client et les administrateurs
doivent avoir accès à ces répertoires.
sM-Client Queue utilise des fichiers au format binaire pour le stockage des messages JMS. Le répertoire
des messages JMS doit aussi être protégé de toutes modifications accidentelles ou indésirables. Par
défaut ce répertoire est <sm-client-root>/hornetq-2.2.14.Final/data
Protection de l’interface utilisateur
L’interface utilisateur (eb-GUI) est protégé par un login avec nom d’utilisateur et mot de passe. La
communication s’effectue via SSL L’exploitant ne doit pas prendre de mesures de protection particulières.
Protection du backup
Si un backup est réalisé par le client sM, le répertoire respectif, dans lequel le client sM est enregistrés,
doit être protégé de manière adéquate au niveau du répertoire.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
28 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Testbed
5 TESTBED
5.1 Tester avec Testbed
Les deux scénarios, recevoir et envoyer des messages peuvent être simulés ou testés à l’aide du
programme Testbed.
Les résultats respectifs sont indiqués dans le Log de Testbed.
Dans la description suivante on suppose que le programme Testbed ait été installé selon les indications
du manuel d’installation [2] et que les répertoires de l’adaptateur concordent.
5.1.1 Simuler l’expéditeur pour tester la réception
Si le programme Testbed doit simuler un expéditeur pour tester la réception de message, le déroulement
correspond à la figure suivante :
Testbed
Client
Meldung senden()
Protokollquittung pos-neg
sedex receipt pos-neg
Fachliche Quittung neg
sedex receipt pos-neg
Pour envoyer un message, celui-ci est déposé dans le répertoire "tosend" (défini par l’administrateur). Le
message doit être un message sedex complet. Il est envoyé au client à tester par Testbed.
Si le client établit une quittance de rapport, celle-ci sera quittancée par Testbed avec une quittance sedex
et déposée dans le répertoire „received“ (défini par l’administrateur).
Si le client envoie en plus une quittance métier, celle-ci sera également quittancée et déposée dans le
répertoire „received“.
Le processus est alors terminé et les fichiers peuvent être vérifiés dans les répertoires respectifs. Les
informations sur les actions sont indiquées dans le Log.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
29 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Testbed
5.1.2 Simuler le destinataire pour tester l’envoi
Si le programme Testbed doit simuler un destinataire pour tester l’envoi de messages, le déroulement
correspond à la figure suivante :
Testbed
Client
Meldung senden
sedex receipt pos-neg()
Protokollquittung pos-neg()
Fachliche Quittung neg()
Le client doit envoyer un message pour commencer ce processus. Ce message est quittancé avec une
quittance sedex et une quittance de rapport correspondante.
Le message reçu est déposé dans le répertoire „received“ et la quittance de rapport envoyée est déposée
dans le répertoire „receipts“ (défini par l’administrateur).
S’il est nécessaire d’envoyer une confirmation de réception métier, celle-ci peut être déposée dans le
répertoire „tosend“ et sera ensuite transmise au client.
Le processus est alors terminé et les fichiers peuvent être vérifiés dans les répertoires respectifs. Les
informations sur les actions sont indiquées dans le Log.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
30 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
6 ANNEXE
6.1 Liste des messages Log
Les messages Log que l’exploitant souhaite éventuellement surveiller sont répertoriés ici. Les messages
sont classés par module, s’ils sont clairement attribuables. Les erreurs et les messages généraux sous
Général.
Les informations peuvent être utilisées si l’on souhaite visualiser des informations supplémentaires du
Audit Trail. Elles servent uniquement d'information et ne doivent pas être surveillées.
Les avertissements sont là s’il faut vérifier et analyser un petit problème avec le client sM. Les
avertissements ne nécessitent pas d’intervention de l’exploitant en cas normal et servent d’abord à
expliquer les processus qui ne se sont pas déroulés comme prévu.
Les erreurs nécessitent l’intervention de l’exploitant ou du fournisseur. Il existe des descriptions pour les
erreurs connues. Toutes les erreurs désignées dans le Log avec Error doivent également être surveillées.
Lorsque des erreurs inconnues apparaissent, qui ne peuvent être corrigées avec un redémarrage, il est
recommandé de faire appel au fournisseur.
6.1.1 Message Handler
6.1.1.1 Informations
i-0101 | Can't parse message File {messageZipFile}
i-0110 | The process for message with id {messageId} was not found! -- protocol receipt ignored...
i-0111 | The process for message with id {messageId} has already ended! -- cause is probably because
you put in the same message twice
i-0112 | Unable to rename file {fileName}
i-0113 | receipt '{receiptLocation}' is not valid!
i-0114 | receipt '{messageLocation}' is not valid!
i-0115 | could not parse message {messagename} so we could not determine rule leaving it
i-0116 | could not parse the envelope file
i-0117 | generating export pdf in triage for messageid: {messageId}
i-0120 | new message found: '{fileName}'
i-0121 | failing message {messageId} because of error '{error}'
i-0122 | Ignoring message {fileName} because of triage configuration
i-0123 | could not parse message {messageId} due to invalid xml
i-0130 | using repository: {repositoryVersion}
6.1.1.2 Avertissements
w-0101 | This version of the message can no longer be send according to the message_list
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
31 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
w-0102 | This sM-Client is not authorized to send message of type '{type}' subtype '{subtype}' to recipient
'{recipient}''
w-0103 | adapter {thisSedexId} is not allowed to send message with type {type} and subtype {subtype}
w-0110 | unable to read repository version info: {reason}
w-0120 | transformation error: {reason}
6.1.2 Case postale
w-0200 | Unable to print document
w-0201 | Can't export message {messageId}
w-0202 | Unable to export message {messageId}
w-0203 | can't change message {messageId} status,probably was deleted by other users
w-0204 | Message {messageId} was already complete deteled
w-0205 | Can't print message {messageId}
w-0206 | Problem deleting file
w-0207 | Can't print messages
w-0208 | {numberTried} messages was selected to export, but {numberExported} were exported
w-0209 | Unable to move message {messageId}, cause {execptionMessage}
w-0210 | Unable to view message {messageId}
w-0211 | Unable to upload file
w-0213 | Unable to delete message {messageId} may be already was deleted by another user
6.1.3 Service formulaire
6.1.3.1 Informations
i-0301 | isValid(): Mime type not detectable
i-0302 | validateUpload(): File already exists: {fileName}
6.1.3.2 Avertissements
w-0301
|
init():
Could
not
initialize
attachmentFileType={attachmentFileType}
properly:
attachmentType={attachmentType},
6.1.4 Général
6.1.4.1 Informations
i-0405 | could not convert attachment '{attachedFile}'
i-0406 | attachment '{attachedFile}' not found, could not add it to pdf
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
32 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
i-0410 | Saving messages to {backupDir}
i-0411 | backup smclient files done
i-0413 | Restored messages from {location}
i-0414 | Restored files from backup
i-0415 | Database dump finished {exitValue}
i-0420 | Update of file repository successfull for directory {diretoryName}
i-0421 | nothing found in update message for directory {diretoryName}
i-0423 |Handling file repository update message from location {messageLocation} and type {type}
i-0424 |automatic update will be executed at {updateTime}
i-0430 | login failed {execptionMessage}
Le message suivant peut être utilisé pour des raisons de surveillance. Il est affiché au même intervalle
que celui utilisé pour le Polling.
i-0500 | Keep alive for sM-Client version {productVersion}
6.1.4.2 Avertissements
w-0410 | Some records already existed in the message table, were cleaned before restore
w-0420 | could not send feedback message, but update was successful
w-0421 | could not remove update directory, but update was successful
w-0422 | could not perform the update... because of exception '{0}' will try again in an hours time
w-0423 | New update for repository needs to be accepted
w-0430 | could not load version properties, something wrong with this build
w-0431 | unable to read user's roles {execptionMessage}
w-0432 | Unable to read user's language {execptionMessage} {locale} will be used
w-0500: moving message {messageId} to location {failedLocation}
w-0501 | Process for id {processId} not found, JMS Message will be ignored
w-0502 | Process is in state {state} but should be in {state}. JMS message for {messageId} will be ignored
w-0503 | error could not locate global-config.location definition in configuration table. Only one Mandant is
allowed to define this location. Found {numbers of definition} definitions. Will use global defaults
w-0504 | Executor has timed out. This message {processId} will be marked as invalid.
w-0505 | Worker Thread has been stop but JMS Message {id} could not be acknowledged. JMS remains
in the queue but process will be marked as invalid.
6.1.4.3 Erreur
e-0401 | Could not find location '{location}' please check the configuration
Vérifiez la configuration de la banque de données et les fichiers de configuration et redémarrez.
e-0402 | could not find baseDir with found for key '{key}' please check the configuration
Vérifiez la configuration de la banque de données et les fichiers de configuration et redémarrez.
e-0403 | could not find property with name '{locationKey}' please check the configuration
Vérifiez la configuration de la banque de données et les fichiers de configuration et redémarrez.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
33 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
e-0404 | could not find fop xslt document
Vérifiez le stockage si tous les XLS nécessaires pour les messages utilisés y sont, si nécessaire mettez
le stockage à jour.
e-0405 | Can't read configuration file
Vérifiez les fichiers de configuration et redémarrez.
e-0408 | error could not locate formservice.location or config.location file
Vérifiez la configuration/chemins des fichiers de configuration de la banque de données et redémarrez.
e-0409 | Can't load property keep.deleted.time
Vérifiez dans le tableau de configuration de la banque de données si keep.delete.time est présent et que
la valeur est positive et redémarrez.
e-0410 | Can't backup files
Vérifie la configuration du backup dans config.properties, en particulier le dossier indiqué, et redémarrez.
e-0411 | Can't restore files from backup because: {exceptionMessage}
Vérifiez si les fichiers sont présents, éventuellement le message d’erreur pour d’autres informations.
e-0412 | Unable to restore TABLES from files {0} in DB
Vérifiez si les fichiers sont présents.
e-0413 | Can't restore tables from backup because: {exceptionMessage}
Vérifiez si les fichiers sont présents, éventuellement le message d’erreur pour d’autres informations.
e-0414 | Can't restore files from backup
Vérifiez si les fichiers sont présents.
e-0415 | Unable to dump database
Vérifiez la configuration du Full Backup dans config.properties et si les Backup Scripts son corrects.
e-0430 | Can't update session timeout
Vérifiez dans le tableau de configuration de la banque de données si timeout.time est présent et que la
valeur est positive et redémarrez.
e-0500 | Can’t connect to sM-Client Queue
Vérifiez que le processus sM-Client Queue est encore actif. Relancez le si tel n’est pas le cas. Il peut
aussi s’agir d’un problème de configuration
e-0501 | Sending JMS message failed
Vérifiez que le processus sM-Client Queue est encore actif. Relancez le si tel n’est pas le cas. Il peut
aussi s’agir d’un problème de configuration
e-0502 | Could not process event for message {messageId}
Le traitement de l’événement a échoué. Voir le message d’erreur suivant. Le message JMS ne sera pas
traité.
e-0503 | Could not process JMS Message for process instance id: {id}. Will rollback process and JMS
Message again after sM-Client restart.
Relancez le sM-Client
e-0504 | Could not store GroupedMessageAudit for internal message id {id}.
Le traitement du message JMS a échoué. Relancez sM-Client Queue et sM-Client Core pour traiter ce
message à nouveau. Si cette erreur se reproduit, cela indique un problème avec le message sM-Client.
Le timout « Timer » stoppera le processus et le message sM-Client sera marqué comme invalide.
w-504 | Timer {name} has triggered, will stop processing.
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
34 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
L’exécuteur JMS n’a pas pu redémarrer le timer. L’exécuteur sera stoppé et le message sM-Client
marqué comme invalide. Cela peut arriver si l’exécution est bloqué ou si le serveur est surchargé.
6.2 Liste des codes de Statut
(für sM-Client Version 5.0)
StatusCode, StatusMessage
0, message-handler-pickup
1, message-handler-validate message
2, message-handler-pack into sedex format
3, message-handler-sent to adapter
4, message-handler-wait for sedex receipt
5, message-handler-wait for protocolreceipt
6, action not definded
8, message-handler-made positive protocolreceipt
9, message-handler-made negative protocolreceipt
10, message-handler-moved to adapter
11, message-handler-moved to failed to sent
12, message-handler-moved to failed to transmit
13, message-handler-moved to sent
14, message-handler-send process ended
15, message-handler-create protocol receipt
16, message-handler-decision made
17, message-handler-validate receipt
18, message-handler-check sedex receipt
19, message-handler-move to inbox
20, message-handler-move to failed
21, message-handler-moved message
22, managed by triage
23, message-handler-receive process ended
25, message-handler-wait for other recipients subprocess
26, message-handler-check protocol receipt
27, message-handler-check sedex receipt
28, message-handler-for each recipient
29, message-handler-can send message to all recipients
30, message-handler-start send process
31, message-handler-start receive process
32, message-handler-check type of receipt
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
35 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
33, protocol-receipt-needed decision
34, message-handler-should execute script
35, message-handler-start script
36, message-handler-script finished
37, message-handler await validation
38, message-handler sent JMS Message
39, message-handler JMS result received
101, mailbox-export
102, mailbox-print
103, mailbox-delete
104, mailbox-forward
105, mailbox-answered
106, mailbox-restore
107, mailbox-permanently deleted
108, mailbox-resend
201, message-handler-start eschkg receive
203, message-handler-start eschkg send
210, message-handler-unzip
211, message-handler-conversion decision
212, message-handler-convert message
213, message-handler-eschkg send ended
214, message-handler-eschkg receive ended
220, message-handler-start elm receive
221, message-handler-end elm receive
222, message-handler-start elm send
223, message-handler-end elm send
224, message-handler-wait for sda
225, message-handler-determine elm subtype
226, elm-should forward to commune
227, elm-await pdf generation
228, elm-pdf generated
301, message-handler-start ech0058v4 receive
302, message-handler-start ech0058v4 send
310, message-handler-store internal messageIds
311, message-handler-isError decision
312, message-handler-ech0058v4 receive ended
313, message-handler-ech0058v4 send ended
314, message-handler-remove invalid messages
315, message-handler-send back invalid messages
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
36 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
316, message-handler-send back message
6.3
Envoi d’email en cas d’erreur
Exemple de fichier de configuration à utiliser à la place de log.config (voir le manuel
d’installation au chapitre 4.2.4.1. Modifier les éléments surlignés en jaune.
Log4j.xml (http://wiki.apache.org/logging-log4j/Log4jXmlFormat):
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="console" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %c{1} - %m%n"/>
</layout>
</appender>
<appender name="SMTPErrorAppender" class="org.apache.log4j.net.SMTPAppender">
<param name="From" value="error@sM-Client.ch"/>
<param name="To" value="XXXX@yourdomain.ch"/>
<param name="Subject" value="*** sM-Client Error ***" />
<param name="SMTPHost" value="XXXXXXXX" />
<param name="BufferSize" value="1"/>
<param name="Threshold" value="ERROR" />
<layout class="org.apache.log4j.PatternLayout" >
<param name="ConversionPattern" value="Folgender Fehler ist am %d{dd MMM yyyy HH:MM:ss} beim sMClient:%nServer: INWDP088%n--------------%n%m"/>
</layout>
</appender>
<logger name="ch.admin.smclient">
<level value="error"/> <!-- könnte auch „fatal“ sein, jedoch gibt es beim sM-client selber eigentlich keine fatal logs -->
<appender-ref ref=”SMTPErrorAppender” />
</logger>
<logger name="org">
<level value="fatal"/>
<appender-ref ref=”SMTPErrorAppender” />
</logger>
<logger name="com">
<level value="fatal"/>
<appender-ref ref=”SMTPErrorAppender” />
</logger>
<logger name="com.sun.facelets">
<level value="fatal"/>
<appender-ref ref=”SMTPErrorAppender” />
</logger>
<root>
<priority value ="debug" />
<appender-ref ref="console" />
<appender-ref ref="SMTPErrorAppender" />
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
37 / 39
sM-Client Projekt
Version finale
Installations-Handbuch
Annexe
</root>
</log4j:configuration>
Autres points à compléter éventuellement par l’exploitant :
Explications techniques et aperçus
Messages d’erreur (Error List) (y compris causes et mesures de correction)
Incident Log (Liste des incidents)
Problème Log
Change Log
Créé le:
24 octobre 2014
von Cambridge Technology Partners © 2013
38 / 39
Cambridge Technology Partners (Switzerland) S.A.
Nyon
27 Ch. de Précossy
CH-1260 Nyon
Tél:
Fax:
+41 (0)22 306 4646
+41 (0)22 306 4647
Zurich
Office Center 1
Postfach 89
CH-8058 Zürich-Flughafen
Tél:
Fax:
+41 (0)43 456 2300
+41 (0)43 456 2301
Basel
Barfüsserplatz 3
CH-4051 Basel
Tel:
+41 (0) 61 271 9140
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising