- martonmiklos blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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)
- A hozzászóláshoz be kell jelentkezni
Nice...
- A hozzászóláshoz be kell jelentkezni
Pfff. Komoly.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 14.2 | 4.4.37-janos
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ez az elmélet szöveg nagyon jó!
Kinéz némi külső adat betolása a rendszerbe (nyilván WS-eken keresztül), így előre félek...
- A hozzászóláshoz be kell jelentkezni
ez biztos több dolgot megvilágít: http://www.connexin.net/de/sap-tabellen-uebersicht.html
- A hozzászóláshoz be kell jelentkezni
Köszönöm szépen! Nálunk Business One van ami szerintem valami butított verzió KKV-knak MSSQL-el. Legalábbis amiket én használtam táblanevek ebben nincsenek benne.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
+1, így van
- A hozzászóláshoz be kell jelentkezni
+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
- A hozzászóláshoz be kell jelentkezni
Rosszul fogalmaztam:
Ugye van egy cikkek táblád, ott használsz olyan cikkszámot amilyet kívánsz, majd az ID-re csinálsz idegen kulcsokat a többi táblára.
Na itt az összes PPSOne táblában amit néztem szöveges mezőben volt a cikkszám.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
+1
Mintha a tervezők írtóznának az összetett kulcsoktól, a sorszámok meg úgy is kéznél vannak azzal le van tudva minden...
gy
- A hozzászóláshoz be kell jelentkezni