SAP Business One Web Service

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. :-)

1 Like

É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.

Dehát kizártnak tartom, hogy ti vagytok az első cég, ahol ilyen igény felmerül. Most kell ezt tákolni?

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.

Ó jaj…

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.

Ez így nagyon nem jól hangzik.

Mondjuk az, hogy egy web service-t egyszerre négyen hivogatnak, meg nem tekinthető durva terhelésnek. Biztos nem valami konfig para?

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

Ezt fizikailag nem tudom elképzelni. Az MS SQL a legkomolyabb adatbázisszerver.

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.

Ez tuti nem a SAP hibája.

https://help.sap.com/saphelp_nw74/helpdata/en/48/9ab14248c673e8e10000000a42189b/content.htm

De ezt hogy??? Mármint értem, hogy technikailag hogyan, de hogy jut ilyen valakinek eszébe?

Meg kell védenem az SAP-t. Pedig utálom. De ez nem az ő sara.

Amennyire sikerült felfognom eddig:

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.

Ez?

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

1 Like

Ezt még azért a végére:

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.

Egy leheletnyit becsapva érzem magam.

1 Like