Conectori
Un conector aduce mesaje în platformă din afara programului care rulează fluxurile dumneavoastră: unul consumă de pe un broker, celălalt urmărește un director. Amândoi prezintă o credențială la ușa de coadă, ca orice alt apelant, cu o cheie de API și plafonul acelei chei, deci ce spune pagina porții de acces despre cheia de API se aplică și lor.
Ce e un conector
Doi conectori se livrează cu platforma: unul consumă de pe un broker de mesaje prin STOMP, celălalt urmărește un director. Niciunul nu face parte din programul care rulează fluxurile dumneavoastră: fiecare prezintă o credențială la ușa de coadă și postează mesajul acolo, exact ca orice alt apelant.
Ce spune pagina porții de acces despre cheia de API, plafonul de debit și refuzuri se aplică și unui conector: nimic în plus și nimic special pentru el.
Ce face un conector la un refuz
| Răspunsul ușii | Ce face conectorul | Ce se întâmplă cu mesajul |
|---|---|---|
| 401, 403 | Se oprește, cu motivul și reparația scrise | Rămâne recuperabil: nu se pierde și nu se reîncearcă la infinit |
| 400, 413 | Trece la mesajul următor | E pus deoparte și păstrat, ca să fie corectat și retrimis |
| 429 | Așteaptă cât spune răspunsul, cu un plafon propriu de cinci minute | Se reîncearcă |
| 5xx, cădere de rețea | Reîncearcă, cu pas crescător | Se reîncearcă |
Un refuz de credențială oprește procesul în loc să-l lase să se învârtă. Credențiala e a conectorului, nu a mesajului: dacă e greșită, următoarele mii de mesaje vor primi același refuz, iar un proces care reîncearcă la infinit umple jurnalul și ascunde cauza. Platforma nu răspunde niciodată 401 când poarta n-a putut decide: acolo răspunde 503, care e tranzitoriu și chiar se reîncearcă.
Ce nu e terminal, deliberat: un 404 se reîncearcă în continuare. Un conector pornit înaintea fluxului pe care-l alimentează primește un 404 legitim, iar oprirea lui ar fi un fals defect. Un corp pe care ușa de coadă nu-l poate citi primește un 400 și e pus deoparte, ca unul peste plafon: conectorul trece la mesajul următor, deci un mesaj ilizibil nu ține pe loc mesajele de după el.
Telemetria conectorului nu cheltuie plafonul apelantului
Un conector raportează în același jurnal ca restul platformei: fiecare mesaj preluat lasă un eveniment, cu o corelare proprie care se regăsește în urma livrării. Raportarea aia nu consumă din plafonul de debit al credențialei. Plafonul e per credențială, deci un conector care împarte cheia cu apelanții sincroni ar plăti de două ori pe mesaj și ar coborî tăcut plafonul celorlalți.
Cum recunoaște platforma un mesaj pe care l-a văzut deja
Conectorul de mesaje ia identitatea din identificatorul pe care-l dă brokerul; cel de fișiere o compune din cale, oră de modificare și dimensiune. Contractul cozii rămâne livrare cel puțin o dată, în ambele cazuri.
Apărarea împotriva unui duplicat se scrie în flux, nu în conector: o cheie de deduplicare declarată în frontmatter, iar a doua livrare a aceleiași chei nu mai rulează fluxul, ci răspunde din înregistrare sau se oprește, după cum cere fluxul. E mecanismul pe care se sprijină un proces de business care nu are voie să se execute de două ori.
Consecință practică pentru identitatea compusă din cale, oră și dimensiune: rezoluția e de o secundă. Un fișier înlocuit în aceeași secundă, la aceeași cale și cu aceeași dimensiune, nu se mai citește a doua oară.
Plafonul de dimensiune, și ce nu trece printr-un flux
Plafonul unui mesaj se rezolvă per punct de acces, iar un corp anunțat peste plafon e refuzat fără să se citească un octet. Conectorii citesc același plafon din frontmatter-ul fluxului pe care-l alimentează, deci nu există un al doilea plafon care să se învechească separat de primul.
Peste plafon nu există conținut opac și nici referință la depozitul adresat prin conținut: corpul se materializează în memorie și se parsează. De aici regula pe care o spunem înaintea oricărei discuții de arhitectură: fișierele mari nu trec printr-un flux. Un nor de puncte, o înregistrare video, o ridicare fotogrammetrică se transferă direct între sisteme; prin platformă trece metadata: unde e fișierul, ce acoperă, ce amprentă are, ce s-a schimbat.
Date incomplete sau deteriorate
Un flux are două garduri, cu două înțelesuri, iar alegerea între ele e a autorului: unul filtrează tăcut mesajele care nu-l interesează, celălalt refuză explicit, la prima regulă falsă, cu mesajul scris de autor. Un set incomplet, insuficient agregat sau neanonimizat se respinge pe al doilea, nu se aruncă pe primul.
Un flux poate avea și o secvență de tratare a erorii. Un handler care reușește nu răspunde 200: statusul rămâne cel natural al erorii, deci un refuz nu se citește niciodată ca acceptare.
Ce pornește singur: interogare și orar, nu abonament
Conectorul de fișiere scanează directorul la un interval configurat, în ordinea vechimii. Nu se abonează la notificările sistemului de fișiere și nu coboară în subdirectoare. Conectorul de mesaje stă pe o coadă de broker și consumă de acolo.
Separat de conectori, un flux poate purta un orar cu șase câmpuri, iar un tic lasă în jurnal aceeași pereche de evenimente ca o cerere, pe canalul de cron.
Ce rămâne pe disc și cât
- Un mesaj acceptat pe ușa de coadă se scrie în jurnalul propriu al cozii și supraviețuiește unei căderi; o reîncercare programată supraviețuiește unei reporniri.
- Corpul mesajului stă în acel jurnal în clar. Mascarea se aplică la ieșirea de jurnal, e numai pe JSON și numai pe chei de obiect. Cadrul de pe coadă n-o primește.
- Confirmarea unui mesaj nu șterge octeții. Nu există nici limită de timp, nici de dimensiune pentru cât stă un corp pe coadă: octeții pleacă la drenajul complet al cozii sau la compactarea unei cozi abandonate.
- Fereastra de retenție guvernează ambele ieșiri de jurnal (rânduri și fișiere) într-o singură trecere. Nu atinge cozile, registrul, lanțul de audit sau starea de flux.