Korábban már sokat írtam egy Exchange migrációról. Röviden összefoglalva: van egy Active Directory, ebben pedig egy több szerverből álló Exchange 5.5 organizáció, melyhez kapcsolódnak az AIX alapú rendszerek is. Az internet felé Symantec SMTP Gateway biztosítja a kijáratot.
Vázlatosan: Internet – SMTPGW – Exchange5.5 (+Outlook kliensek) – AIX.
A migráció célja a középső rész Exchange2003-ra történő cseréje volt.
Ez valamikor tavaly augusztusban kezdődött, decemberben volt a nagy ugrás és a folyamat idén februárban ért véget. Gondoltam én.
Május első hetében kaptunk egy bejelentést az ügyfél fejlesztőitől, hogy az adatbáziskezelő rendszerükből automatikusan generált levelek januári dátummal mennek ki. Megnéztem, a levél belsejében (data mező) lévő dátum tényleg rossz volt. A borítékra viszont már minden szerver a jó dátumot pecsételte rá. Visszadobtam a bejelentést, hogy tessék már egy kicsit a saját ház előtt sertepertélni, mert a levél összerakásakor történik valami a dátummal.
Megnézték a szervereik dátumait, közölték, hogy az bizony jó. Erre megírtam a kedvenc nagymamás hasonlatomat:
A nagyi remegő kezekkel odabiggyeszti levele végére a keltezést, becsúsztatja a lapot a borítékba, leragasztja, bélyeget nyal rá és feladja a postán. Szállítás közben az összes postahivatal rápecsételi bélyegzőjét a levélre. A címzett kibontja és megdöbbenve látja, hogy rossz dátum van a levél végén. Bemegy reklamálni a postahivatalba és csodálkozik, hogy a postások kórusban kiröhögik.
Azt a választ kaptam, hogy náluk fejlesztés van, nem kupleráj. Minden változtatás változásmenedzsmenten keresztül történik és az utóbbi hetekben nem változtattak semmit. Ergo az Exchange hülyült meg. Oldjam meg a feladatot. (Ilyenkor szívja a fogát egy MS adminisztrátor – ugyanis fogalma sincs arról, hogy mije változott a rendszerében azáltal, hogy szorgalmasan pecselgeti – ergo nem mondhatja azt, hogy nálam sem változott semmi, beee.)
Nos, itt már egy kicsit izzottak a vonalak, a probléma felszivárgott a középvezetők szintjére. Én váltig állítottam a saját középvezetőim felé, hogy tkp. a fejlesztők azt szeretnék, hogy mi végezzük el az ő munkájukat; a fejlesztők pedig meggyőzték a saját főnökeiket, hogy eszkaláltassák velünk a problémát a Microsoft felé, ha már mi ilyen bénák vagyunk.
Épp itt volt az ideje mélyebben elgondolkodni, hogy mi is történhet itt tulajdonképpen. A fő gubanc az, hogy a probléma két rendszer találkozási pontján keletkezik és egyik rendszer szakértője sincs képben, hogy mi van a másik oldalon. Megtettem az első lépést, megírtam a fejlesztőknek, hogy _szerintem_ hogyan működik a rendszerük. Egész jól tippeltem, alig kellett korrigálniuk: eszerint az adatok Oracle adatbázisokban vannak, ezeket AIX-en hajtja egy Oracle motor. A leveleket egy gyári Oracle modul készíti el és tolja bele szabványos SMTP-n keresztül a levelezőszerverbe – mely MX rekord alapján az Exchange2003 virtuális SMTP szervere.
Nem tehetek róla, de ha meghallom, hogy ‘szabványos SMTP’, akkor nekem mindig telnetelhetnékem van. Saját gépről kipróbáltam, nem írtam a data blokkba dátumot és ennek ellenére a levélben benne volt a jó dátum. Innentől akár fel is dughattam magamnak a nagymama-hasonlatot, mert nem igaz: ha az első SMTP host (ahol a levél készül) nem talál dátumot a data-ban, akkor beleteszi a saját átvételi dátumát – azaz a postás bizony beleír a levélbe. Közben a fejlesztők is letesztelték, hogy mi történik, ha nem raknak az adatbázisuk dátum mezőjébe semmit – a levelek gyönyörűen megérkeztek, jó dátummal.
Vov: a workaround előállt. Valahol megnyugodtam – velem együtt a főnökeim is -, mert innentől kezdve a napnál is világosabb volt, hogy a fejlesztők adnak át rossz dátumot. De a fiúk nem nyugodtak. Főnökük kifejezetten ingerült levelet küldött, hogy _ök_nem_változtattak_semmit és már napok óta levelezünk, de senki nem vette a fáradtságot, hogy letolja a képét hozzájuk. Az én agyam itt dobta le a szíjat – simogassam meg a szerverüket?! -, és mivel volt egy lezárásközeli projektem, mely akkor már a harmadik határidőmódosítást szenvedte el, megkértem a főnökömet, hogy legyen kedves, priorizálja a feladataimat. Ő is úgy gondolta, hogy inkább az egyre cikisebb projektet zárjam le, a fejlesztőkhöz meg majd lemegy egy helyi emberünk és megcirógatja őket. Helyi emberünk nem sokat tökölt: megkérdezte, kipróbálták-e, hogy mondjuk júniusi dátumot írnak az adatbázisba. Beírták, jó lett. Hoppá.
Persze az eredményt értelmezni is kellett. Íme a megoldás:
Kiderült, hogy az alkalmazásuk, melynek része a levélküldő modul is, magyar nyelvű – tehát az adatbázisban lévő dátum is magyar formában jön ki az Oracle modulból. Rakjuk csak egymás mellé az angol és a magyar formát.
Dec – Dec – oké
Jan – Jan – oké
Feb – Feb – oké
Mar – Már – bejött egy ékezethiba
Apr – Ápr – bejött egy ékezethiba
May – Máj – hoppá, ékezethiba és karakterhiba
Jun – Jún – sima ékezethiba.
Mint látható, a Microsoft SMTP szerver, amikor összerakja a leveleket, az ékezethibákat még le tudja kezelni – de az ‘y’ helyett a ‘j’-t már nem. És május elsején megzakkant a belső dátum generáló algoritmusa és a hónapot januárra javította. A fejlesztők angolra állították a kritikus dátum formátumát és egyből megjavult a májusi levelezés is.
Most akkor mégis az Exchange szerver a hülye? A látszat – és a fejlesztők is – ezen a véleményen vannak. Én – már csak a mundér becsületének megóvása érdekében is -, visszaírtam, hogy ugye tudják, hogy a levél ‘forráskódjának’ formai szabályai vannak… és ezen szabályok szerint a data SMTP parancson belül a dátum szabvány szerint angol formátumú; és nem érdekel, hogy ők, vagy az Oracle modul, de legyenek kedvesek igazodni a szabványhoz.
Viszont van itt valami, ami miatt igazából tartani kellene a pofámat: a korábbi Exchange 5.5 szerver IMS megvalósítása valahogy megbírkózott a feladattal. Gondolom, megnézte, hogy milyen nyelvi támogatások vannak a rendszerben és azok alapján próbálta meg értelmezni az ismeretlen hónapneveket.
A 2003 már bekeményített. Nyilván lehet mögé ideológiát gyártani, de tény, hogy már a sokadik sunyi változtatást szívjuk meg azzal, hogy az öreg SMTP motort a fejlett újra cseréltük.
Recent Comments