SMIRK APP1103, l'application SEPAmail
Cette demande de commentaires (SMIRK) spécifie la structuration spécifique d'un dialogue de messages SEPAmail (SMIRK MES1102[1]) : l'application SEPAmail.
Introduction
L'application SEPAmail permet de définir quelles sont les séquences possibles d'un dialogue autour d'une fonctionnalité métier définie.
Pour cela, SEPAmail définit une application comme :
- un ensemble de messages SEPAmail,
- des séquences possibles et définies de dialogue,
- une liste d'états possibles du dialogue initié,
- un ensemble de règles de gestion à implémenter pour permettre la transition d'états pour chacun des dialogues.
Les principes
La fonctionnalité métier
C'est une fonctionnalité métier bancaire, interne ou tierce qui justifie la création d'une application SEPAmail.
Cette fonctionnalité induit la création d'un dialogue plus ou moins complexe entre les parties.
Le nommage de la famille
Les applications SEPAmail prennent le nom de pierres précieuses ou semi-précieuses.
Si possible, ce nom sert d'acronyme pour définir la fonctionnalité métier en anglais.
Le « E » final, lorsqu'il est présent, devrait signifier Exchange.
Les messages
Le message est obligatoirement conforme à la SMIRK MES1102.
Le dialogue
Un dialogue est constitué d'une séquence finie de messages parmi les messages définis de l'application.
Un dialogue est initié dans SEPAmail par l'émission d'un premier message.
Dans la plupart des cas, il se termine lors de la réponse à ce premier message.
En effet, la plupart des échanges structurés d'information met en jeu :
- deux utilisateurs, l'émetteur du premier message et son destinataire,
- une question et une unique réponse.
Cependant, des cas plus complexes permettent plus de deux utilisateurs et plus de deux messages. Le dialogue se termine lorsque la date de péremption de chacun des messages le constituant est dépassée ou qu'aucune réponse n'est possible.
Remarque : Il n'y a actuellement pas de limite au nombre possible de messages dans un échange.
La vue statutaire de l'application
Il y a des messages qui :
- peuvent initier le dialogue
- peuvent terminer le dialogue
- ne peuvent pas initier le dialogue
- doivent succéder à un autre message.
L'application SEPAmail peut donc être vu comme un ensemble de transitions possibles entre un ensemble de messages (qui seraient alors considérés comme les états de l'application), avec un état « start » et un état « end ».
Remarque : Dans l'état actuel de cette SMIRK, l'annulation et la péremption des messages ne sont pas envisagées, bien que les structures de données nécessaires soient en place.
L'utilisateur de l'application
Le dialogue entre deux utilisateur est possible si :
- les deux utilisateurs sont actifs pour cette application
- les deux utilisateurs sont « connectés ».
On dit que deux utilisateurs sont connectés s'ils ont chacun émis et reçu un message (autorisé pour l'application) de l'autre utilisateur.
Sinon, il sont déconnectés.
L'état connecté est indéfini ; il revient à « déconnecté » dans les cas suivants :
- un des deux utilisateurs demandent la déconnexion,
- un des deux utilisateurs n'est plus actif pour cette application,
- un des relais de messagerie (les adhérents SEPAmail) fait une requête de déconnexion des deux utilisateurs.
Le contenu
Une application est définie par :
- un nom,
- un objectif d'échange bancaire d'information,
- un ensemble de messages SEPAmail,
- un ensemble de transitions possibles entre les messages considérés comme des états avec les deux états « start » (pas de transition vers l'état « start ») et « end » (pas de transition depuis l'état « end »),
- un ensemble d'utilisateurs de l'application, dont le profil permet ou non l'émission ou la réception de message.
Application au cœur de l'architecture de SEPAmail
L'application traite des messages qu'elle récupère généralement d'une implémentation logicielle de SMART via une API, comme décrit dans le schéma ci-dessous.
