Bejegyzés

A SyX-ekkel megint nyerők leszünk (Exchange Server)

A SyX beépülőkkel kapcsolatos fejlesztések nagy sikert aratnak. Hogy miért? Egyszerűen azért, mert a dolgokat meg lehet velük csinálni. Nem tudunk (nem akarunk) kibúvókat keresni, hogy miért nem illeszkedik az alaprendszerbe. Mert nem is az alaprendszer része lesz egy-egy extra funkció. Ma ismét befutott egy kérés, amelyre megnyugtató választ tudtunk adni…

Ügyfél megkeresés futott be, miszerint a Symbol Ügyvitelben rögzített és kezelt emlékeztetők (partnerkapcsolatok) valamilyen módon megjelenjenek az Outlook-ban illetve az Exchange Server-ben. A megoldás kézenfekvő, bár új területekre is el kell merészkednünk.

 

Járt utat járatlanért

Pár perc alatt kiderült, hogy a Symbol Ügyvitel SyX beépülőinek azon képességét kell kihasználnunk, mely szerint külső adatlekérésre is tud válaszolni. Létre kell hozni egy WebMethod-ot, amely egy URL-t definiál (http://gepnev/metodus). Az URL pedig meghívható bármely már alkalmazás irányából. Jelen esetben ez az Outlook lesz. Az Outlook az adatlekérdezés hatására létrehoz egy új felhasználói naptárat és azt szinkronizálja is. Amint új bejegyzés kerül bele, megjelenik a Outlook-ban.

Már csak azt kell megoldani, hogy naptár adatokat tudjunk visszaadni. Erre van egy szabvány, aminek a neve iCal.

 

iPhone, iPad, iCal

Ez kivételesen nem Apple termék, ez egy sokkal régebb óta használt technológia (Apple-nek van ilyen terméke, de ez nem ez). Segítségével egy nagyon egyszerű formátumban naptárbejegyzéseket, emlékeztetőket, privát elfoglaltságokat lehet közzétenni szabványos formában. Annyira szabványos ez, hogy a “Your favourite iCal browser” kifejezés is él, azaz bárki szabadon választhat az iCal formátumot feldolgozni képes alkalmazások közül.

Sok tesztelés, de legalább az alap technológia kiforrott

Ha az értékesítő kollégák jól dolgoznak, akkor az ügyfelünk még elégedettebb lesz. Az árak, maga a konstrukció nem a fejlesztés dolga, erre rálátásunk sincs. De ha ezt megrendelik tőlünk, akkor sok munka lesz vele. Mivel ismeretlen területre tévedünk, sok tesztelésre lesz szükség. De a technológia adott, sok helyen bizonyított, ténylegesen csak az iCal-ra kell koncentrálnunk.

Munkára fel!

Ritkán működő 413-as HTTP hiba

A HTTP szabvány szerint a HTTP hibakódoknak működniük kellene (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). Sok esetben – főleg tárhely szolgáltatónál működtetett PHP kiszolgálón – nem működik minden hibaüzenet. Ilyen hibaüzenet a 413-as hiba is. Ez akkor jelentkezik (jelentkezne), ha a beállított, fogadható adatmennyiségnél többet akarunk ráerőltetni, feltölteni a szerverre.

A hiba az esetek 90%-ban elfedésre kerül, azaz a válasz üzenetben nem érkezik semmi, a böngésző egy üres ablakot jelenít meg. Helyette a 413-as hibát kellene visszaadnia. Így sajnos azok az eszközök, amelyek webrendszeren küldenek adatot, nem értesülnek arról, hogy hiba történt.

WebSyX-ünkben is megvalósítottunk egy hibakezelő réteget, amely az elfedett 413-as hibát megkerüli és precízen kezeli. Amennyiben a hibakezelést bekapcsoljuk, úgy a POST adatfelküldésnél választ kell adni a feltöltésre. A WebSyX esetében ez egy OK szó kell, hogy legyen. Amennyiben nem kapunk választ (a csomag a nagy méret miatt elveszett) úgy hibának érzékeljük. Amennyiben az OK-tól eltérő választ ad vissza a szerver, úgy azt a szöveget is hibaüzenetként kezeljük. Ezzel egyéb, szerver oldalon bekövetkező hibákat is jelezni tudunk (MySQL error, PHP error, out of disk space, stb.)

WebSyX-ünk új változata letölthető a

http://syx.symboltech.hu/tanusitott-syx-beepulok/websyx-webaruhaz-kapcsolat/ linkről.

SaaS – Akkor ez most a Symbol Ügyvitel API?

SaaS működésünk megjelenése előtt számos céggel beszélgettünk róla, hogy ez a működés, akkor most mennyire van kész, ez most akkor gyakorlatilag egy API? A válasz az, hogy ez egy DynamicAPI. Teljes API-t nem lehet csinálni, de bármely része percek/órák alatt implementálható.

Mi is az API?

Az API egy függvénytár, amely egy rendszer kívülről elérhető funkcióit engedi megszólítani. Kis vagy közepes funkcionalitás esetén az API annyi megszólítható “dolgot” tartalmaz, amennyit két kezünkön meg tudunk számolni. Példaképpen említhetjük a POP3 vagy IMAP parancsokat, amelyek a levelek letöltését, üzenettörzs letöltését, üzenetek törlését valósítja meg. Nem is kell többet.

Ugyanilyen a Google Docs API, amely dokumentumok tárolását szolgálja. A műveleteknél nem is vágyunk többre, mint dokumentum feltöltése, letöltése, törlése, áthelyezése és egy gyors keresőszolgáltatás a dokumentumok tartalmában (ez utóbbi nem is biztos, hogy része a rendszernek, de ha már Google, akkor talán igen)

SaaS

Egy összetett (nem bonyolult, hanem komplex) rendszer esetében egy teljes API legalább annyi műveletet tartalmaz, mint ahány főmenüpontja van, a paraméterek száma is több tízre tehető. Ez nyilvánvalóan nem valósítható meg, pontosabban olyan mértékű ráfordítást igényel, amely nem térül meg.

Ehelyett a dolog méregfogát úgy húztuk ki, hogy egy önálló programozási platformmal lehetővé tettük bármilyen API megírását. És mindezt ingyenes eszközökkel. Egy SaaS kompatibilis SyX megírása ahhoz hasonlítható, mintha a Google Docs adatbázisához hozzáférünk (saját adataimat nem rejtsék el előlem) és saját lekérdezéseket írhatunk. A lekérdezéseket egy szabványos hozzáférési rétegen (HTTP) kivezetjük, hogy az azt felhasználó kollégáknak ne kelljen valami újat megtanulniuk.

Nézzünk erre egy példát!

Szükségünk lenne egy termékhez tartozó készletinformációra. Ezt egy külső program (amely a weboldalt frissíti) fogja felhasználni. Programozási nyelve lehet PHP, Delphi, C++ vagy C# is. Triviális megoldás, ha az adatbázisból közvetlenül lekérdezzük ezeket az információkat. (Ügyfélszolgálatunk támogatást nyújt a szükséges adatok helyének megismerésében). Ez a megoldás azonban közvetlen adatbázis kapcsolat igényel, amely közepes méretű cégeknél nem megoldható. Emellett külön kell azzal foglalkozni, hogy a fent jelölt programozási nyelvek miként kapcsolódnak az adatbázishoz. Helyette valósítsuk meg a dolgot két lépésben!

1. lépés: SaaS funkció létrehozása.

Hozzunk létre ingyenes fejlesztőeszközzel egy SyX-et, amely SaaS működésre alkalmas. A fenti művelet kiszolgálására készítsünk egy metódust, amely egy termékkódot vár és egy opcionális dátum paraméterrel hívható meg. A metódus “magja” kb. 8-12 programsor segítségével a beérkezett kérést ki tudja szolgálni a megfelelő táblákból történő lekérdezéssel. Végeredményként visszaadja az összes raktárt és benne a készletet, ahol a termék eddig megfordult. Fontos megjegyezni, hogy a bemenő URL feldolgozását nem nekünk kell elvégezni, sőt az eredmény formátumát sem nekünk kell meghatározni, azokat a SaaS definiálja (XML lesz).

2. lépés: SaaS funkció hívása.

Következő lépésben a Symbol Ügyvitel által használt webszervertől le tudjuk kérni a http://localhost/GetWarehouseBalance meghívásával a raktárkészlet információkat. Az URL meghívása szinte programozási nyelv függetlenül megtehető, minden nyelv tartalmaz weboldalról való letöltést megvalósító funkciókat. A visszaadott érték lehet XML formátumú, esetleg JSON, sőt teljes HTML weboldal is, ha az URL-t böngészőn keresztül kívánjuk elérni.

A fenti példán keresztül jól látható, hogy miért nem egy teljes API-t valósítottunk meg, mennyire szerteágazó lenne az ügyfelek minden igényét egy API-ban kielégíteni. Helyette azt a megoldást választottuk, hogy szabványos platformot hoztunk létre, amelyben mindenki a saját API-ját elkészítheti a saját adatai feletti rétegben.

SyX=Symbol eXtension. Már csak pár nap…

A jövő hét folyamán jelenik meg programunk új verziója. Ezzel nem is mondunk újdonságot. Partnereink megszokhatták, hogy minden két hétben előrukkolunk valamivel. Ha kérik, ha nem. Mert van még a tarsolyunkban.

Amivel a jövő héten megjelenünk, azt nem kérték. Mert ezidáig még senki nem csinált ilyet. Talán nem is gondolták volna az ügyfelek, hogy lehet ilyet is. Mottó: “Egyedi fejlesztés, ingyen.

Mi a helyzet az egyedi igényekkel?

Általában a felhasználók kérik, cégük működéséhez akarván igazítani a dobozos ügyvitel megoldást. Ez így helyén is van, ők a megrendelők.

Mi a baj az egyedi igényekkel?

Ez már fogósabb kérdés. A problémát az okozhatja, ha szót fogadunk és a fejlesztőcsapat beleépíti a kívánt funkciót a programba. Az ügyfél boldog, majd megkapja a számlát. Akkor már csak félig örül. (Valljuk be, minden egyedi fejlesztés pénzbe kerül. A nyomott árú piacon sajnos a termék árának többszöröse is lehet egy-egy új lista vagy export fájl.) De a funkciót megkapta, cége működése rendben van. A fejlesztőcsapat viszont évek múltán is kell, hogy emlékezzen valamilyen egyedi igényre, amely a programban valahol drótozottan jelen van. Nem kell messze mennünk (és sok karaktert sem beütni a böngésző címsorába), hogy példát hozzunk erre.

Képzeletbeli nagy cég, sok egyedi fejlesztés. Évek múltán is ott virít a “IF dubaj_mukodes” feltétel a programban, mert valamikor az őskorban eladtak egy programpéldányt a sejkeknek. A tizedik egyedi fejlesztésnél már egy külön ember kell arra, hogy fejben tartsa, mit kinek és miért építettünk bele. Szomorú tesztelők.

Mi még a baj a felhasználói kérésekkel?

Az, ha nem tudjuk megvalósítani. Technológiailag képzettek lehetnének a szakemberek, de Zsiguli típusú személygépjárművel már csak a Bamakó rally-n indulhatunk. Ne legyenek Forma-1-es terveink és ígéreteink.

Amit mi ígérünk…

Mi nem ígérünk semmit, lehetőséget biztosítunk. Hogy mire? Ez ki fog derülni a jövő héten…

Türelmüket megköszönve, a Symbol Tech Kft. csapata.