Mise à jour

Ce contenu a été traduit par une intelligence artificielle. Si vous repérez une erreur, merci de nous le signaler pour nous aider à améliorer notre support. En cas de doute, la version originale en anglais fait foi.

La mise à jour de l'application (Application Update) est une opération administrative cruciale qui permet au système de caisse (POS) de déclencher manuellement la synchronisation du terminal de paiement (POI) avec le serveur NTMS (Nexo Terminal Management System). Cette fonction garantit que le parc de terminaux reste à jour et offre des capacités de diagnostic.

1. Fonctions et capacités

L'objectif principal de la mise à jour est de forcer le terminal à établir une connexion avec le système de gestion centralisé pour effectuer les tâches administratives nécessaires.

• Mécanisme de déclenchement : Le POS envoie la requête au POI, qui se connecte ensuite de manière autonome au NTMS.

• Capacités principales :

  • Mise à jour de la configuration : Télécharge et applique les derniers réglages et paramètres du terminal.

  • Mise à jour de l'application : Installe les nouvelles versions du logiciel de l'application de paiement.

  • Gestion des journaux (Logs) : Transmet les journaux de l'application et du système d'exploitation du terminal pour permettre un diagnostic et un dépannage à distance.

2. Pourquoi la mise à jour déclenchée par le POS est intéressante

Le point de terminaison (endpoint) Update est un mécanisme essentiel pour la gestion proactive des terminaux, bien que ces derniers gèrent généralement leurs mises à jour de manière autonome.

En temps normal, les terminaux sont configurés pour se connecter automatiquement au serveur NTMS durant la nuit afin d'effectuer la maintenance de routine (téléchargement de configurations, installation de correctifs, envoi de journaux de diagnostic). Cependant, la fonction de mise à jour manuelle devient indispensable pour les besoins opérationnels immédiats et la réduction des risques :

• Forcer une synchronisation immédiate : Si un changement de configuration critique est déployé en journée, le POS peut déclencher une mise à jour pour contourner le calendrier nocturne, garantissant que le terminal utilise les derniers paramètres instantanément.

• Réponse instantanée aux incidents : Cette opération offre un moyen vital, non manuel, de forcer la transmission des journaux applicatifs et système au NTMS en cas de problème. Cela permet aux équipes de support de diagnostiquer les dysfonctionnements à distance sans intervention physique du caissier ou du personnel du magasin.

• Pallier les échecs nocturnes : La mise à jour manuelle est cruciale si le terminal était éteint ou privé de connexion internet durant la nuit. Dans ce cas, le terminal aurait manqué sa fenêtre de maintenance programmée ; la capacité de forcer une connexion depuis le POS est alors nécessaire pour garantir la conformité et l'actualisation du terminal.

3. Charge utile (Payload) et structure requises

La requête Update est une opération synchrone (SYNC) qui utilise la structure de message générique AdminRequest.

A. Requête de mise à jour (Update Request)

En-tête (Header) L'objet standard SaleToPOIRequest.MessageHeader, avec le champ MessageClass défini sur Service et MessageCategory sur Admin.

Corps (Body) Le seul champ requis est la chaîne encodée en Base64 dans AdminRequest.ServiceIdentification. Cette chaîne contient la commande XML réelle transmise au noyau (kernel) du terminal.

• Decoded Content: PFJlcXVlc3Q+CiAgICA8QWN0aW9uPlVwZGF0ZTwvQWN0aW9uPgogICAgPFRpbWVvdXQ+NTAwMDwvVGltZW91dD4KPC9SZXF1ZXN0Pgo= decodes to XML:

  <Request>
     <Action>Update</Action>
     <Timeout>5000</Timeout>
  </Request>

• Objectif : Cela confirme que la requête déclenche l'action de mise à jour (Update) avec un délai d'attente (timeout) spécifié (5000 millisecondes dans cet exemple).

{
  "MessageHeader": {
    "MessageClass": "Service",
    "MessageCategory": "Admin",
    "MessageType": "Request",
    "ServiceID": "823",
    "SaleID": "POS_01",
    "POIID": "POI_01"
  },
  "AdminRequest": {
    "ServiceIdentification": "PFJlcXVlc3Q+CiAgICA8QWN0aW9uPlVwZGF0ZTwvQWN0aW9uPgogICAgPFRpbWVvdXQ+NTAwMDwvVGltZW91dD4KPC9SZXF1ZXN0Pgo="
  }
}

<?xml version="3.1" encoding="UTF-8"?>
<SaleToPOIRequest xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<MessageHeader MessageClass="Service" MessageCategory="Admin" MessageType="Request" ServiceID="3916" SaleID="ECR001" POIID="456"></MessageHeader>
	<AdminRequest>
		<ServiceIdentification>PFJlcXVlc3Q+CiAgICA8QWN0aW9uPlVwZGF0ZTwvQWN0aW9uPgogICAgPFRpbWVvdXQ+NTAwMDwvVGltZW91dD4KPC9SZXF1ZXN0Pgo=</ServiceIdentification>
	</AdminRequest>
</SaleToPOIRequest>

Voici la traduction française de la réponse de mise à jour :

B. Réponse de mise à jour (Update Response)

Le corps de la réponse de mise à jour confirme l'exécution réussie de l'opération via l'objet Response :

• Result : Le résultat « Success » indique que le terminal a accepté la commande et a commencé l'opération demandée.

• AdditionalResponse (XML Base64) : Ce message encodé confirme l'action interne qui a été démarrée. Il se décode ainsi : <Response><Action>Update</Action><Success>true</Success></Response>. Cela signifie simplement que la commande pour déclencher la mise à jour du logiciel ou de la configuration du terminal a été lancée avec succès.

{
  "SaleToPOIResponse": {
    "AdminResponse": {
      "Response": {
        "Result": "Success",
        "AdditionalResponse": "PFJlc3BvbnNlPgogICA8QWN0aW9uPlVwZGF0ZTwvQWN0aW9uPgogICA8U3VjY2Vzcz50cnVlPC9TdWNjZXNzPgo8L1Jlc3BvbnNlPg=="
      }
    },
    "MessageHeader": {
      "MessageCategory": "Admin",
      "MessageClass": "Service",
      "MessageType": "Response",
      "POIID": "POI_01",
      "ProtocolVersion": "3.1",
      "SaleID": "POS_01",
      "ServiceID": "3916"
    }
  }
}

<SaleToPOIResponse>
   <AdminResponse>
      <Response Result="Success">
         <AdditionalResponse>PFJlc3BvbnNlPgogICA8QWN0aW9uPlVwZGF0ZTwvQWN0aW9uPgogICA8U3VjY2Vzcz50cnVlPC9TdWNjZXNzPgo8L1Jlc3BvbnNlPg==</AdditionalResponse>
      </Response>
   </AdminResponse>
   <MessageHeader MessageCategory="Admin" MessageClass="Service" MessageType="Response" POIID="POI_01" ProtocolVersion="3.1" SaleID="POS_01" ServiceID="3916"/>
</SaleToPOIResponse>

Notification d'événement (EventNotification)

Lorsqu'une requête de connexion (Login Request) échoue, le terminal de paiement (POI) répond par un message spécialisé EventNotification, signalant que le message a été rejeté ou n'a pas pu être traité. Il s'agit généralement de la méthode utilisée par le terminal pour communiquer immédiatement au système de caisse (POS) une erreur structurelle ou d'analyse (parsing) irrécupérable.

Le MessageHeader que vous recevez pour une EventNotification reprend les valeurs que vous avez fournies dans la requête. Les deux exceptions sont :

• Le MessageCategory qui est défini sur EventNotification.

• Le MessageType qui est défini sur Response.

{
  "MessageHeader": {
    "MessageCategory": "EventNotification",
    "MessageClass": "Service",
    "MessageType": "Response",
    "POIID": "POI_123",
    "ProtocolVersion": "3.1",
    "SaleID": "POS001",
    "ServiceID": "823"
  },
  "EventNotification": {
    "TimeStamp": "2025-04-02T15:48:47.596+02:00",
    "EventToNotify": "Reject"
  }
}

Ces erreurs surviennent lorsque le POI (terminal) est injoignable ou que les paramètres de session sont incorrects :

• Format de message invalide : Des champs obligatoires (ex. : DateTime, SaleSoftware) sont manquants dans la requête LoginRequest, ou sa structure est corrompue.

• POI injoignable : Le terminal est éteint, déconnecté du réseau, ou son adresse IP est inconnue ou incorrecte.