Ce qu’un producer OSIRIS JSON est cense faire
Les producers OSIRIS JSON sont l’endroit ou le standard devient reel.
Les directives pour les producers et la documentation du SDK producer le rendent explicite. Un producer n’est pas seulement un parseur qui se trouve emettre du JSON. C’est la frontiere ou des inventaires proprietaires sont traduits en un snapshot OSIRIS deterministe, portable et sur auquel d’autres outils peuvent faire confiance.
Un producer est un traducteur en lecture seule
Le premier point important dans les directives pour producers est ce qu’un producer n’est pas.
Il ne provisionne pas l’infrastructure. Il ne modifie pas les equipements. Il n’invente pas les donnees manquantes. Il ne reinterprete pas la specification. Le travail d’un producer est plus etroit et plus strict: decouvrir ce qui existe, le normaliser en OSIRIS, supprimer les donnees dangereuses ou non pertinentes et emettre un snapshot qui peut etre valide par la chaine d’outils canonique d’OSIRIS.
Cela semble evident, mais c’est la bonne ligne a tracer. A partir du moment ou les producers commencent a se comporter comme des plans de controle, ou a integrer des idees personnalisees de ce que signifie OSIRIS, l’interoperabilite se casse.
Le flux de travail du producer est delibere
La documentation decrit le cycle de vie du producer en quatre etapes: discovery, normalization, redaction et emission.
Cette sequence compte parce que chaque etape a une responsabilite differente:
- discovery collecte les donnees du vendor ou de la plateforme
- normalization les mappe vers les structures standard d’OSIRIS
- redaction supprime les secrets, les PII et le bruit inutile
- emission serialise le document et le valide avant publication
Les directives laissent aussi une place a la realite. Les inventaires partiels sont acceptables. Les echecs individuels de discovery devraient generalement etre journalises et ignores plutot que de faire echouer tout l’export. Mais cette flexibilite s’arrete a la frontiere de securite: si des secrets sont detectes, le producer est cense echouer de maniere sure.
Le determinisme est une fonctionnalite, pas une finition
L’un des themes les plus forts dans les deux documents est le determinisme.
Les ID de ressources, de connexions et de groupes sont censes rester stables d’une execution a l’autre. La documentation pour producers insiste fortement contre l’aleatoire, les ordres instables et les noms ad hoc. La raison est simple: si le meme environnement produit une sortie differente a chaque fois, les diff, la correlation et l’automatisation en aval deviennent tous peu fiables.
Le SDK renforce cela avec des aides concretes:
- generation deterministe d’ID a partir de cles canoniques
- gestion des collisions en deux phases via un
IDRegistry - un
DocumentBuilderqui gere$schema,version, les metadonnees du generator et une sortie topologique triee - des helpers de test qui verifient le determinisme octet par octet et la coherence des golden files
C’est l’un des signes les plus clairs qu’OSIRIS est en cours de conception pour un outillage de longue duree, et non pour des exports ponctuels.
La securite est une responsabilite du producer
Les directives pour producers sont tout aussi fermes a propos de la redaction.
Les documents OSIRIS ne doivent pas contenir d’identifiants, de tokens, de cles privees ou de chaines de connexion avec des secrets integres. Les producers sont censes rechercher des motifs courants avant l’emission, decomposer les valeurs dangereuses au lieu de les copier telles quelles et choisir un mode d’echec explicite.
Le mode par defaut recommande est fail-closed. Un mode log-and-redact a activation explicite existe, mais meme la les regles restent strictes: ne jamais journaliser la valeur secrete elle-meme, toujours marquer le document comme redige et ne jamais laisser la redaction se produire en silence.
C’est la bonne posture. Les producers sont les plus proches des systemes sources bruts, ce qui en fait l’endroit le plus dangereux pour etre negligent.
Le SDK est la pour eliminer la derive
Le SDK Go pour producers n’est pas presente comme une infrastructure magique. Il est presente comme un moyen d’arreter la derive des producers.
Il standardise le contrat Collect(ctx), fournit un contexte d’execution partage, des factories de ressources et de relations, des helpers de normalisation, des builders deterministes et un harness de test. Tout aussi important, il refuse de devenir un second validateur. Le SDK n’est pas proprietaire des diagnostics V-* et n’importe pas @osirisjson/core comme bibliotheque. Les producers valident la sortie en appelant la CLI canonique comme etape externe.
Cette separation est saine sur le plan architectural. Elle maintient la logique de mapping dans les producers et la logique de validation dans le moteur partage d’OSIRIS.
La confiance vient des tests
Le message final de la documentation pour producers est que la sortie d’un producer doit etre reproductible et verifiable.
Les golden files sont traites comme la principale defense contre les regressions. Le flux de travail attendu est simple: simuler l’entree du vendor, generer le document OSIRIS, le comparer au golden file, puis valider cet artefact avec la CLI canonique sous le profil strict. Le harness de test du SDK ajoute des helpers pour ce flux et pour des reexecutions deterministes avec des horloges et des fixtures fixes.
Cela compte parce que la qualite d’un producer ne se limite pas a savoir si l’export “fonctionne une fois”. Il s’agit de savoir si la meme entree continue a produire une sortie digne de confiance a mesure que l’ecosysteme evolue.
Lire la documentation des producers
Les directives pour producers sont disponibles dans la section architecture de la documentation: