Benak.NET

V současné době pracuju na třech frontách, ale tu třetí, .NET pominu, to do článku o ABL (dříve 4GL) nepatří. ABL je sice zastaralá platforma, ale ať si co chce kdo chce říká, aplikaci v ní napíšete během velmi krátké doby.

Zaručený elektronický podpis pro NIS Medea

Tak tohle je taková lahůdka, dalo by se říct srdeční záležitost. Do našeho informačního systému jsme potřebovali zakomponovat podepisování různých zpráv a dokladů podle specifikace CMS (cryptographic message structure) a její ukládání do DB a archivu. Archivaci nemáme zatím rozhodnutou, ale už teď je jasné, že budeme používat systém Centera od EMC. Pro vlastní implementaci digitálního podpisu jsme nakonec po dlouhých diskusích zvolili knihovnu Trustporte PKI SDK od firmy AEC. Knihovna je psána jazyce C a je dostupná pouze pro platformu Windows (s přenosem na platformu UNIX jsou prý problémy a navíc tu jde o ochranu jejich investic, prostě by to musel někdo zaplatit), ale to se ukázalo jako řešitelné.

Komunikace s centrálním úložištěm SÚKL

Toto byla již od začátku "průserová akce" a za tím si stojím a trvám na tom. Zpočátku totiž ředitel SÚKLu PharmDr. Beneš a řešitelé centrálního úložiště přistupovali k výrobcům lékárenského SW jako k obtížnému hmyzu a to co řekli na jednom setkání, na jiném už neplatilo a pokud jsme měli štěstí, udělali obrat jen o 90 stupňů. Nejenže údržba této šaškárny přijde mého zaměstnavatele na 1-5 dní mé práce při každé jejich změně a tyto vícepráce musí zaměstnavatel hradit ze svého, ale občas je s námi i nadále jednáno jako s blbci. Dosti nářků, zpět k řešení.

Ačkoliv je centrální úložiště postaveno nad Sonic ESB od firmy Progress, paradoxně implementaci JMS komunikace pro ABL nemůžeme využít, protože neumí autentizaci proti LDAP serveru (mimochodem jsem se dozvěděl, že architekt CÚ si velmi pozorně četl moji diplomku o LDAPu :-), což potěší), kterou mají v CÚ implementovanou. Proto jsme museli jít cestou WSDL, kterou má Progress v ABL velmi dobře prošlápnutou a napsat klienta je otázkou několika minut. Bohužel i zde jsme natrefili na nějaká omezení. Aktuální verze je totiž 10.2B, ale naši klienti mají po delším boji nainstalovánu verzi 10.1C. Bohužel, klientská WSDL není implementována pro Linux 64bit (ve verzi 10.2A už ano), což nám komplikuje situaci a je nutné ji řešit vzdáleným zpracováním úlohy na jiném počítači, než-li je server.

Definoval jsem si pomocnou temp-table, do které na straně serveru ukládám vygenerované informace, a ty předávám voláním úlohy vzdáleného zpracování appserveru na nastaveném stroji.

DEFINE TEMP-TABLE ttSukl NO-UNDO
    FIELD iddoklad AS INTEGER
    FIELD idmsgpodani AS CHARACTER
    FIELD typpodani AS CHARACTER
    FIELD xmlpodani AS BLOB
    FIELD idmsgodpoved AS CHARACTER
    FIELD typodpoved AS CHARACTER
    FIELD xmlodpoved AS BLOB.

Tak a teď trošku zeširoka. idmsgpodani a idmsgodpoved obsahují GUID podání a GUID odpovědi. Ten je reprezentován jako CHARACTER. typpodani a typodpoved je informace o tom, co za typ zprávy posíláme SÚKLu (např. MSG011, MSG027 apod.), a co nám přišlo za odpověď (např. MSG111, MSG127, MSGFATALERR, MSG100 apod.). Obě tyto informace jsou typu CHARACTER. Proč jsou xmlpodani a xmlodpoved typu BLOB když do nich ukládám XML zprávu? Přiznám se, že jsem nezkoušel možnost typu X-DOCUMENT (to asi nejde), LONGCHAR také ne a s CLOBem jsem narazil. S BLOBEM tedy taky, ale nakonec jsem to vyřešil. CLOB a LONGCHAR jsou totiž závislé na nastavení kódové stránky systému

DEFINE VARIABLE hWebSukl AS HANDLE.
CREATE SERVER hWebSukl.
 
IF hWebSukl:CONNECTED() THEN
    hWebSukl:DISCONNECT().
 
 
IF VALID-HANDLE(hWebSukl) THEN
    DELETE OBJECT hWebSukl.