Démarrage & tenants
Comprendre la connexion à chaque tenant et le contexte de chaque pharmacie.
1. Objectif de l’intégration
Permettre à No Waste de suivre, pour une pharmacie équipée de deux ou trois Shelfy, l’état et l’évolution du remplissage de ces bacs, afin de déclencher ses propres alertes de don selon leur rotation. No Waste lit les données brutes de façon périodique et réalise sa propre analyse.
Le périmètre cible comprend :
- L’identification de la pharmacie et de ses bacs.
- La consultation de l’état courant d’un bac : produits présents, remplissage, poids et date de mise à jour.
- La consultation de l’historique de remplissage de chaque bac.
- La vérification de la fraîcheur des mesures.
Aucune écriture n’est ouverte au partenaire : ni création, ni modification, ni association de produit, ni maintenance.
Nommage
| Où | Nom utilisé | Exemples |
|---|---|---|
| Ce que voit le client (écrans, libellés, cette documentation) | Shelfy | Portail, scanner, étiquette du bac, nom du point d’accès SHELFY-xxxx. |
| Le code et l’API | promo_bin |
Type d’appareil et de meuble promo_bin, route /api/promo-bins, identité PB-<numéro de série>. |
Le texte de cette documentation dit donc « Shelfy » ; les chemins, types et identifiants cités entre accents graves restent les noms techniques promo_bin. Une exception : les réponses de la liste et du détail rangent le bac dans une propriété nommée shelfy.
2. Adresse d’API propre à chaque tenant
L’adresse de l’API est fournie par Tekshelf pour chaque tenant. Les chemins décrits dans cette documentation s’ajoutent à cette adresse.
Un tenant correspond à un périmètre client. Un filtre storeId permet de cibler un magasin dans les appels qui le proposent.
2.1 Configuration de connexion
| Information | Règle d’intégration |
|---|---|
| Origine de l’API | Adresse HTTPS propre au tenant, fournie par Tekshelf. |
| Environnement | Test ou production, explicitement identifié. |
| Accès partenaire | Jeton Bearer fourni par Tekshelf pour un utilisateur en lecture, limité aux magasins autorisés ; procédure d’obtention à compléter. |
| Magasin | Identifiant storeId (UUID) utilisé lorsque l’appel le demande. |
| Ressources | Identifiants Tekshelf des bacs (deviceId) et des produits ; à conserver avec le contexte du tenant. |
Convention de cette documentation : TENANT_ORIGIN désigne uniquement le protocole et l’hôte, sans barre finale ni suffixe /api.
Exemple d’assemblage, avec un domaine fictif non opérationnel :
TENANT_ORIGIN = https://tenant-a.example.invalid
Chemin = /api/promo-bins?storeId={storeId}
URL appelée = TENANT_ORIGIN + chemin
Les adresses de test et de production se configurent séparément dans No Waste.
2.2 Gestion de plusieurs tenants par No Waste
No Waste conserve, pour chaque connexion client, l’origine du tenant, l’environnement, les accès associés et la correspondance avec les magasins. Une requête est toujours envoyée au tenant de la ressource concernée.
Les identifiants sont à considérer dans leur contexte : le stockage côté No Waste doit associer au minimum l’environnement, le tenant et l’identifiant de ressource. Une connexion accordée à un tenant n’autorise pas à lire un autre tenant.
Un storeId est un filtre et un contexte métier ; il ne remplace pas le contrôle des droits côté serveur. L’absence de filtre ne doit jamais ouvrir l’accès à des magasins non autorisés.
Aucune API centrale de découverte de tous les tenants n’est définie ici. Les adresses initiales sont fournies par Tekshelf ; leur provisionnement automatisé pourra être spécifié séparément si nécessaire.