SAP Business One, 20 millió forint. És kiderül, hogy a dokumentumok lefűzése gyakorlatilag egy szálon fut és API-n keresztüli tömeges dokumentum létrehozás a hardware képességeitől függetlenül megfogja a rendszert.
Most kitalálták, hogy akkor beleprogramoznak a tömeges dokumentum létrehozásba várakozásokat, hogy addig a többi felhasználó is dolgozhasson. Jobb időben ezt co-operativ multitaskingnak hívták.
Ha valaki programozott Mac OS 9-re, ez maga az event loop és a WaitNextEvent reinkarnációja. :-)
Én az SAP-t csak használtma mint felhazsnáló (raktárban), a világ legotvarabb programja szerintem. Borzalom volt az egész, a régebbi dos-os saját raktárprogramunk minden tekintetben jobb volt. Persze azt nem tudták eladni XX millióért évente.
Mi most fogunk elindítani egy webshopot, aminek gyakorlatilag nem lesz saját adatbázisa, mindent az SAP-ból vesz és ír vissza API-n keresztül. Kezdek félni.
Boschban használtam (eger) sírtam tőle. Egy olyan raktár program miben egérhez kell nyulni ki vagy bekönyveléshez már alapban egy nulla. DE egy tételhez mindim 20at kell kattintatni.
Akedvencem a jobb felsősarokban lévő 16színű animgif animáció :D (nem tudom ott van e még) valami síralmas.
A bevezető egy magyar kft. nem kizárt, hogy náluk ilyen többirányú API felhasználás eddig nem volt jellemző. Nálunk most egyszerre legalább 4 helyről érkeznek be API-n dokumentumok az SAP-ba párhuzamosan.
Azt el tudom fogadni, hogy ronda, azt el tudom fogadni, hogy PC-s, nehezen de lenyelem, hogy nehézkesen használható, DE hogy egy X milliós hardware-en ülve, egy MS SQL szerverrel maga alatt nem lehet párhuzamosan gyakorlatilag végtelen számú dokumentumot létrehozni benne, ezt nehéz megemészteni.
Olyan probléma van, hogy a készpénzes fizetéshez nem rögzíti hozzá a pénztári bizonylatot. Ott marad nyitva, mintha az ügyfél nem fizetett volna. És akkor lehet este SQL-ből keresni a nyitott készpénzes számlákat.
Lassan kell tartani a dolgozóknak egy alap SQL tanfolyamot. :-P
Az a baj, hogy vannak a gyári SAP folyamatok, amelyek tranzakciókba vannak rakva. És minden egyedi fejlesztés ezeken a tranzakciókon kívül kerül végrehajtásra, pedig sok esetben az eredeti SAP tranzakcióban kellene lennie ezeknek a folyamatoknak, különben az adatbázis inkonzisztens állapotba kerülhet.
Ez ma ki lett nyögve. Csak ha ezzel kezdik, akkor kicsit óvatosabban fejlesztetünk velük “add-on”-okat.
Az összes SAP szolgáltatás alatt van egy DI API nevű szolgáltatás, ami az összes az SAP-ban beállított feltételt ellenőrzi a beküldött dokumentumokban. Egyfajta absztrakciós réteg. Az interneten egyesek azt állítják, hogy bizony egy egy szálon fut. És a bevezető cég szerint is itt van a szűk keresztmetszet.
Ugyanakkor én sem hiszem el, hogy ez csak így működhet SAP-ban. Magasabb szinteken, ha más nem queue-knak kellene lennie, hogy a beérkező kéréseket eltárolja, amíg a DI API fel nem dolgozza az előtte lévőket. De nem vagyok SAP szakértő és egyre kevésbé bízom a bevezető cégben. Amit most az addon-jaik csinálnak az egyenlő a találgatással, az idő nagy részében jó lesz és néha nem.
Az SAP a világ egyik legnagyobb vállalatirányítási szoftvere. Kizárt, hogy négy darab store-ból érkező párhuzamos requestek megfektessék. Nem tudom elképzelni.
Csak az API-n keresztül érkező dokumentumok a problémásak. A boltok által generáltak nem, már ha a DI-API-t nem fogja épp le valami.
Igen, ezt az oldalt én is megtaláltam. Csak reméltem, hogy nem kell SAP fejlesztővé avanzsálnom, hanem a jófizetett szakértőink megoldják.
Bár már egy many-to-many kapcsolat is megfektette őket. :-P Ott kezdett gyanús lenni az egész.
@esojaro Ne fáradj vele, úgysem hagyom kiadni így a teljesítési igazolást nekik, amíg rendes munkát nem végeztek. Legalábbis felhívom a vezetés figyelmét ezekre.
Csukd be a gépet és igyál egy sört. :) Teljesen igazad van, te a megrendelő vagy, neked csak annyit kell mondanod, hogy ‘Eredményeket akarok, Safranek!’ :D
Ennek a fordította azért még rosszabb, hogy vannak olyan cégek, ahová ugyanezen emberek bevezették az SAP-t, ugyanezekkel a problémákkal, csak még rá sem ébredtek, hogy lehetnek problémáik.
Persze ők is mondták az elején, hogy “ne állítsuk fejre az SAP-t”, de ez nem lett technikailag kifejtve, hogy az mért lenne rossz. Ha azt mondják, hogy ez inkonzisztenciát okozhat az adatbázisban, mert nem lehet olyan szinten hosszáfejleszteni az SAP-hoz, akkor tudomásul vesszük és kész.