Comptes, marchands et environnements
Avant de configurer des intégrations ou des processus, clarifiez les périmètres dans lesquels vous travaillez. Un utilisateur accède à des comptes Ormuz ; chaque compte contient les marchands qu’il opère ; les configurations de test et de production restent séparées.
Les quatre périmètres à distinguer
| Périmètre | Rôle |
|---|---|
| Utilisateur | Personne qui se connecte à Ormuz et accède aux comptes qui lui sont autorisés. |
| Compte | Environnement administré par une organisation. Un utilisateur peut avoir accès à plusieurs comptes. |
| Marchand | Périmètre métier dans lequel sont organisés les données, extensions et processus d’une activité opérée. |
| Environnement externe | Mode test ou production des systèmes et providers connectés au marchand. Il doit rester cohérent avec le compte Ormuz utilisé. |
Comptes Ormuz
Le compte est le premier périmètre sélectionné après la connexion. Il regroupe les utilisateurs autorisés et les marchands disponibles dans cet environnement. Si vous avez accès à plusieurs comptes, vous choisissez celui dans lequel vous souhaitez travailler avant d’administrer ses ressources.
Pour commencer, utilisez un compte sandbox. Il permet de découvrir la plateforme, de connecter des systèmes de test et de valider les processus sans mélanger ces opérations avec votre activité de production.
Marchands
Le marchand représente l’activité métier pour laquelle Ormuz orchestre des opérations. Les objets métier, configurations d’extensions et processus sont rattachés à ce périmètre afin qu’une même organisation puisse exploiter plusieurs activités lorsque cela est nécessaire.
Un ou plusieurs marchands ?
| Situation | Découpage généralement adapté |
|---|---|
| Une société avec une activité commerciale principale | Un marchand constitue généralement le bon point de départ. |
| Plusieurs boutiques alimentent la même société et les mêmes opérations | Un marchand peut regrouper plusieurs systèmes connectés si les données et processus forment un même périmètre métier. |
| Plusieurs filiales ou activités sont opérées séparément | Utilisez des marchands distincts lorsque données, processus ou configurations de services doivent être isolés. |
| Une plateforme opère pour plusieurs vendeurs autonomes | Plusieurs marchands peuvent être nécessaires lorsque chaque vendeur constitue un périmètre opérationnel indépendant. |
En sandbox, créez votre premier marchand depuis la Console avec son nom et, si vous en disposez, une référence issue de votre propre système. Cette référence aide à conserver une identité stable entre Ormuz et votre SI.
Sandbox et production
Sandbox et production ne sont pas deux modes d’une même configuration. Ils représentent des environnements distincts qui doivent utiliser leurs propres accès, configurations d’extensions, endpoints et comptes externes.
| Élément | Sandbox | Production |
|---|---|---|
| Compte Ormuz | Compte de test | Compte de production distinct |
| Marchand | Périmètre de test représentatif | Périmètre de production configuré explicitement |
| Systèmes métier | Instances, boutiques ou données de test | Systèmes réellement opérés |
| Providers | Credentials et comptes sandbox | Credentials et comptes réels |
| API et webhooks | Clés et endpoints de test | Clés et endpoints de production |
| Processus | Validés avec des données représentatives | Configurés pour les extensions et responsabilités de production |
Variables d’environnement marchand
Un marchand peut définir des variables réutilisables par ses processus : seuils, adresses, références ou autres valeurs qui changent selon l’environnement sans changer la logique du processus. Elles sont accessibles dans les bindings, expressions et contenus dynamiques via le namespace env, par exemple env.approval_limit ou env.invoicing_contact.
Chaque variable porte un type. Le processus enregistre les clés et types qu’il utilise comme dépendances ; une variable absente ou devenue incompatible est donc détectée avant l’exécution plut ôt que de produire une valeur ambiguë à runtime.
env.ma_cle. Les accès dynamiques tels queenv[variable] ne sont pas acceptés, car Ormuz doit pouvoir déterminer les dépendances du processus et les vérifier avant son déploiement.Valeur figée par instance
Au démarrage d’une instance, Ormuz capture la valeur des seules variables référencées par sa révision. Cette instance continue donc avec le même contexte même si un opérateur modifie ensuite la variable pour les nouvelles exécutions. Une réexécution sur une révision plus récente reconstruit en revanche son propre snapshot.
Import et export
La Console permet d’exporter les variables d’un marchand puis d’importer ce même format dans un autre environnement. Deux stratégies sont proposées :
| Stratégie | Comportement |
|---|---|
skip_existing | Crée les clés absentes et laisse intactes les variables déjà présentes. |
overwrite | Remplace type, valeur et description des clés existantes. |
L’import est atomique. Si une modification de type est incompatible avec un processus courant qui référence la variable, l’opération entière est refusée plutôt que de laisser le marchand dans un état partiellement importé.
Portabilité et déploiement
Les variables d’environnement ne sont pas embarquées comme valeurs dans une définition de processus. Le processus transporte son contrat de dépendances — clés et types attendus — tandis que chaque marchand cible conserve ses propres valeurs.
Lors d’un déploiement vers un autre environnement, Ormuz vérifie que toutes les variables requises existent chez le marchand cible avec exactement le type attendu. Le déploiement est bloqué tant que ce contrat n’est pas satisfait. Cette séparation permet de promouvoir le même processus sans copier des valeurs propres au sandbox.
Choisir le bon découpage
Le bon modèle est celui qui suit vos responsabilités opérationnelles. Séparez les marchands lorsqu’ils doivent réellement isoler des données, processus ou configurations. Ne les séparez pas uniquement parce qu’un même marchand utilise plusieurs boutiques, plusieurs providers ou plusieurs processus.
- Identifiez l’activité métier que vous souhaitez opérer comme un ensemble.
- Déterminez quels systèmes font autorité sur ses clients, commandes, factures et paiements.
- Créez le marchand correspondant dans le compte sandbox.
- Connectez uniquement les systèmes et services nécessaires au premier cas d’usage.
- Reproduisez ensuite ce découpage dans le compte de production avec des configurations dédiées.
Le guide Premiers pas replace ces périmètres dans le parcours complet d’intégration.