Automatizarea facturării și a aprovizionării Plesk

Un produs de găzduire automatizat are trei momente în care banii și mașinile se ating:

1. 01Comanda este plătită. Un abonament trebuie să existe, pe planul de serviciu corect, în câteva secunde.
2. 02Factura este restantă. Abonamentul trebuie să se stingă și să revină în momentul în care este plătită.
3. 03Abonamentul se încheie. Trebuie eliminat, cu adevărat, inclusiv datele sale.

Plesk are apeluri pentru toate trei. Ce nu are este ceva care să decidă când să le ruleze, iar aceasta este jumătatea pe care o construiți. Această pagină este despre racordarea celor două și despre patru comportamente care sunt inofensive când le declanșați cu mâna și periculoase când un planificator le rulează la trei dimineața.

Totul de aici a fost măsurat față de un server Plesk Obsidian 18.0.80 în funcțiune, în august 2026.

Cele trei momente și apelurile care le susțin

Două dintre aceste cifre modelează proiectarea. Crearea unui abonament durează patru secunde și jumătate, iar ștergerea lui aproape opt. Este suficient de mult cât un formular de comandă să trebuiască să semnaleze că se întâmplă ceva, suficient de mult cât un buget de expirare scris pentru un API rapid să reteze la jumătate un apel care funcționează și suficient de mult cât două comenzi care sosesc împreună să fie cu adevărat concurente, nu doar teoretic.

Observați și rândul de citire. Un singur apel XML returnează fiecare abonament cu planul, starea, cota și utilizarea lui într-o treime de secundă, indiferent câte sunt, iar un sistem de facturare se reconciliază neîncetat cu panoul.

Capcana suspendării este o eroare de facturare, nu un detaliu de API

Plesk oferă două moduri de a suspenda, iar ele scriu câmpuri diferite. Într-un produs de găzduire, acest lucru încetează să fie o banalitate.

Măsurat, pe același abonament:

Un ciclu de relansare care suspendă prin REST scrie un câmp la care citirea în masă nu se uită, așa că platforma dumneavoastră continuă să raporteze contul ca activ. Iată de ce acest lucru dăunează în special facturării: când factura este în sfârșit plătită, automatizarea dumneavoastră se uită la propria stare, vede un cont care nu a fost niciodată suspendat și nu îl reia. Clientul a plătit și rămâne stins, iar nimic nu a consemnat o eroare.

Regula este o singură linie: suspendați prin câmpul pe care îl citiți. Provibr scrie <webspace><set><gen_setup><status>, după care ambele vederi se pun de acord.

gen_info.status este o mască de biți; am măsurat 0 pentru activ, 1 pentru webspace-off și 16 pentru dezactivat de administrator. Considerați suspendat tot ce nu este zero, singura interpretare care rezistă la o valoare pe care încă nu a văzut-o nimeni.

Un gol sincer: nu am măsurat suspendarea unui abonament deja suspendat. Pe HestiaCP, acel caz nu este idempotent și returnează o eroare care are aspectul unei erori de autentificare, exact ceea ce face un ciclu de relansare să se împiedice zilnic, așa că stabiliți acest lucru pe propriul dumneavoastră server înainte de a vă baza pe el.

O cheie expirată arată exact ca un server gol

Aceasta este defecțiunea care poate provoca pagube reale, și se descrie într-o singură frază.

API-ul XML returnează HTTP 200 pentru o cheie greșită. Eroarea se află în interiorul documentului, sub codul 11003. Un client care verifică codul de stare citește, prin urmare, o eroare de autentificare ca pe un tur reușit care nu a găsit niciun abonament.

Puneți acum acest lucru într-o sarcină de reconciliere nocturnă. Un tur reușit care nu a găsit nimic înseamnă, pentru orice platformă de găzduire, că fiecare cont prezent ieri a fost șters. O singură cheie expirată, și peste noapte sistemul dumneavoastră marchează întreaga bază de clienți ca dispărută.

Din aceasta decurg două reguli, iar ele se aplică oricărui panou care semnalează eșecul printr-un 200, ceea ce, dintre panourile pe care le-am integrat, este cazul celor mai multe:

• Pe API-ul XML, codul de stare nu poartă absolut nicio informație, nici măcar despre autentificare. Analizați documentul.
• Un răspuns ilizibil este necunoscut, niciodată gol. Un server gol chiar există, și el produce un singur rezultat gol în loc de o eroare. Aceste două cazuri sunt cu adevărat diferite, iar a le distinge este toată munca.

REST eșuează din nou altfel: o cheie inutilizabilă revine ca HTTP 401 cu un corp complet gol. Așadar, un test de conexiune trebuie să sondeze ambele suprafețe și să le raporteze separat. Un rezultat REST verde alături de un API XML mut înseamnă că lista de conturi, lista de planuri și fiecare schimbare de plan vor rămâne goale, iar concluzia tentantă este că clientul nu are niciun cont.

Codul de eroare nu vă spune ce a eșuat

Erorile REST ale Plesk poartă un cod numeric, iar tentația este să vă ramificați în funcție de el. Măsurat, el nu clasifică:

• 1007 acoperă atât „acest domeniu există deja”, cât și „acest nume de autentificare de client există deja”.
• 1013 acoperă atât „nu există un astfel de plan de serviciu” (REST), cât și „domeniul nu există” (XML).
• 0 înseamnă niciun cod, nu nicio eroare.

Pentru o integrare de facturare, pagubele aterizează în logica de reîncercare. „Domeniul există deja” după o comandă plătită poate însemna că încercarea anterioară a reușit pe jumătate și că ar trebui să vă uitați înainte de a reîncerca; „nu există un astfel de plan de serviciu” înseamnă că acea comandă nu va reuși niciodată și că ține de un om. Ele împart o familie de coduri. Prin urmare, textul clasifică, iar acea corespondență trebuie să se afle într-un singur loc din codul dumneavoastră, în loc să fie redusă din nou la fiecare punct de apel.

Există și o a cincea formă de eșec: cereți-i REST-ului o rută care nu există, iar el răspunde cu o pagină HTML, nu cu JSON.

O comandă eșuată poate bloca reîncercarea

Măsurat: crearea unui domeniu față de un plan de serviciu care nu există returnează HTTP 404 cu un mesaj clar, iar obiectul domeniu există totuși după aceea, fără tip de găzduire și cu o rădăcină de documente goală. Plesk creează mai întâi obiectul și aplică apoi planul și nu revine la starea anterioară când al doilea pas eșuează.

Într-un flux de facturare, acest lucru se citește astfel: clientul a plătit, aprovizionarea a eșuat, iar reîncercarea eșuează acum diferit, pentru că domeniul este folosit de un cont pe care nu l-a primit niciodată. Al doilea eșec arată ca o comandă duplicată, ceea ce se numără printre lucrurile mai derutante de depanat pornind de la un tichet de asistență.

Din aceasta decurg două lucruri ieftine. Rezolvați planul înainte de a crea ceva. Aveți deja lista de planuri, așa că căutați numele local și faceți comanda să eșueze înainte de a atinge panoul, ceea ce elimină acest eșec în loc să îl gestioneze. Și faceți curat după o creare eșuată, pentru că a lăsa în urmă epava transformă o comandă eșuată într-un nume de domeniu blocat pentru totdeauna.

Prin contrast, o eroare de validare a unui câmp, cum ar fi un nume de autentificare de client duplicat, returnează HTTP 400 și nu lasă nimic în urmă. Acea verificare rulează înainte de creare; doar căutarea planului vine prea târziu ca să vă salveze.

Două apeluri care au fiecare un mijloc

A elimina un abonament înseamnă DELETE /domains/{id} și apoi DELETE /clients/{id}. Dacă primul reușește și al doilea nu, vă rămâne o înregistrare de client care nu deține nimic: invizibilă în majoritatea vederilor și o eroare de nume de autentificare duplicat data următoare când acel client revine. La 7,7 secunde, ștergerea este de asemenea suficient de lungă cât o rețea să o întrerupă, așa că o anulare merită același tratament ca o aprovizionare: recitiți panoul după aceea și reconciliați cu citirea în masă, nu cu răspunsul pe care l-ați primit.

Trecerile la un plan superior sau inferior au colțul lor propriu. <webspace><switch-subscription> nu acceptă un nume de plan, ci doar GUID-ul planului sau ID-ul său extern, acolo unde peste tot în altă parte în Plesk un pachet este referențiat prin nume. Provibr păstrează numele ca lucrul pe care îl văd oamenii și face traducerea nume-către-GUID intern, pornind de la lista de planuri pe care interogarea o preia oricum. A stoca în schimb un GUID în sistemul dumneavoastră de facturare funcționează exact până când cineva reconstruiește un plan.

Unde locuiește factura

Cele trei momente de mai sus sunt doar jumătate dintr-un produs de găzduire. Cealaltă jumătate este cum arată propria dumneavoastră factură.

Plătiți pentru capacitate, per tip de resursă, iar un cont de găzduire este unul dintre ele. Fiecare abonament contează, fie că este în funcțiune sau nu; doar unul suspendat nu contează. Acesta este sensul corect pentru relansare. Suspendarea unui client restant eliberează locul în timp ce datele lui rămân neatinse, iar reluarea îl preia din nou.

Depășirea limitei dumneavoastră nu este blocată în momentul în care se produce. Este detectată, vi se spune ce tip de resursă și cu cât, iar dumneavoastră aveți o zi lucrătoare ca să remediați. Dacă aceasta expiră, cele mai noi servere de peste limită sunt oprite, cele mai noi mai întâi, astfel încât ceea ce ați construit primul să supraviețuiască. O a doua depășire în aceeași săptămână primește o oră în loc de o zi, pentru că altfel perioada de grație s-ar putea reînnoi la nesfârșit trecând pe sub limită și depășind-o din nou. Nimic nu este repornit în locul dumneavoastră când este rezolvată: a porni o mașină este o decizie, iar platforma nu o ia în timp ce nimeni nu se uită.

Fiecare perioadă produce o proformă pe care o puteți citi și tipări, factura definitivă sosind din contabilitate sub forma unui fișier. O linie de factură consemnează numele pachetului așa cum era el în momentul facturării, așa că redenumirea unui plan ulterior nu rescrie istoria.

Ce face Provibr și ce nu face în mod deliberat

Provibr se așază între facturarea dumneavoastră și serverul dumneavoastră Plesk. Un abonament este un rând obișnuit: comandați-l, suspendați-l, reluați-l, schimbați-i planul de serviciu, ștergeți-l. Suspendarea trece prin câmpul pe care îl citește interogarea. Planul este rezolvat înainte de creare, iar o creare eșuată este curățată. Fiecare modificare se încheie prin recitirea abonamentului, astfel încât ceea ce este stocat să fie ceea ce a fost observat, nu ceea ce a fost cerut. Agentul se conectează spre exterior din propria dumneavoastră rețea, astfel încât portul 8443 nu trebuie să fie expus către internet.

Ce nu face: să gestioneze serverul Plesk însuși sau să pătrundă în interiorul unui abonament. De asemenea, nu îi cere niciodată Plesk seturile de date care conțin parola FTP sau hash-ul parolei clientului, pe care panoul le predă pe amândouă în text clar dacă le cereți.

De citit în continuare

• Cum să vindeți găzduire web cu Plesk: modelul de produs, cele două API-uri și ce nu cerem niciodată panoului.
• Facturare și licență: capacitatea, prețul pe paliere, creditul, proformele și ce se întâmplă la depășirea limitei.
• Configurarea Plesk: cheia API, planurile de serviciu, planurile web și importul abonamentelor.

Măsurat pe Plesk Obsidian 18.0.80 în august 2026, cu răspunsurile înregistrate ca fixtures. Suspendarea repetată, cheile limitate la un revânzător și comportamentul sub o sarcină reală de trafic nu au fost măsurate și sunt notate ca atare mai sus.