Ghid Sanramses Marketing
Plan de integrare pentru aplicații B2B: contract înainte de implementare
Un plan practic pentru evenimente, date, identitate, autentificare, autorizare, erori, retry, idempotency, acceptanță și rollback.
Un plan de integrare B2B este contractul operațional dintre două sisteme înainte de implementare: eveniment, date, identitate, responsabilitate, eroare, securitate și retestare. O diagramă cu săgeți nu este suficientă dacă nimeni nu știe ce se întâmplă când transferul eșuează.
Definește rezultatul înaintea tehnologiei
Scrie scenariul în limbaj operațional: „când formularul valid este trimis, se creează sau se actualizează o singură oportunitate, se păstrează sursa și se atribuie ownerul conform regulii”. Abia apoi alegi webhook, API, export sau conector. Platforma nu trebuie să dicteze procesul.
Proiectează schema minimă și identitatea
Pentru fiecare câmp notează sistemul sursă, tipul, caracterul obligatoriu, transformarea, destinația și regula de ștergere. Stabilește cheia care evită duplicatele și ce se întâmplă când două sisteme au valori diferite. GDPR cere minimizare și protecție prin proiectare atunci când sunt prelucrate date personale.
| DECIZIE | ÎNTREBARE | RISC FĂRĂ RĂSPUNS |
|---|---|---|
| Source of truth | Cine deține câmpul? | Suprascrieri |
| Identity key | Cum recunoaștem aceeași entitate? | Duplicate |
| Required fields | Ce este minim necesar? | Blocare sau exces de date |
| Permissions | Cine poate citi/scrie? | Acces neautorizat |
Autentificarea nu înlocuiește autorizarea
Un token valid nu dovedește că operația asupra fiecărui obiect este permisă. Definește permisiunile minime, rotația secretelor, separarea mediilor și interdicția de a include credențiale în cod, documente publice sau jurnale. OWASP tratează autorizarea la nivel de obiect și autentificarea ca riscuri distincte pentru API-uri.
Proiectează retry-ul împreună cu idempotency
O retrimitere automată poate crea duplicate dacă aceeași operație nu poate fi recunoscută. Pentru fiecare eroare stabilește dacă este temporară, permanentă sau necesită intervenție. Păstrează correlation ID, momentul, rezultatul și ownerul, fără a jurnaliza date personale ori secrete inutile.
Cum reconciliezi?
Compară periodic numărul și identificatorii înregistrărilor eligibile din sursă cu cele acceptate, respinse și aflate în retry. Reconcilierea descoperă pierderile pe care un răspuns HTTP izolat nu le arată.
B2B Integration Contract Canvas
| FIELD | DEFINIȚIE | DOVADĂ |
|---|---|---|
| TRIGGER | Evenimentul și condițiile | Exemplu real |
| PAYLOAD | Schema și versiunea | Contract validat |
| IDENTITY | Cheie și deduplicare | Test repetat |
| AUTH | Autentificare și permisiuni | Acces minim |
| FAILURE | Retry, dead letter, alertă | Scenarii simulate |
| OWNER | Responsabil business și tehnic | Runbook |
| ROLLBACK | Revenire și reconciliere | Test de restaurare |
Acceptanța include eșecul și schimbarea
- Happy path cu date valide.
- Eveniment duplicat.
- Câmp lipsă sau format invalid.
- Indisponibilitate temporară.
- Credential expirat ori permisiune insuficientă.
- Versiune nouă incompatibilă.
- Rollback și reconciliere după incident.
Pentru ordinea candidaților și riscuri, consultă auditul de automatizare. Pentru poziția integrării în întregul traseu, vezi arhitectura sistemului digital și harta sistemului digital de achiziție.
Când integrarea nu trebuie lansată?
Când nu există owner, sursă de adevăr, metodă de deduplicare, cale de eroare, mediu de test sau rollback verificat. O operație manuală documentată poate fi temporar mai sigură decât o integrare opacă.
Pregătește mediile și datele de test
Separă dezvoltarea, testarea și producția. Folosește conturi și credențiale distincte, permisiuni minime și date sintetice sau anonimizate când este posibil. Dacă testul are nevoie de date reale, documentează necesitatea, accesul și ștergerea lor. Nu presupune că un sandbox reproduce toate limitele producției; verifică diferențele declarate de vendor.
Scrie runbook-ul înainte de activare
Runbook-ul spune cum observi sănătatea integrării, cine primește alerta, ce verifică prima dată, cum oprește fluxul, cum reia mesajele și cum reconciliază perioada afectată. Include datele de contact operaționale, nu credențiale. Un incident nu este închis când endpointul răspunde din nou, ci când înregistrările pierdute, duplicate sau întârziate au fost reconciliate.
| SEMNAL | PRIMA ACȚIUNE | ÎNCHIDERE |
|---|---|---|
| Creștere erori | Oprește retry-ul necontrolat | Cauză și backlog rezolvate |
| Duplicate | Protejează scrierile | Cheie și date reconciliate |
| Payload respins | Compară schema și versiunea | Contract și test actualizate |
| Acces refuzat | Verifică permisiunea și rotația | Acces minim restaurat |
Gestionează schimbarea contractului
Orice câmp eliminat, tip schimbat, permisiune nouă sau limită de rată poate afecta consumatorul. Păstrează versiunea, perioada de compatibilitate, ownerul și planul de migrare. Nu lansa simultan schimbarea ambelor sisteme fără o cale de revenire independentă.
Integrarea are un contract sau doar o listă de conexiuni?
Sanramses poate documenta traseul, datele, excepțiile și criteriile de acceptare înainte de implementare.