Írta Ana Canteli 2022 április 29-én
Az alkalmazásintegrációs projektek olyan célok, amelyet előbb utóbb minden szervezet elkíván érni. Kezdetben a vállalat által használt alkalmazások rendelkezésre bocsátása, illetve konfigurálása intuitívan történik. A vállalat tagjai a vonzó ajánlatok és hatékony marketingakciók helyett inkább korábbi tapasztalataikra támaszkodva építik fel azokat.
Idővel azonban a munkavállalók és a vezetők is felismerik, hogy milyen gyakorlati és alternatív költségekkel jár az, ha nem fektetnek be a rendszerek közötti átjárhatóságba. A felhasználók így kénytelenek kétszer vagy akár háromszor is alkalmazást váltani az információk begyűjtéséhez, majd adatokat átvinni egyik oldalról a másikra, hogy tovább folytathassák a munkát. Ez a folyamat magában foglalja a következő veszélyeket is: hanyagság, megfelelőség hiánya, adatvédelmi kockázat, információvesztés, hogy csak néhányat említsünk.
Ennek ellenére nem ritka, hogy a vállalatok ERP-t és dokumentumkezelő rendszert is használnak. Bár elsőre úgy tűnhet, hogy a két szoftver átfedésben van egymással, mégis integrációjukból számtalan előny származhat.
Azonnali hozzáférés: az integrációnak köszönhetően a felhasználó könnyedén indíthat az alkalmazásból egy üzleti folyamatot, tudva, hogy a vállalat alkalmazásplatformja segíteni fogja őt a gyors és egyszerű munkavégzésben.
Időoptimalizálás:az interoperabilitás javulásából származó előnyöknek köszönhetően jelentősen csökken a lekérdezésekre, valamint a fájlok keresésére, fordított idő.
Jobb nyomon követhetőség: egy integrált szoftver csomag javíthatja a dokumentáció nyomon követhetőséget, valamint azok ellenőrzését.
Kifinomult folyamatok javítása: például riportok és mérőszámok javítása, illetve dokumentum vagy tároló megsemmisítési folyamatok. Az integrációnak köszönhetően ezek a célok globális szinten elérhetők.
Az integráció lehetőségeinek, sőt alkalmasságának mérlegelésekor számos tényezőt kell figyelembe venni.
Először is kezdjük azzal, hogy ideális esetben a humán erőforrások rendelkeznek bizonyos fokú tapasztalattal, mind műszaki, mind végfelhasználói szempontból, hogy meg tudják határozni a kiindulási pontokat, a célokat, a kitűzendő mérföldkövek műszaki, valamint humánerőforrás igényét és időráfordítását.
A következő szempont, amelyet érdemes figyelembe venni az a megoldások dokumentáltsága. Minden valamire való ERP és dokumentumkezelő rendszer rendelkezik olyan lehetőségekkel, amelyek megkönnyítik a harmadik felekkel való integrációt. Az OpenKM egy olyan dokumentumkezelő rendszer, amely az OpenKM tudásközpontján keresztül teszi elérhetővé a rendelkezésre álló erőforrások készletét, így könnyedén bővítheti a dokumentumkezelő rendszer funkcióit és lehetőségeit. Ugyanezt kell elvárni az ERP szolgáltatójától is.
Az OpenKM csapata nagy tapasztalattal rendelkezik az integrációs projektek terén és szakembereink felkészültek az integrációs feladatok elvégzésére.
Mivel számos különböző forgatókönyv előfordulhat, ezért ebben a cikkünkben csak a legkritikusabb eseményekkel foglalkozunk.
Az OpenKM Kcenterben hozzáférést biztosítunk a dokumentumkezelő rendszer teljes API-jához. Továbbá a Java, .NET és NodeJS SDK-khoz. PHP esetében az ügyfelek kérésére példákat is biztosítunk.
Ahogy fentebb említettük, az integrációkra többféle forgatókönyv létezik.
Tételezzük fel, hogy van egy ERP rendszerünk, ahol a szervezet a számlákat, illetve szállítóleveleket stb. kezeli. Az első integrációs lehetőségünk a megosztott mappák révén lehetséges. Ebbe a megosztott mappába az ERP bizonyos dokumentumokat és a hozzájuk tartozó CSV fájlokat helyezi el. Az OpenKM pedig periodikusan egy folyamat révén beolvassa ezeket a megosztott mappában lévő tartalmakat, így végül bekerül a dokumentumkezelő rendszerbe.
Ebben a szcenárióban a dokumentumkezelő rendszer helyez el egy CSV fájt, amelyben az adott dokumentum ERP azonosítója található. Ekkor az OpenKM egy olyan cserefájlt generál, amelyben az ERP azonosítója megfeleltethető egy OpenKM-ben tárolt dokumentum UUID (egyedi azonosítójával). A rendszerek közötti integrációs során ezeket az egyedi azonosítókat keressük a megfeleltetés érdekében.
Ha az API-t kívánjuk használni, akkor az eset az ERP által biztosított lehetőségektől is függ; pl. annak programozási nyelvétől. Egyesek lehetővé teszik az OpenKM könyvtárak közvetlen használatát Java, NodeJS és .NET nyelven. Más esetekben azonban az integráció több fejlesztést igényel. ERP alatt itt azt alkalmazást értjük, amelyet integrálni szeretne az OpenKM-mel. Az elvárás az lenne, hogy az ERP alkalmazásnak legyen egy programozott eseménye, amely aktiválódna egy API-híváskor.
Például, ha egy dokumentumot szeretnék feltölteni, akkor a "dokumentum feltöltése" metódust hívná meg. Ezzel feltölthetnénk a dokumentum metaadatait, majd a dokumentumkezelő rendszer erre válaszul visszaküldi a UUID-t, ami az ERP által rögzített azonosító, bár nem kell, hogy ez legyen az egyetlen lehetőség. Ebben a forgatókönyvben az ERP-ben nem tárolunk semmilyen OpenKM azonosítót; csak metaadatokkal dolgozunk (dátum, számlaszám stb.). Ezeket az adatokat az API-n keresztül használhatjuk az információk lekérdezésére.
Az ilyen megoldás alkalmazásakor van néhány kulcstényező, amelyet figyelembe kell venni pl. a fájlok napi mennyisége. Ez határozza meg ugyanis, hogy az integrációt valós időben vagy kötegelt módon érdemes kivitelezni. Például egy pénzintézet, amely naponta kb. 20 000 dokumentumot tölt fel, nem valószínű, hogy a valós időben fogja importálni a dokumentumokat. Elegendő, ha munkaidőn kívül csatlakozik. Ennek a megoldásnak is vannak előnyei, például, hogy a terhelés nem befolyásolja negatívan a hardver teljesítményét valós időben a felhasználók számára.
A teste szabási faktor szintén egy olyan tényező, melyet érdemes figyelembe venni. Az felhasználó nem feltétlenül az OpenKM felületét látja, hanem az API-n keresztül kommunikáló köztes közvetítő alkalmazást.
A legnagyobb potenciállal rendelkező metódus a dokumentumok feltöltése metódus. Ennek hatására az OpenKM létrehozza az elérési útvonalat és beilleszti a dokumentumhoz a metaadatakat. Az OpenKM API használatával a szervezet magas szintű metódusokat hozhat létre. Ha a felhasználó nem a köztes alkalmazást használja, hanem az OpenKM-ben hoz létre dokumentumot, akkor az transzparens módon átláthatóvá válik a plugin architektúrán keresztül.
Gyakorlati példaként említhetjük a személyazonosító okmányok kezelését a közigazgatásban. Ha egy személynek van nemzeti személyazonosító okmánya, akkor a szokásos módszert követik. Ha a személy nem rendelkezik az említett dokumentummal, akkor olyan adatok kérhetők, mint a fénykép, a név, a vezetéknevek, a születési idő és a születési hely. Ezekkel az adatokkal a rendszer létrehozhatja az azonosító okmányt. Ha a személynek van azonosító okmánya, a rendszer válaszol az információkkal.
A dokumentációban megtalálunk minden információt, amire szükségünk van ennek az opciónak a használatához. Ebben az esetben a REST pluginokat kell használni, mivel ezáltal egy olyan osztályt hozhatunk létre és illeszthetünk a szolgáltatásba, amely lehetővé teszi a kívánt feladatok elvégzését. Így elkerülhetjük, hogy 4-5 hívást kelljen intézni az API-hoz, ami bizonyos esetekben jó megoldás lehet, de bonyolultabb feladatok esetén, célszerű összetettebb metódusokat meghívni.
Az e mögött rejlő alapfilozófia az, hogy az OpenKM API rendelkezik például a dokumentumok feltöltésére, illetve a metaadatok hozzáadására alkalmas metódussal, de amikor a dokumentumkezelőt egy másik alkalmazással integráljuk, akkor sokkal jövedelmezőbb lehet egy egyéni API hívás létrehozása, ahol a meghatározott bemenetre a kívánt kimenetet kapjuk. Ha a hívások számát korlátozzuk, akkor optimalizálni tudjuk a teljesítményt, különösen nagy repository-k esetén fontos ez.
Amennyiben további információra van szüksége, vagy egyéb kérdése van az OpenKM-mel való integrációs lehetőségekkel kapcsolatban, forduljon hozzánk bizalommal!