Šťastný nový rok!

Vše nejlepší v roce 2010! V letošním roce se můžeme těšit na novou verzi Dynamics AX ("6" či "2011"), nové Office, SharePoint, Visual Studio, Team Foundation Server a tak dále, takže nudit se určitě nebudeme. Mimochodem, betaverze řady produktů je možné již nějaký čas testovat a můžete se tak s novinkami v klidu a včas seznámit. Nové produkty v mnoha případech vyžadují také nový operační systém, takže i v tomto směru nás jistě nás čekají změny, ve vetšině případů zatím odkládané. Pro mě osobně byla migrace na Windows 7 i příležitostí opustit 32-bitovou architekturu. Pokud bych si dával nějaká předsevzetí do nového roku, na místě by jistě byl slib dokončit všechny rozpracované příspěvky pro blog, který jsem v poslední době velmi zanedbával. Tak uvidíme, sám jsem zvědav, jak to stihnu... :-)

Powershell remoting

V posledních týdnech pracuji spíše okolo Axapty než přímo v ní a v podobném duchu je i tento příspěvek. Jednou z věcí, kterými se zabývám, je totiž automatizace správy Dynamics AX prostředí, zejména instalace programových úprav. PowerShell je pro to ideální nástroj a funkce pro práci po síti - "remoting" - jsou velice potřebné, protože i jednoduchá migrace mezi dvěma Dynamics AX prostředími typicky vyžaduje práci na několika serverech. Nasazování úprav se skládá z mnoha kroků - například zastavování a spouštení AOS, kopírování souborů (vrstev, labelů), importy, kompilace a podobně. Automatizace nejen že sníží čas, který je třeba věnovat celému nasazování, ale sníží i chybovost při práci se soubory a minimalizuje dobu odstávek prostředí. PowerShell remoting v tom může pomoci tak, že celý proces lze řídit z jednoho místa - spravovat služby na vzdálených počítačích, spouštět aplikace, pracovat se soubory, přistupovat k registrům a tak dále. To vše velmi pohodlně a s plnou podporou .NET typů. Na Microsoft Festu 2009 jsem se dozvěděl, že mnoho lidí naráží při pokusech o konfiguraci PowerShell remotingu na problémy, zkusím tedy popsat mé zkušenosti. Musím rovnou říct, že já jsem na žádné příliš závažné problémy nenarazil, tak snad budete stejně úspěšní. První věc, kterou budete potřebovat, je PowerShell verze 2.0. Oproti verzi 1.0 obsahuje řadu nových funkcí, hlavně ale ten zmiňovaný remoting. PowerShell 2.0 je již obsažen v systémech Windows Server 2008 R2 a Windows 7, může ale být samozřejmě nainstalován i do starších systémů a to jako součást Windows Management Frameworku (odkaz obsahuje podrobnější informace včetně podporovaných systémů). Osobně používám PowerShell na WS2008 SP1 a WinXP SP3. Windows Management Framework tedy stáhněte a nainstalujte na všechny počítače, kde chcete PowerShell (i jen vzdáleně) využívat (a pokud nejde o systém, kde již je obsažen). Dále je třeba povolit remoting a to nejlépe pomocí příkazu:

Enable-PSRemoting

Tento příkaz spustí (a nakonfiguruje) službu WinRM, připraví listener očekávající vzdálené příkazy a vytvoří odpovídající pravidlo na firewallu. Toto musí být provedeno jak na serveru, tak i na klientském počítači. Na klientech jsem dále musel změnit konfiguraci sdílení:

Set-ItemProperty –Path HKLM:\System\CurrentControlSet\Control\Lsa –Name ForceGuest –Value 0

a přidat server mezi důvěryhodné. K tomu lze využít následující příkaz:

Set-Item WSMan:\localhost\Client\TrustedHosts –Value MujServer -Force -Concatenate

A to bylo v mém případě vše. :-) Pokud takové štěstí mít nebudete, zkuste se podívat nejprve na about_Remote_Troubleshooting a příbuzná témata, kde je mnoho možných problému popsáno. Off-line můžete zobrazit lokální podobu nápovědy takto:

Get-Help about_Remote_TroubleShooting

Konkrétnímu využití pro nasazování Dynamics AX se budu věnovat někdy v blízké budoucnosti. Dnes uvedu jen jeden jednoduchý příklad - spuštění AOS číslo 2 na vzdáleném stroji MujServer:

$aosService = (Get-Service -Name 'AOS50$02' -ComputerName MujServer)
$aosService.Start()
$aosService.WaitForStatus("Running")

Triviální, nemyslíte?

Nová kniha o Dynamics AX

Další kniha o programování v Dynamics AX je na cestě, konkrétně jde o Microsoft Dynamics AX 2009 Programming: Getting Started. Předpokládané vydání v prosinci, ale již nyní je možné objednávat. Bohužel nevím o obsahu nic víc, než co najdete na uvedeném odkazu.

Generování přístupových metod

Vytváření přístupových metod (tzn. metod zpřístupňujících neveřejné členy tříd) je velmi častá činnost. Členské proměnné tříd totiž nejsou přímo přístupné pro čtění či zápis a je proto nezbytné vytvořit metody, která vrátí či nastaví hodnotu dané proměnné. Díky tomuto řešení lze například zcela odstranit proměnnou a nahradit ji nějakým výpočtem, aniž by bylo třeba provádět změny mimo danou třídu. Přístupové metody mají obvykle prefix get (metoda pro čtení) nebo set (pro zápis), v AX se typicky kombinují do jediné metody s prefixem parm, která slučuje obě funkce. (V AX se používá několik přístupů - get metody jsou většinou zcela bez prefixu, někdo naopak propaguje používání prefixu parm i pro metody jen pro čtení či jen pro zápis atd.) Šablona parm metody V Dynamics AX si lze psaní přístupových metod zjednodušit pomocí šablon metod. V editoru otevřte Scripts > template > method > parm, případně použijte sekvenci zkratek "Alt+R" (Alt+M ve starších verzích) "S" "T" "M" "P". Do dialogu zadáte typ a název proměnné a po potvrzení bude vygenerovaný kód vložen na pozici kurzoru. Stále to ale není "ono". Je třeba vytvořit metodu, vymazat její obsah, ale zejména vědět typ a název proměnné. S jednou metodou se člověk vypořádá snadno, ale má-li jich vytvářet několik desítek, rázem vidí tento problém v jiném světle. Musí hledat deklarace požadovaných proměnných, vytvářet metody, kopírovat typy a názvy a tak dále. To je neproduktvní a stereotypní činnost, která volá po automatizaci. Generátor Proto jsem vytvořil generátor přístupových metod, který umí o něco víc. Konkrétně:

• zobrazí členské proměnné dané třídy (formuláře, datasetu apod.) včetně zděděných a umožní vybrat, pro které budou vytvořeny přístupové metody
• tento seznam je možné filtrovat
• umožňuje nastavit, zda vygenerovaná metoda bude určena pro čtení, zápis nebo obojí
• umožňuje změnit vygenerovaný název proměnné a parametru

V praxi to vypadá takto: Po potvrzení zadání se zobrazí infolog s výsledky generování. Z něj lze dvojklikem otevřít metodu v editoru. Existující metody nejsou přepsány. Pár poznámek k implementaci

• Vývoj i testování generátoru proběhly v AX2009.
• Potřebujete-li změnit vytváření výchozích názvů metod a parametrů, změňte metody initMethodName() a initParameterName() na tabulce TmpDevAccessorMethod.
• Pokud v dialogu měníte hodnoty checkboxů Read a Write, mění se i prefix v názvu metody. Jakmile však zadáte svůj název, změny Read/Write na něj nemají vliv.
• Vygenerované metody nepoužívají prmIsDefault(), což může být v některých případech problém. Bohužel, v tuto chvíli vám nezbývá než modifikovat vygenerovanou metodu ručně. Mám tuto vlastnost v "Nice to have". :-)

Integrace do kontextové nabídky Intergrace do kontextového menu je velmi prostá, stačí:

1. Přidat do menu
2. Určit, u kterých elementů bude tato volba dostupná (

První krok znamená jen přetáhnout menu item (DevAccessorMethodsGenerator) do menu SysContextMenu. Druhý vyžaduje změnu ve třídě SysContextMenu, metodě verifyItem(). Do větve MenuItemType::Action přidejte následující kód, který zajistí zobrazení jen u podporovaných typů:

case menuitemActionStr(DevAccessorMethodsGenerator):
    if (this.selectionCount() == 1
        && !firstNode.AOTIsOld()
        && DevAccessorMethodsGenerator::isSupportedTreeNode(firstNode))
  {
      return 1;
  }
  return 0;

Zpětná vazba Připomínky jsou vítané, hlášení chyb vyžadované. :-) Download Generátor přístupových metod (AX2009)

Otevírání formulářů v hlavním okně

Na AxForu jsem narazil na nápad změnit chování AX2009 tak, aby se formuláře otevíraly vždy v hlavním okně (originální post) a ne v oknech samostatných (tedy aby se chovaly stejně jako v dřívějších verzích). Já jsem si to ještě rozšířil o ListPages a dostal jsem tak všechny formuláře pod kontrolu Tabaxu. Toto uspořádání mi vyhovuje daleko více než to standardní. Potřebuji-li pracovat s příliš mnoha okny, otevřu si další workspace a v každém workspace pak udržuji související okna. Nemusím tak řešit chaos na taskbaru pokud například pracuji ve více prostředích a společnostech. Programová úprava je jednoduchá - do SysSetupForm.init() před super() jsem přidal:

if (this.form().design().windowType() == FormWindowType::Standard
    || this.form().design().windowType() == FormWindowType::ListPage)
{
   this.form().design().windowType(FormWindowType::Workspace);
}

Prosté a efektivní. Tak to má být. :-)

Překlad X++ do MSIL

Před pár dny jsem konečně našel čas a podíval se na video Peter Villadsen and Gustavo Plancarte: X++ to MSIL z Channel9. A musím říct, že opravdu stojí za zhlédnutí. V krátkosti tam lidé z X++ teamu popisují, proč a jak vytvořili překlad z mezijazyka AX do MSIL (Microsoft Intermediate Language - do něj jsou překládány všechny .NET jazyky). Dále také ukazují debugging X++ v prostředí Visual Studia a na závěr připouští možnost rychlého opuštění X++. A upřímně, ty možnosti jsou natolik lákavé, že to podle mého názoru sotva může v budoucnu dopadnout jinak. Špičkové vývojové prostředí, mj. také jednotné prostředí (když se ve VS už vyvíjí EP, reporty, workflow…), pohodlná integrace, testovací nástroje, plné využití TFS… Vůbec jsem netušil, že se do tohoto překladače Microsoft už pustil, natož že ho má hotový. Udělali mi velkou radost. :-)

Zobrazení názvu reportu

Na úvod malé vysvětlení, proč jsem se v poslední době poněkud odmlčel. Absolvoval jsem totiž stěhování a až dnes mě připojili k internetu, no a na novém projektu se také nenudím :-). Nicméně na pár zajímavých věcí jsem narazil, snad z toho dám něco v nejbližších dnech do zveřejnitelné podoby. Začnu tou nejčerstvější věcí. Dnes jsme řešili, jak nesnáze získat AOT jméno reportu (tiskové sestavy) vytištěné na obrazovku. Zkrátka máte na obrazovce report, chcete jej editovat/prozkoumat implementaci a nevíte, jak ho vlastně najít v AOT. Možnosti samozřejmě existují, ale nejsou příliš pohodlné. (Tedy pokud o nějaké víte, dejte vedět!) Já jsem zvolil řešení, které sice vyžaduje programovou úpravu, ale jeden řádek není zas tolik. ;-) Do titulku okna reportu jsem přidal jméno reportu - stačí k tomu drobná úprava metody createReportViewer() ve třídě ClassFactory:

public ReportViewer createReportViewer(
    PrintJobHeader  _jobsCursor,
    PrintJobPages   _pagesCursor,
    ReportRun       _reportRun = null)
{
    ReportViewer ret;

    ret = super(_jobsCursor, _pagesCursor, _reportRun);
    ret.description(strFmt("%1 (%2)", ret.description(), _reportRun.name()));
    return ret;
}

A nezbytná ukázka výsledku: