Status update

Nejprv bych chtěl trochu vysvětlit, proč je na tomto blogu poslední dobou tak ticho. Všechno to více či méně souvisí s mým přesunem do Anglie (tentokrát už ne pouze na jeden projekt). To s sebou neslo a nese řadu starostí, od pozitivních (průzkumy Londýna), po méně pozitivní, jako byla absence počítače na kterém bych mohl doma pracovat. Původně jsem totiž přijel jen s netbookem a naivně předpokládal, že použiji firemní servery; nicméně nechal jsem si z ČR poslat svůj vývojový servřík a už to snad bude OK. (Mimochodem poštou to není nijak zvlášť drahé, jen mi na Border Agency rozřezali krabici, což mě moc nepotěšilo.)

Také se mi v práci moc nedaří objevit něco publikovatelného a doma se věnuji spíš .NETu. Blog se širším záběrem je v plánu, ale zatím nemá tu správnou prioritu.

Hlavní věc v AX světě je teď samozřejmě AX2012 (tedy ne AX2011, jak byla často označována), zejména po technické konferenci v Redmondu (17.-20. 1.). Té jsem se bohužel nezúčastnil, ale informace ke mně putují, takže něco bych určitě napsat mohl.

Nicméně jsem se rozhodl, že nebudu sepisovat nějaký list „všech novinek“ a to ze dvou hlavních důvodů. O některých novinkách je tak málo informací, že se všude opakuje jen nějaký vágní popis a málokdo skutečně ví, co to vlastně znamená. A CTP má být vydáno už v únoru, tedy během pár týdnů, a pak bude možné napsat něco konkrétnějšího.

V tuto chvíli se omezím na prohlášení, že se toho mění neskutečně moc. :-)

Verzování bez Team Serveru

Nedávno jsem chystal vývojové prostředí AX2009 využívající Team Foundation Server, ale použití Team Serveru (aka ID Server) by mi nic nepřineslo a jen by mi věci zkomplikovalo.

Jak tedy donutit AX2009, aby se spokojila se správou verzí bez Team Serveru?
Odpověď je jednoduchá:
SysVersionControlSystem.requireTeamServer() musí vracet false.
Sám jsem čekal něco komplikovanějšího… :-)

AX2009 a TFS2010

Jak jistě víte, AX2009 může používat k ukládání zdrojových kódů Team Foundation Server. Co když ale máte TFS2010, který není podporovaný AX2009?
Nastěstí je řešení celkem jednoduché - budete potřebovat:

1. Team Explorer 2008 - AX využívá jeho knihovny (a nejspíš ho budete používat i přímo).
   Ještě není vyhráno, protože Team Explorer 2008 nespolupracuje s TFS2010. Za druhé tedy potřebujete:
2. VSTS 2008 SP1 Forward Compatibility Update for TFS2010 - díky němu se Team Explorer 2008 dokáže připojit k TFS2010.
   Jak napovídá i název, na Team Explorer musí být aplikován:
3. Service Pack 1 (Visual Studio 2008).
   Zde se můžete dostat ještě do jednoho problému - pokud máte Visual Studio 2008 SP1 a doinstalujete Team Explorer, musíte přeinstalovat SP1. Teprv pak je možné aplikovat Forward Compatibility Update.

Verzování dokumentů v TortoiseSVN

Verzování zdrojových kódů se díky integraci do IDE (velmi) pomalu zabydluje i ve světě Dynamics AX, ale často se zapomíná na ostatní data. Přitom znát historii třeba funkčního designu, mít možnost porovnat změny mezi verzemi atd. je stejně tak potřebné jako v případě kódu.
Navíc jde i o zdrojový kód mimo AX, třeba SQL, XSLT, HTML a tak podobně.

Některé týmy používají nějakou podobu document managementu s verzováním, typicky v rámci SharePointu. Ale i toto řešení má své nedostatky, zejména komplikovanost práce s takovými soubory, a tak zůstává řada dokumentů mimo tyto systémy.

Kontextové menu TortoiseSVN

Dnes chci ukázat, že používat verzovací systém může být snadné a bezbolestné. A to tak, že můžete snadno verzovat úplně všechny soubory, u kterých to má nějaký smysl.
Nebudu tedy zabíhat do žádných detailů - pokud TortoiseSVN nebo podobný nástroj používáte, asi se toho mnoho nedozvíte.

Ikony souborů

Nejpřirozenější systém je takový, který vám umožní pracovat s verzovanými soubory z velké části tak, jak se soubory pracujete dnes, ale přidá další vrstvu pro práci s verzemi. Přesně to vám umožní TortoiseSVN, což jeden z mnoha klientů pro verzovací systém Subversion (existují také například Subversion pluginy pro Visual Studio, doma používám AnkhSVN).

Nejviditelnější věc na TortoiseSVN jsou dodatečné symboly na ikonách ve správci souborů (viz obrázek vpravo). Ty se samozřejmě nezobrazují všude, ale jen v adresářích, v kterých je verzování aktivní (hodně zjednodušeně řečeno).

Do takové složky je možné soubory přidávat, měnit, mazat atd. jako by zde žádný verzovací systém nebyl (řada lidí žije v představě, že používání verzování znamená provádět checkout před každou editací a proto se mu brání, tak to raději zdůrazňuji).

Ukládání do repozitáře

Jakmile jste se změnami spokojeni, uložíte (v jediném kroku) veškeré modifikované soubory do úložiště verzí (repozitáře) - a hotovo, soubory jsou uloženy a můžete dále pracovat s vědomím, že se k dané verzi kdykoli vrátíte, bude-li třeba.

Kontextové menu TortoiseSVN nabízí sice spoustu možností, ale zmiňme jen pár základních:

• Update = načtení souborů z repozitáře
• Commit = uložení do repozitáře
• Show log = zobrazení hostorie
• Rename = přejmenování souboru se zachováním historie

Historie verzí

Show log zobrazí okno se všemi verzemi zvoleného souboru nebo adresáře, obsah každé verze (přidané, smazané soubory atd.), komentáře k verzím a podobně. Můžete zde také vybrat verze k porovnání, přímo otevřít historickou verzi a tak dále. Při porovnání nejste omezeni na čistě textové porovnání, třeba Word a Excel jsou také podporované!

Instalace
Instalační soubor můžete stáhnout zde. Při výběru verze (32/64 bit) vezměte v potaz nejen verzi operačního systému, ale i správce souborů. Máte-li Windows 64bit a chcete používat TortoiseSVN jak ve Windows Exploreru (64bit), tak Total Commanderu (32bit), potřebujete nainstalovat obě varianty TortoiseSVN.

Po instalaci musíte vytvořit repozitář. Subversion opět nabízí spoustu možností, které budu okázale ingorovat. :-) Vytvořte adresář (ideálně na nějakém bezpečném serverovém disku, v horším případě lokálně), z kontextové nabídky na adresáři zvolte TortoiseSVN > Create repository here a potvrďte. Do tohoto adresáře v podstatě nemusíte vstupovat, takže volte spíš lokaci, kde vám nebude překážet.

Dále vyberte místo, kde budete chtít pracovat se svými verzovanými soubory. Zvolte SVN Checkout a zadejte cestu k repozitáři (jako file://ServerName/path/to/repos/ nebo file:///C:/repo). Těchto pracovních adresářů můžete mít kolik chcete a můžete si nějaký vytvořit kdykoli, kdy potřebujete svá data a máte dokážete číst z adresáře s repozitářem (serverový disk přístupný přes VPN je skvělá volba).

Nastavení

Nastavení můžete měnit v TortoiseSVN > Settings.

Z obsáhlého kontextového menu si můžete vybrat často používané položky a umístit je hned přímo do hlavní kontextové nabídky, tedy tam, kde je defaultně SVN Update atd. Mně například dost chyběl příkaz Add.
(General > Context menu)

V Icons Overlays můžete nastavit, na jakých druzích disků (síťové, přenostné atd.) se mají zobrazovat stavové ikonky TortoiseSVN. Chcete-li vidět ikony i v jiných aplikacích, než jen ve Widnows Exploreru (typicky v jiném souborovém manageru), odšktněte zde Show overlays and context menu only in explorer.
Pokud používáte konkrétně Total Commander, musíte mít v jeho konfiguraci zaškrtnuté Show overlay icons (Configuration > Options > Icons).

Užitečné je také nastavit, jaké soubory má Subversion ignorovat (v General > Global ignore pattern), například soubory začínající "~" (mj. pracovní soubory MS Office).

AX Business Intelligence Team blog

Dynamics AX Business Intelligence Team blog byl spuštěn před pár dny a obsahuje (v tuto chvíli) dvacet videí o používání SQL Server Reporting Services v Dynamics AX. Každé video má jen pár minut a na základní seznámení nejsou vůbec špatná.

Tabulky v Table map

Řekněme, že píšete třídu, která bude schopná pracovat s libovolnou tabulkou z určité mapy (třeba PBAItemLine, v mém případě). V objektu typu Args vám přijde buffer, a vy byste rádi zkontrolovali, zda patří mezi tabulky definované v dané mapě.

K tomu lze využít metodu SysDictTable::isTableMapped(); konkrétní přiklad by vypadal takto:

if (SysDictTable::isTableMapped(tableNum(PBAItemLine), _args.dataset()))

Implementace metody isTableMapped() je trochu ošklivá (dívá se přímo do AOT na obsah uzlu Mappings),  inteligentní podpora zřejmě v API chybí.

Mimochodem, instance třídy DictTable může reprezentovat nejen "klasickou" tabulku, ale i Map nebo View.

Implementace metod definovaných rozhraním

Při přípravě jiného článku jsem narazil na dost… osobité chování Axapty při implementaci rozhraní. Navzdory veškerým očekáváním Axapta nekontroluje, zda má implementující třída správné veřejné rozhraní (proto interface), ale jen že má metody shodných názvů, jaké má i rozhraní.

Ukažme si to na příkladu. Definuji následující rozhraní:

interface Rozhrani
{
    int rychlost(int _rychlost){}
}

Předpokládal bych, že každá třída implementující toto rozhraní musí obsahovat metodu rychlost() s parametrem a návratovou hodnotou typu int.

Následující třída jde nejen zkompilovat, ale kód v metodě main() i bez chyby proběhne, včetně přiřazení do proměnné.

class ImplementujiciTrida implements Rozhrani
{
    //Správný název metody, ale nesprávný typ parametru i návratové hodnoty
    void rychlost(str _slovniPopisRychlosti)
    {}

    public static void main(Args _args)
    {
        Rozhrani trida = new ImplementujiciTrida();
        //Instance nemá metodu akceptující číselný parameter a vracející hodnotu,
        //přesto toto volání proběhně.
        int i = trida.rychlost(5);
    }
}

Metoda rychlost() obdrží hodnotu překonvertovanou do řetězce a vrátí hodnotu 0 (případná hodnota v proměnné i v main() by byla přepsána), přestože má návratový typ void.
Pokud by implementace metody rychlost() obsahovala parametr, pro který neexistuje implicitní konverze (např. Object _o), dojde k chybě za běhu aplikace.

Rozhraní má poskytnout jistotu, že instance každé implementující třídy "rozumí" určitému způsobu komunikace, tedy že je možné zavolat nějakou metodu s předem danými typy parametrů. Když se třída hlásí k určitému veřejnému rozhraní (= implementuje interface), kompilátor by měl zajistit, že tomu tak skutečně je. Kompilátor Axapty to ale nedělá - a výsledkem chyby, kterou měla odhalit první kompilace, může být runtime exception nebo opravdu nepochopitelné chování aplikace.

Tímto nechci říct, že se v X++ nemají rozhraní používat. Naopak si myslím, že se používají málo (a místo nich se vytváří sporné hierarchie dědičnosti apod.). Ale nelze se spoléhat na kompilátor, že korektní implementaci rozhraní vynutí.