Dolibarr Webhook: automatizálás kézi másolás helyett
A rendelés elkészült. Miért másoljuk még mindig kézzel a következő rendszerbe?
A Dolibarr beépített Webhook modulja üzleti eseményből indíthat külső automatizálást. Saját példa, bevezetési próba és a megbízható feldolgozás feltételei.
Az értékesítő rögzít egy rendelést, majd átmásolja az adatokat egy másik alkalmazásba. A kolléga üzenetet ír róla, valaki pedig újra begépeli a partner nevét. A Dolibarrban már megtörtént az üzleti esemény, a következő lépés mégis egy ember emlékezetén múlik. A Webhook modul éppen ennél az átadásnál lehet érdekes.
Az ERP szólhat, amikor történik valami
A hivatalos Webhook-dokumentáció szerint a modul egy kiválasztott Dolibarr-esemény hatására JSON-üzenetet küld egy külső URL-re. A Dolibarr része, külön csomagot nem kell telepíteni. Adminisztrátorként a modulbeállításokban aktiválható; utána célcímet és egy vagy több triggereseményt kell megadni. Az üzenet az esemény kódját és az érintett objektum adatait tartalmazza.
Ez egy meglévő funkció gyakorlati bemutatója, nem új kiadás bejelentése. Az érdekes lehetőség az, hogy az ERP-ben elvégzett munkát egy másik rendszer felé is jelezhetjük.
Egy partnerfelvétel, két rendszer, egyetlen adatbevitel
Az alábbi saját, kitalált példa egy szolgáltató vállalkozásról szól. Új partnert hoznak létre a Dolibarrban, és a belső ügyfélfogadó alkalmazásban is szükség lenne egy előkészítő feladatra.
- A munkatárs felveszi a partnert a Dolibarrban.
- A Webhook a beállított partnerlétrehozási eseményt elküldi a fogadó végpontnak. A dokumentáció példájában ennek kódja
COMPANY_CREATE. - A saját integráció kiválasztja a szükséges adatokat, és létrehoz egy előkészítő feladatot a másik alkalmazásban.
- A kijelölt kolléga ellenőrzi a feladatot, mielőtt elindul az ügyfél kiszolgálása.
A harmadik és negyedik lépés a javasolt folyamat része: a fogadó alkalmazást és annak szabályait külön kell megvalósítani. Egy célcím megadása önmagában még nem hozza létre a másik rendszer munkafolyamatát.
Miért külön kérdés az elküldés és az elvégzett munka?
Tervezési szempontként érdemes végiggondolni: mi történjen, ha a másik alkalmazás éppen nem működik, vagy ugyanazt az üzenetet ismét feldolgozza? Az alábbi megoldások saját integrációs ajánlások; nem a beépített modul dokumentált kézbesítési garanciái.
| Helyzet | Javasolt működés |
|---|---|
| Kétszer érkezik ugyanaz a létrehozási jelzés | A forrásrendszer, az eseménykód és a partnerazonosító alapján ismerjük fel a már létrehozott feladatot. |
| A célalkalmazás nem elérhető | Legyen követhető hiba és felelőse az újrafeldolgozásnak; ahol szükséges, építsünk tartós várólistát. |
| Hiányzik egy kötelező adat | Kerüljön javításra váró állapotba az ügy, látható indoklással. |
| Sikeres az átvétel, de nincs kész a feladat | Külön jelöljük az üzenet fogadását és az üzleti feldolgozás eredményét. |
Az ismétlődés felismerésére adott példa egy egyszeri partnerlétrehozáshoz illik. Módosításoknál ugyanaz a partner többször is jogszerűen változhat, ezért ott eseményenkénti azonosításra vagy más, külön megtervezett szabályra lehet szükség.
Mennyi adatot adjunk tovább?
A dokumentáció mintaobjektuma belső megjegyzésekhez tartozó mezőket is felsorol. Ezért a próba során a ténylegesen küldött adatokat is nézzük meg, és csak olyan fogadó szolgáltatást válasszunk, amelynek ezeket átadhatjuk. A további rendszerek felé az integráció már csak a feladathoz szükséges mezőket továbbítsa. A célvégpont védelmét és a hitelesítés lehetőségeit a használt verzióval együtt ellenőrizzük.
Egy délelőttös próba, amelyből valódi döntés születhet
Kezdjünk tesztkörnyezetben, kitalált partneradatokkal és egyetlen eseménnyel. Hozzunk létre egy tesztpartnert, ellenőrizzük az üzenetet, majd nézzük meg a fogadó rendszer feladatát. Ezután a fogadó oldalon próbáljuk ki ugyanannak a tesztüzenetnek az ismételt feldolgozását és egy hiányos adat esetét is.
A próba akkor ad használható eredményt, ha meg tudjuk mondani, melyik partnerből melyik feladat készült, melyik ügy akadt el, és ki intézi. A megtakarítást is a saját munkán mérjük: hány kézi másolás és egyeztető üzenet maradt el? Az automatizálás értékét ebből lehet megítélni.
Webhook, trigger vagy API?
A hivatalos integrációs áttekintő külön tárgyalja a Dolibarrban saját kódot futtató triggereket, a bővítési pontokat adó hookokat és a külső URL-re üzenő Webhook modult. A külső rendszerből indított Dolibarr-adatelérés a kapcsolat másik iránya. A választást ezért azzal kezdjük, hol történik az esemény, és melyik rendszerben kell utána munkát végezni.
A következő lépéshez olvassa el a magyar webhook-útmutatót és a Dolibarr-munkafolyamatokról szóló cikkünket.
Források
- Dolibarr Wiki: Module Webhook – beépített modul, aktiválás, célcímek és üzenetminta.
- Dolibarr Wiki: Interfaces Dolibarr toward foreign systems – az integrációs mechanizmusok szerepe.
Forrásellenőrzés: 2026. október 16. A vállalkozási példa, a feldolgozási javaslatok és a próbalépések saját szerkesztőségi kiegészítések. Éles integrációs tesztet a cikk nem állít.
Címkék: Dolibarr · Webhook · automatizálás · integráció · adatbevitel · KKV
Nézze meg, milyen Dolibarr-folyamat illeszkedhet a vállalkozásához, vagy küldje el röviden a saját helyzetét.
Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.