Opérations HTTPS
Lectures et écritures passent par l’API SaaS sous périmètre client, entrepôt, appareil et utilisateur.
Connectivité et continuité
Les applications prises en charge se connectent directement à Ysend en HTTPS et via les hubs temps réel. Files hors ligne et maillage de terminaux préservent le travail borné ; pont desktop, tunnel équipement et edge de reprise restent trois composants facultatifs distincts.
Route par défaut
Aucun serveur applicatif d’entrepôt n’est requis. Chaque client enrôlé conserve sa propre identité, son périmètre et sa session cloud.
Lectures et écritures passent par l’API SaaS sous périmètre client, entrepôt, appareil et utilisateur.
Les hubs transportent les mises à jour sans transférer l’autorité métier à un relais local.
Sans pont local configuré ou joignable, le terminal conserve son chemin cloud direct.
Garde appareil
Chaque événement reçoit un identifiant unique pour ne jamais être enregistré deux fois, et le contexte de la tâche est conservé localement.
L’interface ne dit pas encore que l’opération est acceptée par le cloud.
Les reprises gardent la même identité pour rendre les doublons sans danger.
L’enregistrement sur l’appareil ne remplace pas la confirmation par Ysend.
Maillage pair à pair d’entrepôt
Les instances prises en charge écoutent et découvrent leurs pairs, puis échangent événements d’opération et références signées.
Les pairs échangent des événements bornés sans cloud ; un poste desktop peut participer comme pair facultatif.
Au retour du WAN, chaque appareil transmet normalement son propre travail directement au SaaS.
Un pair inactif peut envoyer un événement répliqué pour un appareil d’origine devenu indisponible.
Compte, entrepôt, appareil, période de clé, signature et expiration sont vérifiés ; aucun identifiant de connexion ou clé API réutilisable n’entre dans le maillage.
Composants locaux facultatifs
Par poste
L’agent fourni relie scanners, imprimantes et caméras, et peut devenir pair du maillage ou relais WAN.
Par site équipement
Un agent enrôlé par le fournisseur transporte les flux adaptateur TCP autorisés dans des tunnels sortants.
Par entrepôt, sur activation
Le logiciel edge local séparé est désactivé par défaut et doit être configuré et installé pour chaque entrepôt.
Équipement derrière NAT
L’agent de site enrôlé établit un WebSocket sortant vers le SaaS.
Le site n’autorise que les adresses prévues, et les jetons d’appairage ne sont jamais conservés en clair.
Chaque connexion équipement autorisée obtient un canal binaire duplex séparé.
Le trafic TCP machine ou robot traverse le tunnel, tandis que le SaaS reste autoritatif.
Réconciliation cloud
Envoi d’origine, secours pair et relais local peuvent se recouvrir. Le SaaS valide et déduplique sans demander à l’entrepôt de choisir un vainqueur.
La même opération garde le même identifiant unique à travers reprises et copies, pour ne jamais être appliquée deux fois.
Périmètre, séquence, âge, signature et état du flux sont contrôlés avant acceptation.
La réponse cloud établit un état accepté, refusé ou déjà enregistré.
Supervision du parc
Identité appareil et affectation entrepôt sont explicites et révocables.
Connectivité, version, santé et signaux métier permettent le diagnostic sans contrôle illimité.
Les appareils gérés reçoivent des mises à jour approuvées en conservant leurs droits d’accès.
Une identité supprimée ou expirée est refusée partout : cloud, maillage et pont.
Listez applications, adresses des équipements, pannes réseau et exigences de garde. Nous séparerons SaaS direct, maillage, pont équipement et edge facultatif.