ugrás a tartalomhoz

Összetett folyamat hibakezelése

Max Logan · 2011. Júl. 8. (P), 11.03
Adott egy összetett folyamat, jelen esetben egy megrendelés feladás. Ezen folyamat kapcsán nem igazán tudom, hogy mi lenne a jó megoldás a hibakezelésre.

A felállás: adott egy rendszer, melyben a felhasználó összeállít egy megrendelést. A megrendelés első körben elmegy SOAP kérésként. Ha a SOAP hívás sikeres, akkor létre kell hozni egy PDF dokumentumot a megrendelésből, majd ezt letárolni fájl szinten. Ezt követőn egy e-mail csatolmányaként ki kell küldeni a PDF-et. Majd ezt követően a megrendelés végösszegével növelni kell egy counter-t (amit aztán a rendszer egy másik funkciója használ majd).

Ez az egész tekinthető egy megrendelési folyamatnak. Ha mind a SOAP kérés (helyi hálón, másik szerver felé), mind a fájl letárolás (local), mind az e-mail küldés (SMTP-n keresztül), mind a counter növelése (DB szerver, szintén helyi hálóban másik szerveren) sikeresen megtörtént, akkor joggal mondhatom, hogy a megrendelési procedúra sikeres volt.

De mi van akkor, ha mondjuk a SOAP kérés sikeres, de a PDF fájlba mentése már nem ok. Ekkor nem tudom e-mailben küldeni, ami szükségszerű lépés lenne, mert akkor teljes a folyamat, ha az is megvan.

Mi ilyenkor a célszerű megoldás? Az egész folyamatot kezeljem "tranzakcióként" és csak akkor mondjam, hogy sikeres mentés, ha tényleg minden művelet sikeres volt (ekkor pl. kellene a SOAP hívás visszavonhatósága, ami jelenleg pl. megoldhatatlan)? Vagy?

Van erre valami irodalom, hogy ilyen komplex megoldások (folyamatok) esetén miképpen kell/célszerű eljárni? Vagy minden eset más és más és az adott folyamat esetén magunknak kell felállítani, hogy mit miképpen kezelünk le?
 
1

A Distributed Transaction

H.Z. v2 · 2011. Júl. 8. (P), 11.32
A Distributed Transaction kifejezés mond neked valamit? Ha nem, akkor lehet, hogy ez az, amit keresel.
(ha ismered, akkor én nem fogtam fel a problémád lényegét)
2

Ez lesz az

Max Logan · 2011. Júl. 8. (P), 11.41
Igen, azt hiszem ez lesz az, amire gondolok.
3

Tranzakció

tisch.david · 2011. Júl. 8. (P), 14.21
Szia Norbert!

Nem vagyok nagy mágusa a "Distributed Transaction" féle bűvszavaknak, úgyhogy csak a józan paraszti ész alapján mondom:
szerintem ilyen esetben, amikor a feladat csak minden részfeladat eredményes lefutása után tekinthető eredményesnek, akkor ezt egy tranzakcióként kell kezelni. Ilyenkor hiba esetén vagy vissza kell tudni görgetni az egyes lépéseket, mintha semmi se történt volna, vagy az egyes részfolyamatok eredményét csak akkor véglegesíteni, amikor az utolsó részfolyamat is rendben befejeződött. Más lehetőség szerintem nincs.

Üdv:

Dávid
4

Re

Max Logan · 2011. Júl. 8. (P), 14.57
Nos igen. Az igazság az, hogy az igények technológia tekintetében egyre magasabbak a melónál, viszont a lehetőségek elég korlátozottak bizonyos tekintetben.
5

Visszagörgetés helyett újra próbálkozás

Poetro · 2011. Júl. 8. (P), 15.48
Én még megpróbálnék berakni egy számlálót feladatonként, mondjuk mindegyikkel próbálkozzon háromszor, és csak ezután feladni, visszagörgetni, jelenteni az adminnak / felhasználónak, hogy kérem itt egy komoly probléma történt. Főleg abban az esetben ha harmadik fél is játszik az egyenletben, ami felett nincs irányításunk.
6

Hasonló

janoszen · 2011. Júl. 9. (Szo), 01.20
Azt kel mondjam, hogy a probléma nagyon is ismerős, én a munkám során rengeteg külső szolgáltató által üzemeltetett API-val találkozom. Ezek közül nem mindegyik van olyan szuperül megtervezve vagy kivitelezve, hogy teljesítse a "Distributed Transaction" követelményeit.

Most megoldásként az tűnik szimpatikusnak és egyelőre járhatónak is, hogy a rendszer a feladatokat egy workflow rendszerben dolgozza fel. Erre a célra azt hiszem, Tyrael ajánlotta Apache Zeta Components szoftvert, ami egészen jól csinálja a dolgát, viszont kell hozzá ezt-azt telepíteni a gépre.

A workflow rendszernek köszönhetően a műveleteink nem mint egy adatbázis tranzakció részei látszanak, hanem sok apró feladatként, amelyekhez mind-mind meg kell írni a saját hibakezelést. Ez ugyan némileg több meló, mint egy egyszerű rollback parancs, de az egységek önállóan tesztelhetőek és meglehetősen robusztusak lesznek.

Ami a hibakezelést illeti, a fenti egységek saját hibakezelésén felül a workflow rendszernek is van egy hibakezelése, ami az újrapróbálkozás és az operátori beavatkozás keverékeként áll össze.

Amellett, hogy a rendszer meglehetősen robusztus, van még egy előnye a dolognak. Ha az egyes részegységek úgy vannak megírva, akkor azokat akár külön gépen és adatbázison is üzemeltetheted, aminek köszönhetően skálázható(bb) lesz a rendszered és nem fogsz olyanba belefutni, hogy egy-egy bonyolult, rosszul megírt query megfogja egy csomó modul működését.
7

Hibakezelés a végletekig

Max Logan · 2011. Júl. 11. (H), 08.30
Nem tudom, hogy én vagyok-e nagyon paranoiás, de mi van abban az esetben, ha mondjuk egy ilyen műveletsor esetén szeretnék file alapú naplózást csinálni a hibákról, de a file létrehozása közben is hiba lép fel.

Ekkor -- nem vagyok bennne biztos -- talán a php error logban látom annak tényét, hogy hiba történt a fájl létrehozása közben, de a folyamat közben fellépett hibáról nem kapok értesítés (mivel nem jön létre vagy nem bővíthető a hibanapló file).

Van arra valami megoldás, hogy 100%-os legyen egy ilyen hibakezelési folyamat, vagy túlzottan maximalista vagyok és ez lényegében megoldhatatlan? Ha utóbbi, akkor mi az ami maximálisan kivitelezhető?
8

Én olyat csináltam,

deejayy · 2011. Júl. 11. (H), 11.50
Én olyat csináltam, hogy

register_shutdown_function('error_handler_shutdown');
function error_handler_shutdown() {
  ...
}
Ez ugye akkor hajtódik végre, amikor a php script végez (akár hibával, akár nem, ha van hiba, logolom).
Egyszer elírtam egy függvénynevet ebben a kezelőben, és a script csak simán megállt, semmi hibaüzenet, csak úgy vége.

Ha az error kezelőben vétesz hibát, akkor ez a függvény még végrehajtódik, tehát érdemes a legvégső hiba kezelését ebbe tenni.