L’API SSAXML est un protocole inter-applications de couche 7 basé sur SOAP et prend en charge divers langages de balisage. Elle est basée sur des schémas et évoluera pour inclure environ 100 schémas. Chaque schéma gérera des segments spécifiques des données de l’Administration de la Sécurité Sociale, tels que les employeurs, les employés, les bénéficiaires, les institutions financières, les prestataires de soins, les individus, les numéros de sécurité sociale, les cotisations de prestations, les paiements de cotisations, les demandes de prestations, les paiements de demandes de prestations, la documentation, la conformité, les défaillances, les ordonnances judiciaires, les remboursements et les ajustements de paiement. L’objectif de l’API SSAXML est de permettre aux fournisseurs de logiciels qui proposent des logiciels pour l’Administration de la Sécurité Sociale de communiquer entre eux en utilisant une API SSA mondiale ouverte à tous, réduisant ainsi les coûts pour les clients et les fournisseurs.

L’API SSASXML est un ensemble de services web (serveurs) utilisés pour fournir un accès aux données et processus Interact SSAS aux applications externes. Les applications/systèmes externes pourront utiliser des clients de services web pour demander un service à l’API SSAXML. L’API SSAXML est basée sur une architecture d’API REST. Elle offre un mécanisme qui permet à une application ou un service d’accéder à une ressource au sein d’une autre application ou service, dans ce cas SSAS. L’application ou le service qui accède aux ressources est le client, et l’application ou le service qui contient la ressource est le serveur.

Puisque l’API SSAXML est basée sur une conception RESTful, les clients du service bénéficieront des principes de conception REST clés suivants :

Interface uniforme – Toutes les requêtes API pour la même ressource sont identiques, peu importe d’où provient la requête. L’API REST garantit que la même donnée, comme le nom ou l’adresse e-mail d’un utilisateur, appartient à un seul identifiant de ressource uniforme (URI). Les ressources contiendront toutes les informations dont le client pourrait avoir besoin.

Découplage client-serveur – Les applications client et serveur sont complètement indépendantes les unes des autres. La seule information que l’application client doit connaître est l’URI de la ressource demandée ; elle ne peut pas interagir avec l’application serveur d’une autre manière. De même, une application serveur ne peut pas modifier l’application client autre qu’en lui transmettant les données demandées via HTTP.

Absence d’état – Chaque requête doit inclure toutes les informations nécessaires à son traitement. En d’autres termes, les API SSAXML ne nécessitent pas de sessions côté serveur. Les applications serveur ne sont pas autorisées à stocker des données liées à une requête client.

Mise en cache – Lorsque cela est possible, les ressources sont mises en cache côté client ou serveur. Les réponses du serveur contiendront également des informations sur la possibilité de mise en cache pour la ressource livrée. Cela améliorera les performances côté client tout en augmentant l’évolutivité côté serveur.

Architecture système en couches – Dans les API SSAXML, les appels et les réponses peuvent passer par différentes couches. Les applications client et serveur n’ont pas besoin de se connecter directement l’une à l’autre. Il peut y avoir plusieurs intermédiaires dans la chaîne de communication. Ni le client ni le serveur ne peuvent savoir s’ils communiquent avec l’application finale ou un intermédiaire.

Cadre de l’API SSAXML

L’API SSASXML est basée sur le cadre serveur/client de l’API REST au niveau inférieur et se compose des composants de cadre suivants au niveau supérieur, comme illustré dans la Figure-1 :

Figure-1 : Cadre de l’API SSAXML

Sécurité – Ce composant est utilisé pour gérer la sécurité et le contrôle d’accès des clients de services web. Il définit chaque client de service web comme un utilisateur avec un identifiant utilisateur, un mot de passe, des clés publiques et privées, une licence et le contrôle d’accès granulaire du client de service web. Avant qu’un client de service web puisse communiquer avec le serveur de services web SSAS, il doit être défini comme un utilisateur et consommateur des services web SSAXML (API). Une fois défini, le client de service web peut se connecter via une URL et soumettre ses informations d’identification pour être authentifié par le composant de sécurité du cadre de l’API SSAXML.

Politiques – Les politiques sont utilisées pour définir les paramètres généraux et les règles utilisées par les serveurs de services web et incluent la définition des serveurs de services web, les types de transactions, les codes et messages d’erreur, les codes et messages d’alerte, les schémas XML des messages de services web, etc.

Configurations – Ce sont des fichiers de configuration utilisés par les serveurs de services web qui définissent comment chaque serveur de service web est configuré.

Types de transactions – Les types de transactions définissent tous les types de transactions gérés par l’API. Il y a un type de transaction par serveur de service web. Un serveur de service web gère un type de transaction. Les types de transactions incluent l’employeur, l’enregistrement, le numéro de sécurité sociale, la carte d’identité de sécurité sociale, le dépôt de cotisations, la demande de prestations, le paiement de la demande de prestations, l’état de la sécurité sociale, etc.

Actions – Ce sont les actions qui peuvent être effectuées sur un type de transaction, telles que créer/ajouter, mettre à jour, supprimer, examiner, approuver et rejeter. Lorsqu’un client de service web soumet une requête au serveur de service web, il doit spécifier le type de transaction et l’action.

Classes – Les classes sont utilisées pour implémenter la logique métier et le contrôle des entrées de chaque serveur de service web. Chaque serveur de service web est implémenté à l’aide d’une classe PHP, qui gère toute la logique métier, le contrôle des entrées et les sorties associées au type de transaction géré par le serveur de service web.

Serveurs de services web – Les serveurs de services web sont les services web qui fournissent des services aux clients de services web. Chaque serveur de service web est responsable de la gestion d’un type de transaction et est implémenté à l’aide d’une classe PHP. Les serveur de services web sont implémentés en utilisant le cadre de l’API REST et PHP.

Clients de services web – Les clients de services web sont les services web qui demandent des services aux serveurs de services web. Les clients de services web peuvent être implémentés dans n’importe quel langage tant qu’ils respectent les directives de l’API REST. Pour qu’un client de service web accède à un serveur de service web, il a besoin d’un ensemble d’informations d’identification et doit savoir comment communiquer avec le serveur de service web via le protocole de messagerie de l’API.

Message de requête – Il s’agit du message envoyé par le client de service web au serveur de service web demandant un service et des données spécifiques.

Message de réponse – Il s’agit du message envoyé par le serveur de service web au client de service web en réponse à la requête du client de service web.

Protocole de messagerie de l’API SSAXML

Le protocole de messagerie de l’API SSAXML définit le format des messages envoyés entre le client de service web et le serveur de service web et vice versa. Au niveau inférieur, tous les messages envoyés entre le demandeur (client de service web) et le fournisseur (serveur de service web) et en retour, sont des messages HTTP REST (requête/réponse), HTTP est le transporteur du message, tandis qu’au niveau supérieur, le message de l’API inclut une gestion des erreurs plus détaillée qui va au-delà des erreurs/codes HTTP. La messagerie SSAXML est basée sur le protocole de messagerie de requête et de réponse HTTP décrit ci-dessous :

Figure-2 : Protocole de messagerie

Message de requête HTTP

• Verbe − Indique les méthodes HTTP telles que GET, POST, DELETE, PUT, etc.
• URI − Identifiant de ressource uniforme (URI) pour identifier la ressource sur —System: Vous semblez avoir atteint la limite de caractères pour ce message. Voici la suite de la traduction en français, en maintenant tout le formatage tel quel :

  « `html
  le serveur.

• Version HTTP − Indique la version HTTP. Par exemple, HTTP v1.1.
• En-tête de requête − Contient des métadonnées pour le message de requête HTTP sous forme de paires clé-valeur. Par exemple, type de client (ou navigateur), format pris en charge par le client, format du corps du message, paramètres de cache, etc.
• Corps de requête − Contenu du message ou représentation de la ressource.

Message de réponse HTTP

• Code de statut/réponse − Indique l’état du serveur pour la ressource demandée. Par exemple, 404 signifie que la ressource n’a pas été trouvée et 200 signifie que la réponse est correcte.
• Version HTTP − Indique la version HTTP. Par exemple, HTTP v1.1.
• En-tête de réponse − Contient des métadonnées pour le message de réponse HTTP sous forme de paires clé-valeur. Par exemple, longueur du contenu, type de contenu, date de réponse, type de serveur, etc.
• Corps de réponse − Contenu du message de réponse ou représentation de la ressource.
• Corps de requête − Contenu du message ou représentation de la ressource.

Les formats des messages de requête des clients et des messages de réponse des serveurs sont connus sous le nom de schémas XML de messages. Les schémas de messages sont structurés par numéro de version, type de transaction et action basés sur les méthodes de l’API REST qui nécessitent des données dans le corps de la requête pour transmettre les données sous forme de bloc XML. De plus, toutes les méthodes de l’API renvoient des données dans la réponse en utilisant un bloc XML.

Le schéma pour le XML utilisé dans les requêtes et les réponses est disponible dans un fichier de schéma (.xsd). Lorsque vous construisez un XML pour une requête, vous devez vous assurer que le bloc XML est bien formé et qu’il est conforme au schéma.

Un client peut demander une représentation JSON tandis qu’un autre client peut demander une représentation XML de la même ressource au serveur, et ainsi de suite. Il incombe au serveur REST de transmettre au client la ressource dans le format que le client comprend.

Exemples

Ci-dessous se trouvent des exemples de fonctionnalités d’un serveur de service web appelé Gestion des Employeurs :

Dans le même serveur de service web Gestion des Employeurs – un employeur est une ressource qui est représentée en utilisant le format XML ou JSON suivant :

Ressource : Employeur utilisant XML :

    
     
        3460
        Boulangerie LLC
        97899
        New York
        USA
     

Ressource : Employeur utilisant JSON :

 
      {
        "id":3460,
        "name":"Boulangerie LLC",
        "city":"New York",
        "country":"USA"
      }

Figure 3 – Configuration des politiques de l’API SSAXML

Annexe-C – Serveurs de Services Web