SAP kalandok

Cégnél (KKV 16 fő) SAP Business One-t használunk vállalatirányításra és egy PPSOne nevű plugint gyártástervezésre.

Jött egy kérdés, amihez némi SQL-t kellett túrni és naná hát nézzük meg mi baj lehet.

Az első sokk akkor ért, amikor megláttam, hogy az SAP 4 betűs táblaneveket használ ilyen >100 táblára.

https://wiki.scn.sap.com/wiki/display/B1/SAP+Business+One+Tables

Oké biztos így optimalizálták az SQL queryk méretét, vagy tudja a tököm.

De! Amikor szembe jön veled a PPSOne táblákban az, hogy a creating user az nvarchar(100) típusú mezőben van eltárolva akkor konkrétan elsírtam magam. Cikkszámok dettó mindenhol szövegesen vannak tárolva.

( SzBlackY | 2017. 01. 13., p – 20:27 )

Az SAP-t én ott adtam fel, amikor nézegettem, hogy hogyan működik a hálózaton és megtaláltam ezt a mondatot:

The SAP Protocol is the protocol used by SAP programs that communicate using the NI interface. This is an enhanced version of the TCP/IP protocol, which has been extended by one field and some options for error information.

(kiemelés tőlem - forrás: https://support.sap.com/content/dam/library/SAP%20Support%20Portal/remo…)

Többé-kevésbé bullshitnek néztem első nekifutásra (bár _elvileg_ van néhány nem standardizélt bitnyi hely a fejlécekben, de hogy az A-ból B-be helyesen el is jusson, majdnem biztos vagyok, hogy nem, ill. belenéznék pl. egy Java implementációba, ami TCP header-öket ír-olvas platform-függetlenül, sima userként). Aztán gondoltam belenézek egy kicsit wiresharkkal, hogy ténylegesen mit küld, de amikor plaintextben megláttam a gép NetBIOS nevét egy egyébként direkt a remote accessre kitalált SAPRouter-nek küldött csomagban, úgy döntöttem, hogy soha többet. És most amíg kerestem a fenti doksit, találtam egy másikat, ami szerint semmi titkosítás nincs a SAP protokollokon és az opcionális 3rd party cuccokat meg kevesen használják (https://yurichev.com/non-wiki-files/blog/SAP/sniffing_diag.pdf), csak valami proprietary módon tömörítve vannak... oh, és a jelszót simán plaintext küldi, úgyhogy amint kitömöríted, ott van.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( uid_4263 v | 2017. 01. 14., szo – 08:34 )

Van egy elmélet, ami szerint a SAP a németek bosszúja a WW2 miatt.

De egy kicsit vissza a szakmára: szerencsém volt hozzá egy ~2 éves projektben társbeszállitóként (user törzs kezelése, webservice-ek biztositása).
Hát mondjuk hogy voltak kalandok. Például tud XML/XSD/WSDL témát, de rakás limitációval:
- a 4+ éves schema 1.1 -et nem ismeri
- a fogadott XML doksi nem lehet 9 child layernél mélyebb (azért mert a WS provider a fogadott doksit rögtön leboritja valami db táblába (igen, abba), és hogy ne legyen végtelen sok oszlop, azt mondták hogy 9)
- stb

--
arch,debian,retropie,osmc,android,windows

( uid_17626 | 2017. 01. 15., v – 20:22 )

"Cikkszámok dettó mindenhol szövegesen vannak tárolva."

Ezt meg kell védenem. Vakon mondom, hogy user igény. Nagyon sok helyen a cikkszámba egyénileg "belekódolnak" pl beszerzési forrást vagy olyan adatot amire nincs mező, de szeretnék látni.

+1
Cikkszámnak hívjuk, közben cikk azonosítóra gondolunk.
Van ahol egyszerű folyó sorszám, van ahol különböző pozíciók más-más jelentéssel bírnak, nem beszélve a különböző állapot jelzőkről, vagy katalógusokból átemelet gyári azonosítókról

Elcsesztem... eggyel alá, bennyh válaszára ment volna.

gy

És akkor mi van?
Sehol nem írja elő semmi, hogy elsődleges kulcsnak sorszámnak kell lennie, ez egy eléggé buta berögződés. A cikkek táblában a cikkszám az ID. És szöveges. Now what?

Képzelj el egy kapcsolótáblát, például ami cikkszámhoz és rendelésazonosítóhoz rendel rendelési mennyiséget.
A valóságban ez úgy megy, hogy van az ABCDEF1234 cikkszámú árucikk, és mondjuk a 201701345 rendelésazonosító, és egy mennyiség: 5.

Sokkal több értelme van (a valóságot modellezi), hogy a kapcsolótáblában egymás mellett látod az ABCDEF1234-201701345 elemeket és az 5 értéket, mintha egy táblabeli sorszámot (5-8-5) látnál. A sorszámnak nincs SEMMI jelentése önmagában, akkor kell használni, ha a valóságban is sorszámot kell használni.
Szerintem hülyeség surrogate keyekkel (mert így hívják ezt) teletömni a DB-t. Ugyanis maga a valós életbeli adatmodell sem dolgozik surrogate keyekkel.