Service Déposant

English

Principe de fonctionnement

Le Service Déposant représente notre solution d'envoi automatique du reporting vers les autorités.
Cet outil est compatible avec les principaux systèmes d'exploitation actuels (Windows / Unix / Linux) et est habituellement installé sur un serveur de votre coté.
Avec un mapping réseau approprié, les utilisateurs peuvent ensuite simplement copier le fichier à envoyer dans un répertoire adapté.
Le fichier est alors automatiquement envoyé de manière cryptée.

Installation du service

Un guide de mise à jour simplifié, également applicable à une nouvelle installation, est à votre disposition.
Il décrit, pas à pas, les manipulations à effectuer pour mettre à jour ou en place un tel service.

En complément, pour des informations plus précises sur l'architecture et le principe de fonctionnement de cet outil, nous vous invitons à consulter notre documentation exhaustive à ce sujet.

Vous trouverez également des informations complémentaires et suffisantes à la bonne implémentation et utilisation du service dans les chapitres suivants.

Prérequis

Comme pour le module de cryptage, le Service Déposant nécessite un environnement d'exécution Java supérieur ou égal à 1.6.0_14.
Le service communiquant en continue avec notre serveur, certaines adaptations réseau peuvent également être nécessaires pour autoriser les appel sortant vers www.e-file.lu en HTTP et HTTPS uniquement.

Enfin, un compte utilisateur e-file dédié au service doit être créé et lié aux bon groupes métiers en fonction du reporting souhaité avec un profil SD avec retour.

Paramétrage du fichier properties

Un fichier properties se trouve à la racine du Service Déposant.
Il contient vos paramètres de connexion ainsi que les services à activer et permet de générer les fichiers de configuration lors de l'installation physique.
Ce sont ces derniers qui sont utilisés au démarrage et à l'utilisation du service.
En d'autres termes :

• Il contient toutes les variables nécessaires au fonctionnement du service.
• Toute modification de ce fichier doit être suivie d'une installation pour être prise en compte réellement.

La documentation exhaustive, en page 15, décrit précisemment, champ par champ les besoins de ce fichier. N'hésitez pas à la consulter.
Vous trouverez également, dans les paragraphes suivants, les informations résumées nécessaires au bon paramétrage du fichier organisés par blocs d'informations.

Plus généralement, le principe est de remplacer tous les '????' par vos propres informations.

	e-file.hostname : www.e-file.lu pour la production, ou homologation.e-file.lu pour l'environnement de test. Les autres informations concernent le login et mot de passe de votre utilisateur dédié au Service Déposant ainsi que le nom et mot de passe de votre keystore, connu de tous les utilisateurs.
	proxy.required : up si un proxy doit être utilisé pour sortir du réeau en HTTP et HTTPS. Les autres variables dépendent de votre infrastructure réseau. Toutes ne sont d'ailleurs pas obligatoires. Nous vous invitons à consulter votre équipe réseau pour obtenir ces informations.
	Ces variables permettent d'accepter ou non les retours et accusés de réception des autorités. Nous vous invitons à toujours les mettre à up
	Tous les blocs suivants correspondent à un type de reporting ou de document particulier. L'objectif est donc d'identifier vos besoins et de mettre à up les variables reportingXXXXXX.state nécessaires. Les autres doivent nécessairement être mise à down reportingXXXXXX.remoteDir : Chemin de dépôt des fichiers pour le reporting concerné à destination des utilisateurs. @PROJECT_ROOT_PATH@ : Variable dynamique représentant le chemin d'installation du Service déposant. A modifier si vous souhaitez placer le répertoire de travail utilisateur ailleurs sur le serveur ou une autre machine. Dans ce cas, indiquez le chemin réseau complet vers le fichier. (séparateur = '/') reportingXXXXXX.scheduleTime : Fréquence de d'exécution du Service pour chercher des fichiers à traiter dans le répertoire. (30mn par défaut). N'hésitez pas à réduire cette valeur sans descendre en dessous des 5mn = 300000ms reportingXXXXXX.deeplevel : Profondeur des sous-répertoires à scruter. Par défaut, la variable vaut 0, ce qui signifie que seuls les fichiers présents à la racine du répertoire courant seront pris en compte.
	domain.descr : N'a pas d'importance. Mettre le nom abrégé de votre société par exemple domain.env.ac.id.xxx : Identifiant qui vous a été attribué par la CSSF formatté sur 7 positions, 1 code et 6 chiffres. (exemple : P000999). Les mots de passe et codes d'Authentification vous ont été fournis par courrier officiel de la CSSF lors de votre identification sur le marché Luxembourgeois.
	Système de monitoring du Service Déposant. Si la variable est mise à up, nous serons en mesure de vous prévenir si nous détections un arrêt de votre Service. mon.app.origin : Nom unique et quelconque à nous fournir, sans espaces, qui nous permettra d'identifier votre Service Déposant.

Remarque : Il ne doit plus rester de '?' dans le fichier à la fin du paramétrage

Installation et exécution

L'installation du Service Déposant est simple et rapide. Il suffit de :

• Télécharger ce fichier SD.zip et le dézipper sur un serveur
• Copier votre keystore dans le répertoire 'keystore' du Service déposant.
• Adapter le fichier properties comme expliqué dans le chapitre précédent.
• Installer le service comme précisé en page 5 du manuel de mise à jour.

Une fois l'installation effectuée, il ne vous reste plus qu'à créer le service Windows via le fichier InstallServiceNT.bat automatiquement généré post-installation à la racine du Service Déposant.
Le démarrage du service peut alors se faire via le nouveau service Windows nommé Service Déposant ou par l'intermédiaire du fichier StartServiceNT.bat

Remarque : Dans le cadre d'une installation Unix, il vous suffit d'utiliser les versions de fichiers contenant une extension .sh

Version et mise à jour

Nous sommes en mesure de contrôler la version du programme que vous utilisez car cette information est remontée vers notre base de donnée au démarrage du Service.
De votre coté, le fichier RELEASE_README.txt situé à la racine de l'outil vous informe des différentes maintenances réalisée.
La version courante correspond à la première date du fichier. L'exemple ci dessous correspond à la version du 18/10/2012 :

Dans tous les cas, si une évolution majeure du service a lieu et que cette dernière vous impacte directement, notre procédure interne nous invite à vous prévenir par mail. (par l'intermédiaire de votre Administrateur).

Test de fonctionnement et environnement de test

Il n'y a pas lieu proprement dit de tester le bon fonctionnement de votre service en réalisant un envoi.
En effet, toutes les vérifications d'ordre techniques sont effectuées au démarrage de ce dernier.
En d'autres termes, si le démarrage ne provoque aucune erreur, c'est que le service est fonctionnel.

• Lancer le service via la commande MS-Dos run.bat ou comme à votre habitude depuis le service Windows
• Attendre la fin du démarrage et consulter les logs dans le répertoire log du Service Déposant.
• Si le fichier error.log est vide ou ne contient aucune trace du démarrage, c'est que le service est opérationnel.

Remarque : Si un problème devait survenir après ce contrôle, il serait d'ordre fonctionnel ou lié au paramétrage e-file.
Nous vous invitons dans ce cas à éditer le fichier .err généré lors de la tentative d'envoi.


De plus, vous serez probablement intéressé de pouvoir disposer d'un environnement de test afin de valider le développement de vos fichiers sources ou pour, par exemple, anticiper une migration technique.
Dans ce cas, il suffit de :

• Dupliquer votre service de production en copiant l'intégralité du répertoire Service Déposant à un autre emplacement.
• Adapter le fichier properties pour qu'il pointe vers notre environnement de test, l'Homologation. e-file.hostname = homologation.e-file.lu
  A noter que si le login de connexion reste identique dans ces deux environnements, le mot de passe change pour prendre la valeur fixe formation dans l'environnement de test.
  N'oubliez pas également de modifier les chemins vers les différents reportings si ces derniers étaient spécifiques.
  Pour finir, afin de différencier les 2 services Windows, nous vous invitons également à adapter les variables responsables du nom du service : wrapper.app.long.name et wrapper.app.name

• Refaire l'installation du service

Déroulement d'un envoi et suivi

A l'exception du mode semi automatique abordé dans la section consacrée à la Station Finesti, le principe de base lié au service déposant est toujours le même.

Pour un fichier source nomFichier.ext par exemple :

1. Le fichier source est renommé en .trt après prise en charge => nomFichier.ext_YYYYMMDDhhmmssmmm.trt
2. Un fichier .acq est créé comme preuve de bon envoi dans le même répertoire --> nomFichier.ext_YYYYMMDDhhmmssmmm.acq
3. En cas d'erreur c'est un fichier .err qui est obtenu --> nomFichier.ext_YYYYMMDDhhmmssmmm.err.
   Nous vous invitons dans ce cas à éditer ce fichier avec un éditeur de texte standard afin de comprendre l'origine du problème.

Les autorités peuvent ensuite vous envoyer des retours ou des acquittements de réception :

• Reporting FINESTI = Ox.x + Sx.xx + TPT = Réception d'un fichier ack comme preuve de bonne réception => nomFichier.ext_YYYYMMDDhhmmssmmm.ack
  Ceci vient en complément de l'acq qui est la preuve d'envoi uniquement.
  

• Reporting CSSF listé dans ce document = Réception d'un feedback technique de bonne réception = FBR et parfois, en complément, un FDB = Feedback métier dans le cadre d'un retour de prospectus visé par exemple.
  Ces feedbacks sont créés dans un sous répertoire Replies du Service déposant.
  Vous trouverez des explications exhaustive sur ce procéssus dans la documentation CSSF.
  

• Pour le reste du reporting (08/371 / VNI...), aucun système d'acquittement n'est mis en place.
  Ceci signifie que seul un fichier acq sera généré.
  
  

En conclusion : S'assurer de la bonne création d'une paire trt + acq est un bon moyen de s'assurer du bon fonctionnement du service déposant. De cette manière, vous certifiez avoir correctement envoyé vos données, et il nous revient de les acheminer correctement aux autorités.

Remarque : Tout envoi implique d'office la création d'une procédure visible depuis www.e-file.lu en utilisant la recherche avancée.

Processus d'automatisation des envois de packages

Dans le cadre des mises à jour de KIID vers la CSSF, il est possible de mettre en place l'envoi automatique des packages de KIIDs depuis notre serveur vers le Service Déposant. Une fois que le Service Déposant à récupéré les KIIDs a envoyer, ils sont placés dans le répertoire :

\ReportingDiffusion\DOC_FIS_OPC\KID_OPC

Et sont envoyés à la CSSF par le processus de traitement habituel.

Pour bénéficier de cette fonctionnalité :

• Il est nécessaire de disposer d'une version du Service Déposant supérieure ou égale à celle du 18/03/2013. Voir installation du service
• Il faut ensuite en faire la demande au service CRM (un paramétrage spécifique est à mettre en place) : nous contacter
• Enfin, le package doit être initié par l'application de gestion des documents UCITS IV https://www.e-file.lu/e-file ou dans certains cas par un processus automatique sur nos serveurs

Problèmes les plus fréquents

Le service ne démarre pas

Si, lors du lancement du service déposant via les services Windows, ce dernier ne démarre pas, nous vous invitons à analyser l'origine du problème selon ce protocole.

Faire une tentative de démarrage MS-Dos

• Ouvrir une fenêtre MS-DOS en prennant soin d'être logué en tant qu'administrateur de la machine (Start>run : cmd)
• Vous placer dans le répertoire d'installation du Service Déposant
• Exécuter la commande run.bat

Si le service démarre correctement via cette commande MS-DOS, sans générer de log d'erreur, nous vous invitons à suivre cette méthode de résolution.
Sinon, une analyse des logs est nécessaire

Analyse des logs

Dans le répertoire log, à la racine du Service Déposant, un fichier error.log contient la trace d'erreur à l'origine de ce dysfonctionnement.

Vous trouverez ci dessous les problèmes connus les plus fréquents.

Dans tous les cas, nous sommes à votre disposition pour vous assister dans cette analyse. En cas de problème, nous vous invitons à envoyer vos logs d'erreur par mail au service SDI

Problème réseau

Erreur 1 : Error when webservice's call 'obtenirVersionsDocument'.Unrecognized SSL message, plaintext connection.

Méthode de résolution

• Vérifier les paramètres proxy entrés dans votre fichier properties
• Refaire l'installation du Service Déposant pour prendre en compte ce changement.
  
  

Erreur 2 : java.net.ConnectException: Connection timed out: connect.
Erreur 3 : Connection timed out: connect [TIP: The machine can be unauthorized by the proxy]]

Méthode de résolution

• Vérifier le paramétrage de votre proxy avec votre équipe réseau.
  

Ce dernier doit être correctement configureé pour autoriser les connexions sortantes de votre serveur vers www.e-file.lu en HTTP et HTTPS.

Autre problème de time out

Erreur : Startup failed: Timed out waiting for signal from JVM.

Méthode de résolution

• Augmenter la valeur de la variable wrapper.startup.timeout dans votre fichier properties.
  La passer par exemple de 300 à 600.
• Refaire l'installation du Service Déposant pour prendre en compte ce changement.

En effet, ce paramètre indique en secondes, le temps alloué au démarrage du Service. 5 min n'est parfois pas suffisant lorsqu'il y a des proxy qui ralentissent les connexions avec e-file par exemple.

Problème de droits administrateur avec le service Windows

L'exécution d'un service windows se fait par défaut par un user system non administrateur.
Selon votre architecture, il est possible que ce user manque de droits pour assurer le bon démarrage du Service Déposant. (problème au niveau du proxy par exemple).
Il suffit alors de changer ce paramètre d'exécution de cette manière :

Méthode de résolution

• Accéder à l'écran des services Windows. (Menu Démarrer > Panneau de configuration > Outils d'administration > Services)
• Faire un clic droit sur le service nommé ServiceDéposant
• Choisir l'item Propriétés
• Depuis l'onglet LogOn indiquer un user / mot de passe administrateur.
• Relancer le service pour valider la bonne configuration

Les fichiers tombent en erreur à l'envoi

Lors du traitement de vos rapports, l'apparition d'un fichier .err est le signe d'un problème à l'envoi.
Dans ce cas, il est nécessaire d'analyser l'origine du problème car les données n'ont pas pu être transmises aux autorités.

Ce fichier .err contient l'explication de l'erreur à l'origine de ce dysfonctionnement.

Vous trouverez ci dessous les problèmes connus les plus fréquents.
Dans tous les cas, nous sommes à votre disposition pour vous assister dans cette analyse. En cas de problème, nous vous invitons à envoyer vos deux fichiers .trt et .err par mail au service SDI

Problème fonctionnel

Erreur 1 : Failed to validate XML
Erreur 2 : Toute erreur pointant un problème de donnée

Méthode de résolution

• Corriger le fichier en agissant sur les données en erreur listés dans le .err
• Refaire l'envoi.
  
  

Problème lié à l'utilisateur

Erreur 1 : Getting addressees information Une erreur est survenue lors de l'execution du Workflow

Méthode de résolution

• Lier le user utilisé par le Service Déposant au bon groupe correspondant au reporting que vous cherchez à envoyer. Son profil doit être SD avec retour