L’utilisateur se connecte à JURIS via un navigateur web (client léger). Mais avant d’accéder à la page d'acceuil, il passe généralement par une page publique. Les requêtes de connexion sont alors envoyées au serveur web, qui les transmet au serveur de base de données. Ce dernier vérifie la validité des informations de connexion (y compris la vérification de la clé d'activation), puis renvoie une réponse au serveur web qui la traduit pour affiché la page finale sur le navigateur du client. Ce même principe, on le retrouve sur toutes les actions enclenchées au niveau de l'application.
Avant d'afficher à la fin la réponse dans le navigateur du client.

Les données utilisées par JURIS sont extraites à partir des systèmes d'informations de différents institutions financières (Corebanking, base de données, etc.). Généralement, on trouve :

Juris est caractérisé par une architecture sous forme de composants qui communiquent entre eux au travers des connexions et des flux de fichiers. Parmi ces composants, on trouve : les conteneurs (Celery, Redis, MetaBase ainsi le cors JURIS), la base des données (Oracle DB dans ce cas), le CoreBanking (Amplitude) et l'IHM dont le rôle d'interagir avec les utilisateurs et activer en conséquence les traitements souhaités.

Les composants JURIS :
Les composants propres à JURIS sont les conteneurs : Cors1 juris, Redis, Celery ainsi que le conteneur de l'application JURIS. La communication entre ces composants se fait via le docker network qui crée des ponts avec des Ips interne associés à chaque container et qui est défini dans docker compose. Cependant les autres conteneurs sont paramétrés manuellement au niveau du docker network.

La figure ci-dessus décrit aussi bien la communication entre les différents composants que le traitement asynchrone (en arrière-plan) de JURIS (par exemple les notifications).
Les Statistiques :
Le composant statistique (metaBase) est connecté avec JURIS par des URLs. La connexion est assurée par un accès direct à la base des données en mode lecture, et ce, afin de récupérer les données via des requêtes sql avant d'être transformées sous forme de dashboards.

L'interface In :
JURIS dispose d'une interface IN qui permet de charger manuellement les données issues du CoreBanking sous format xlsx et csv. L'objectif est d'alimenter le moteur de déclassement de JURIS avec les données nécessaires pour ses propres traitements notamment le calcul des risques, le calcul des provisions, etc. Il est à noter que cette interface exécutent en amont un ensemble de programmes qui font appel aux différents règles et paramétrages prédéfinis avant d'envoyer les données au moteur de déclassement.

Déclassement :
Le composant "Déclassement" est à l'origine du traitement de classification dont l'objectif est de calculer principalement les risques des clients et les provisions. Celui-ci récupère les données insérées au niveau de la base moyennant l'interface IN. Ensuite, il génère un fichier sous format Excel après l'aboutissement des différents programmes de calcul. Ce même fichier est réinjecté dans JURIS après sa vérification et éventuellement sa mise à jour par la ligne métier.

L'interface Out :
Après le processus de déclassement, JURIS génère via son interface de sortie des fichiers (sous format xml et txt) qui sont chargés ensuite par des programmes propres au CoreBanking (Amplitude), et ce, afin d'alimenter ce dernier avec les données issues du traitement de déclassement notamment le code qualité client, opposition de compte client, etc.

Recouvrement :

1- Cors juris: Conteneur du code regroupant toutes les fonctionnalités nécessaires pour les différents traitements de JURIS.