d'avancement de la validation concernant le dossier qu'il a dйposй. 4. Rйcupйration (modиle simpliste) : Aprиs signature, l'agent peut commander а la plate-forme mйtier de tйlйcharger le dossier signй, et purger ensuite le dossier. Remarque : suite au tйlйchargement, l'effacement du dossier est une opйration nйcessaire. Une interface qui ne rйalise pas ces opйrations de nettoyage est rйputйe incomplиte. Cette lacune fonctionnelle impose alors а l'exploitant de mettre en place des contre-mesures palliatives: il s'agira de contenir la toxicitй de l'accumulation de dossiers rejetйs non-purgйs ainsi que les dossiers en fin-de-circuit non purgйs. 1.3.
Modalitйs de dialogue Dans le cadre prйsent, l'application mйtier est un PUR client de i-Parapheur, lequel propose un ensemble de services web (contrat de Web- Service SOAP) – plutфt qu'une classique API – а l'application mйtier. Les Web-Services de i-Parapheur adressent tous types de flux normalisйs, notamment: PESv2, ACTES... Dans une optique de chaone globale dйmatйrialisйe, il convient que l'application productrice soit pleinement pilote du cycle de vie du dossier. Ainsi l'architecture fonctionnelle fonctionnerait idйalement sur le principe ci-aprиs : 1. L'application mйtier produit les йlйments constitutifs du dossier :
piиce(s) principale(s) (document signable), mйta-donnйes, annexe(s) 2. Elle dйpose par Web-Service ces йlйments dans i-Parapheur pour visa/signature, puis peut suivre а son grй l'йtat d'avancement du dossier (exemple : prйsentation en tableau de bord dans l'application mйtier). 3. Aprиs signature (en fin de circuit), elle rйcupиre le dossier signй et en assure l'exploitation (TDT, etc) 4. Enfin elle stocke le dossier et mйta-donnйes de diffusion (Accusй de rйception par le destinataire, par exemple) de faзon pйrenne : versement en GED ou autre (S.A.E., …). 1.3.1. Contrat WEB-SERVICES SOAP SOAP est un protocole, pas un pattern d'architecture logicielle.
A ce titre, c'est un standard officiel W3C, indйpendant de la plateforme ou du langage d'implйmentation. Les services exposйs sont dйfinis selon un « contrat » WSDL . L'application mйtier respectant ce contrat reste libre de son choix technologique d'implйmentation (liste non exhaustive de langages et frameworks de dйveloppement reconnus compatibles): JAVA via JAXWS, C++ via gSOAP, PHP via WSO2-WSF ou autre framework, Ruby, Python (voir par exemple la librairie 'iparapheur-utils' publiйe sur pipy.org), Microsoft™ .NET™, NatStar™ NSDK, WinDev™ Remarque : il est а noter que peu d'exemples d'implйmentation sont rendus publics, encore moins open-source.
Les mentions ci-dessus sont prйsentйes а fins purement informatives. Il s'agit de retours d'expйrience d'йditeurs ou d'intйgrateurs tiers qui ne partagent pas forcйment les valeurs de collaboration inhйrentes au logiciel libre. Ainsi, il n'y a pas ou trиs peu d'exemple de code source avec ces langages de programmation. 1.3.2. Modиle d'implйmentation dйprйciй Le serveur i-Parapheur disposant йgalement de connecteurs vers le tiers de tйlй-transmission SІLOW (notamment), l'application mйtier pouvait кtre tentйe de piloter l'envoi de dossier en prйfecture ou en paierie, sans ressentir le besoin d'implйmenter l'API de SІLOW par exemple.
Sur ce modиle particulier, l'application mйtier ne « voyait » que i-Parapheur, et bйnйficiait par simple paramйtrage des circuits et connecteurs disponibles (SІLOW/ACTES et SІLOW/HELIOS). Ce n'est plus possible. L'application i-Parapheur n'est plus un relais vers les opйrateurs ACTES ou HELIOS. 1.4. Architecture logicielle serveur Manuel de spйcifications web-services SOAP i-Parapheur - Version 4.x page 7 / 25