Blog ·
Automatizarea facturării ISPConfig
ISPConfig răspunde HTTP 200 la orice, inclusiv la eșecuri. Ce înseamnă asta pentru un declanșator de facturare și cum arată ciclul contului pe API.
De Provibr
ISPConfig are o comandă pentru fiecare moment în care banii și mașinile se ating: crearea contului, suspendarea lui, mutarea lui pe alt pachet, eliminarea lui. Ce nu are este ceva care să decidă când să le ruleze.
Racordarea celor două jumătăți este în cea mai mare parte muncă obișnuită. Două lucruri legate de ISPConfig nu sunt obișnuite și amândouă vor strica în tăcere o primă încercare: codul de stare al unui apel nu vă spune absolut nimic, iar un cont nu este un client.
Codul de stare nu spune nimic
Totul se întoarce ca HTTP 200. Erori de validare, „acest lucru nu există”, o parolă greșită, o metodă pe care utilizatorul la distanță nu are voie să o apeleze: toate, 200. Verdictul este un câmp code din interiorul corpului JSON.
code | Semnificație |
|---|---|
ok | A funcționat; response poartă rezultatul |
remote_fault | A eșuat: validare, obiect lipsă, autentificare, permisiune. message explică |
invalid_method | Metodă necunoscută sau o metodă care nu se află în acea clasă |
permission_denied | Utilizatorului la distanță îi lipsește acea funcție |
Clasificați după code și după text, niciodată după stare. Motivul pentru care acest lucru contează mai mult pentru o integrare de facturare decât pentru orice altceva este interogarea: un client care tratează 200 drept succes citește un eșec de autentificare ca pe un inventar gol reușit și apoi marchează fiecare cont al acelui client drept dispărut. O singură sesiune expirată, iar reconcilierea dumneavoastră șterge o afacere de găzduire.
Câmpul message vine în două variante, iar diferența este utilă. Erorile de validare care vin din stratul de formulare al panoului sunt o listă de chei de traducere separate prin <br>, nu propoziții: domain_error_unique pentru un domeniu care este deja găzduit. Verificările din biblioteca la distanță sunt propoziții obișnuite în engleză: Invalid client_id 99999. Potriviți cheile, citați propozițiile.
Un cont înseamnă un site web, nu un client
ISPConfig separă două lucruri pe care majoritatea panourilor de control le contopesc. Un client este o autentificare în panou cu limite pentru întregul cont. Un web_domain este un singur site găzduit. Un client poate deține mai multe site-uri.
Un cont de găzduire Provibr este un singur site web, identificat prin domeniul său. Crearea unuia are prin urmare nevoie de un proprietar, așa că agentul creează un client nou și un site sub el și derivă autentificarea clientului din domeniu, ca să poată găsi întotdeauna proprietarul din nou.
Acea alegere este cea care face sigură calea de ștergere, iar calea de ștergere este locul unde această integrare aproape că a luat-o razna. Mai multe despre asta mai jos.
Ciclul de viață, în corespondență
| Eveniment de facturare | Apel ISPConfig | Răspuns în caz de succes |
|---|---|---|
| Comandă plătită | client_add, apoi sites_web_domain_add | code: ok, de două ori |
| Factură restantă | sites_web_domain_set_status(id, "inactive") | code: ok |
| Plată primită | sites_web_domain_set_status(id, "active") | code: ok |
| Trecere la un plan superior / inferior | client_update cu un șablon de client nou | code: ok |
| Anulare | sites_web_domain_delete, apoi eventual clientul | code: ok |
Suspendarea este idempotentă în ambele direcții
Suspendarea comută indicatorul active al site-ului între y și n. Nu există măști de biți și nici stări parțiale: un site este pornit sau este oprit.
O a doua suspendare pe un site deja suspendat răspunde code: ok cu un răspuns de 0, ceea ce înseamnă zero rânduri modificate. Aceasta nu este o eroare, iar un ciclu de relansare care suspendă tot ce este restant, inclusiv ceea ce a suspendat ieri, nu are pentru ce să își ceară scuze. Merită apreciat cât de rar este acest lucru: așa cum arată Facturarea și aprovizionarea HestiaCP, acolo aceeași a doua suspendare este un HTTP 401, imposibil de deosebit de un secret greșit, pe un panou care vă blochează adresa după cinci autentificări refuzate.
Un lucru de știut, chiar dacă integrarea nu îl folosește: ISPConfig are și o blocare la nivel de client, iar setarea ei trece deodată pe inactiv fiecare site al acelui client. Un client care se blochează singur în panou, sau o blocare de revânzător de deasupra lui, apare prin urmare în interogare ca suspendat. Acest lucru este corect și nu este ceva ce a făcut sistemul dumneavoastră de facturare.
Schimbarea unui pachet este aici o acțiune reală
Un pachet ISPConfig este un șablon de client: un set de limite cu nume, construit de un administrator în panou. API-ul la distanță nu poate crea unul, ceea ce este în regulă, pentru că un plan ar trebui să se refere la un pachet, nu să îl inventeze. Provibr transmite numele pachetului, iar agentul caută ID-ul șablonului.
Asta face din ISPConfig unul dintre panourile de control unde o schimbare de plan este cu adevărat o schimbare de plan. CloudPanel și CyberPanel trebuie să o refuze din capul locului; aici ea se întâmplă, iar limitele se mută imediat.
Două avertismente măsurate, dacă scrieți asta dumneavoastră înșivă. Trimiteți o actualizare minimală, care nu poartă nimic în afară de noul șablon: o actualizare cu întreaga fișă a clientului s-a întors ca remote_fault fără niciun mesaj utilizabil, la fel și una care combina un șablon explicit cu limite explicite. Și să știți că șablonul are prioritate față de limitele pe care le trimiteți în același timp, ceea ce este ordinea corectă, dar surprinde lumea prima dată.
Semnalul de gata este global pe server
Crearea unui site web răspunde în milisecunde, iar acel răspuns înseamnă acceptat, nu gata. Rândul din baza de date există; gazda virtuală și rădăcina documentelor sunt așezate asincron de demonul serverului.
Semnalul pe care îl așteptați este numărătoarea cozii de sarcini a acelui server, despre care s-a măsurat că scade de la trei la zero în aproximativ opt secunde pe o mașină liniștită și în aproximativ douăzeci și trei de secunde la o rulare anterioară. Este un contor global, nu unul per comandă. Pe un server aglomerat, cu mai mulți chiriași, el poate rămâne peste zero din cauza sarcinilor altor clienți sau poate ajunge la zero în timp ce munca dumneavoastră este încă în așteptare.
Așadar, regula este o expirare cu un mesaj sincer și nu o așteptare infinită: interogați până când coada este goală sau până când se epuizează bugetul de creare de 180 de secunde, și apoi raportați contul ca fiind creat, pentru că este. „Site-ul este încă în curs de configurare” este un lucru mai bun de spus unui client plătitor decât un indicator de încărcare care nu se oprește niciodată.
Ștergerea este o chestiune de confidențialitate, nu una de curățenie
Aceasta este partea articolului de păstrat dacă nu păstrați nimic altceva, și nu este cu adevărat despre ISPConfig.
Calea de ștergere avea un defect pe care niciun set de date de test nu îl putea vedea: compara două câmpuri care nu sunt niciodată efectiv egale, așa că ramura care elimina clientul proprietar era cod mort. Fiecare ștergere lăsa în urmă o autentificare în panou care purta numele clientului, adresa lui de e-mail, datele lui de contact și parola. Comanda răspundea ok, site-ul dispărea, contorul mergea la zero, iar datele personale ale unei persoane care ceruse să plece rămâneau pe nod.
Nimic de deasupra panoului nu poate vedea asta. Un lucrător de epurare și un export pentru persoana vizată curăță partea noastră; ele nu au nicio vedere asupra a ceea ce rămâne pe nodul dumneavoastră de găzduire. Regula care a ieșit din asta merită furată:
> Măsurați o cale de ștergere față de propria bază de date a panoului și niciodată față de „comanda a returnat ok”.
Pe ISPConfig acestea sunt patru numărători și toate patru trebuie să fie zero: site-urile, clienții, autentificările de sistem și directorul clientului de pe disc. Și măsurați-le cu panoul, nu cu ajutorul de curățare al propriului dumneavoastră test, pentru că acel ajutor poate purta aceeași neînțelegere, și atunci mașina pare curată în timp ce integrarea pierde date.
Regula sigură de ștergere este ea însăși un singur rând: eliminați site-ul; eliminați clientul proprietar doar dacă nu îi mai rămâne niciun site. ISPConfig are un apel care șterge un client și tot ce se află sub el, iar pe un cont importat acesta ar lua cu el celelalte site-uri ale clientului. Nu ștergeți niciodată mai mult decât s-a cerut.
Nimic nu este instantaneu
Panoul dumneavoastră este accesibil doar prin agentul din interiorul propriei dumneavoastră rețele, iar acel agent se conectează spre exterior, așa că un punct final care modifică un cont nu poate răspunde cu rezultatul. El răspunde că ordinul a fost acceptat și vă înmânează o comandă de urmărit până când starea ei este definitivă: încheiată, eșuată, expirată sau anulată. Citirea nu funcționează niciodată astfel, pentru că un inventar sau o factură vine dintr-o bază de date și nu de la gazda dumneavoastră.
Consecința practică pentru un declanșator de facturare: nu marcați comanda ca finalizată pe baza răspunsului de acceptare. Tot ce creează ceva acceptă și o cheie de idempotență de propria dumneavoastră alcătuire, așa că un webhook reluat și un dublu clic nu vă costă nimic.
Unde se află factura
Provibr nu facturează clienții dumneavoastră, nu îi urmărește și nu știe ce le percepeți. Acea relație este a dumneavoastră.
Ceea ce facturează Provibr este capacitatea pe care o rezervați: câte conturi de găzduire puteți rula în același timp, la un preț unitar care scade pe paliere pe măsură ce numărul crește. Pentru un cont de găzduire nu există „oprit”: există activ și suspendat, iar un cont suspendat nu contează. Așadar, acțiunea de relansare pe care oricum o voiați din motive comerciale este și cea care eliberează locul pentru care plătiți.
Ce nu este automatizat
Provibr gestionează conturi, nu panoul. Nu instalează ISPConfig, nu îl actualizează și nu atinge căsuțele de e-mail, bazele de date sau DNS-ul: un client care își șterge propria căsuță de e-mail o face fără ca ceva de deasupra panoului să știe sau să îi pese. Nu există consolă pentru un cont de găzduire, nu există reinstalare și nu există suspendare parțială.
Dacă vă aflați mai devreme în acest proces decât la partea de facturare, articolul însoțitor este Cum să vindeți găzduire web cu ISPConfig, care acoperă utilizatorul la distanță, delimitarea drepturilor și modelul cu un panou și mai multe servere. Datele de autentificare, certificatul și ecranul pachetelor sunt documentate pe pagina de documentație ISPConfig.
Întrebări frecvente
De ce fiecare apel de API ISPConfig returnează HTTP 200?
Pentru că API-ul său la distanță poartă verdictul în corp, nu în linia de stare. Câmpul code spune ok, remote_fault, invalid_method sau permission_denied. Un client care se încrede în stare citește un eșec de autentificare drept un răspuns gol reușit.
Un cont ISPConfig înseamnă un client sau un site web?
Un site web. ISPConfig ține clientul, care este o autentificare în panou cu limite, separat de web_domain, care este un site găzduit, iar un client poate deține mai multe site-uri. Un cont de găzduire este identificat aici prin domeniul său.
Poate un sistem de facturare să suspende de două ori același site ISPConfig?
Da. Al doilea apel răspunde ok cu zero rânduri modificate, ceea ce nu este o eroare. Și anularea suspendării este idempotentă, așa că un ciclu nocturn de relansare nu are nevoie de o stare proprie.
Ștergerea unui cont ISPConfig elimină autentificarea clientului în panou?
Trebuie să o facă și merită verificat pe propria dumneavoastră instalare. Comportamentul corect este eliminarea site-ului și apoi a clientului proprietar doar atunci când acel client nu mai are niciun site. O ștergere care lasă clientul în urmă lasă pe nod numele, adresa și parola clientului.
Pot schimba un pachet ISPConfig dintr-un sistem de facturare?
Da. Un pachet este un șablon de client, iar atribuirea altuia mută limitele imediat. Trimiteți în actualizare doar noul șablon; s-a măsurat că o încărcătură mai completă eșuează fără un mesaj de eroare utilizabil.
