AX.NET

Podle názvu byste možná řekli, že AX.NET má něco společného s Dynamics AX a .NET. A skutečně! AX.NET je nástroj usnadňující vývoj .NET aplikací, které volají aplikační logiku AX pomocí Business Connectoru. A v čem je to usnadnění? Zejména v tom, že AX.NET vytvoří z AOT .NET sestavení, obsahující všechny třídy, tabulky, enumy atd. Toto sestavení je pak přidáno do projektu ve Visual Studiu a objekty jsou připraveny k použití - lze volat metody tříd, přiřazovat hodnoty do polí v tabulkách atd. To vše s podporou všech schopností Visual Studia - IntelliSense, typová kontrola a spousta dalších. To proto, že díky AX.NET je Axapta jen další .NET sestavení. Skvělé řešení! AX.NET také podporuje LINQ dotazy (Language-Integrated Query, speciální syntaxe pro psaní dotazů), které překládá do X++ a spouští přes Business Connector (takže se opět použije veškerá AX aplikační logika). Praktickou ukázku můžete vidět například v tomto videu. Na AX.NET jsem narazil v podstatě okamžitě, co se objevili první zprávy, ale čekal jsem, zda se to podaří realizovat a jen jsem občas zkontrolovat, co na mě vypadlo z RSS. Ale zřejmě je na čase vzít tento projekt vážně, protože oficiální vydání má být právě dnes! Jen bych asi měl dodat, že jde o komerční projekt. Více informací o AX.NET naleznete na proisv.com.

Odhady pracnosti

O odhadech pracnosti při tvorbě softwaru už byla napsána řada knih a já ani nemám ambici přinést tímto článkem něco nového. Přesto… povědomí vývojářů, konzultantů, projekt manažerů (a všech ostatních ;)) o zkušenostech, které softwarový průmysl nasbíral za desítky let své existence, je mimořádně nízké, takže trocha opakování snad neuškodí. V tomto článku chci ukázat, jak dělám odhady programátorských prací já osobně a upozornit na některé časté chyby. Můj osobní přístup nelze samozřejmě považovat za univerzálně platný. Pro další postupy, lepší vysvětlení, teoretické podklady, statistiky atd. musíte zapátrat v odborné literatuře. V češtině nelze než doporučit Odhadování softwarových projektů (možná znáte originální název Software Estimation: Demystifying the Black Art). Cíl odhadu Nejprve je třeba si ujasnit, k čemu má odhad sloužit. Z toho pak plyne, v jaké fázi projektu odhad potřebujeme, s jakou přesností atd. Někdy stačí velmi vágní odhady (projekty typu až to bude, tak to dodáme) jindy je třeba dělit práci do iterací, volit variantu, která se stihne do fixního data atd. Odhad by měl poskytnout data dostatečná pro plánování a řízení projektu, nemůže poskytnout přesné číslo, jak dlouho bude práce trvat (tuším McConnell to nazývá „předpovídání budoucnosti“). Přesto je nalezení tohoto magického čísla cílem odhadů na mnoha projektech – a asi nepřekvapí, že v předpovídání budoucnosti lidstvo velký pokrok neudělalo. :-) Jednou z nejčastějších chyb je přímá kalkulace ceny projektu z odhadu (odhad v hodinách × hodinová sazba). To je také zřejmě důvodem, proč jsou tak často požadovány „předpovědi budoucnosti“. Krom negativních dopadů na konstrukci ceny má tento přístup také dopad na tvorbu odhadu – místo aby se udělal co nejpřesnější odhad a cena se stanovila nezávisle, vytváří se tlak na změnu odhadu. Problém je v tom, že takto modifikovaný odhad (ať už kterýmkoli směrem) může být těžko použit pro plánování projektu. Byl jsem dokonce svědkem snah přenést zodpovědnost za dodržení „odhadu“ na vývojáře. Nutným důsledkem by pak bylo dohadování mezi vývojářem (snažícím se nadsadit odhad tak, aby se do něj vždy vešel) a projekt managerem (snažícím se stlačit termín). Skutečný odhad by v takovém procesu figuroval jen zcela okrajově. Kdy odhadovat Projekt lze odhadovat v kteroukoli fázi, ale dosažitelná přesnost je limitována množstvím informací, které jsou k dispozici. Například pokud odhadujete pracnost na základě pouhého uživatelského požadavku, nemá podle mého názoru smysl větší přesnost než Malá/Střední/Velká náročnost (a i tak se to často nepodaří trefit). Pokud chcete získat (relativně) přesný odhad, potřebujete znát všechny funkční požadavky i způsob implementace. Protože v Dynamics AX většinou zasahujete do existujícího kódu, je nutné vědět, jaké části již existují a bude je možné využít a jaké je třeba nově naimplementovat. Někdy je také vhodné vytvořit prototypy nejasných částí ještě před odhadem pracnosti. To všechno si pochopitelně vyžádá určitý čas, se kterým musí být počítáno v projektovém plánu. Jak odhadovat První a nejdůležitější částí odhadu je dekompozice na menší části. Tyto části je nutné nejprve vůbec identifikovat (do té doby jen tušíte, co všechno bude asi tak třeba udělat), ověřit, zda pokrývají všechny požadavky, a nakonec je postupně odhadnout. Často nejsou všechny potřebné informace k dispozici, ale je možné odhadnout alespoň některé části a ke zbylým se vrátit později. Já projekt člením po (relativně) samostatně funkčních blocích realizovatelných v řádu hodin čí dnů (dnů v případech, kdy je v odhadu příliš mnoho nejistoty). Odhady rozepisované podle jednotlivých objektů (tedy ne podle funkcí) považuji za hůře členitelné a nerespektující skutečný postup práce při vývoji. Ke každému funkčnímu bloku zapisuji vše, co je třeba udělat, ale tyto detaily neodhaduji samostatně. Seznam pak používám i v průběhu vývoje ke kontrole, zda je vše naimplementováno, a k vykazování stavu implementace. V mém případě vypadá popis bloku nějak takto: Parametrizační tabulka (EDTs, help texty, tabulka, formulář, menu item, do menu) Členění na menší části má ještě několik dalších výhod. Zejména je jasné, co je vlastně do odhadu zahrnuto, a v případě změn lze snadno přidat/odebrat určité bloky, popř. zpětně vysledovat, jaká práce chyběla v odhadu a přesto se musela udělat. Když už víte, co všechno se bude programovat, zbývá jen udělat odhad. Na většině projektů (alespoň co mohu soudit z mé zkušenosti) je odhad číslo popisující za jak dlouho by se práce mohla stihnout. Pak se pár věcí zkomplikuje a výsledek se oproti odhadu liší i o stovky procent. Odpovědí na tento problém (a nejen na něj) je definice odhadu jako rozsahu, do kterého výsledná pracnost s vysokou pravděpodobností padne. Když jsem o tomto přístupu poprvé četl (v praxi jsem ho nikdy neviděl), nedovedl jsem si to moc představit. V praxi se ale ukázalo, že je to postup velmi přirozený a rychle se na něj zvyká. Prostě odhadnete optimistickou variantu (to je to výše zmíněné za jak dlouho se to dá stihnout) a naopak pesimistickou. Odhad pak daleko lépe popisuje, jaké situace mohou nastat a zabraňuje zaměňování odhadu za termín, kdy bude práce určitě hotova. U jednočíselných odhadů se také často projevuje tlak na jejich snížení – zde to nepředstavuje problém, protože optimistická varianta je zahrnuta, ale zároveň je zřejmé, že to skutečná pracnost bude pravděpodobně větší. Na závěr Doufám, že jsem něco málo z problematiky odhadování odhalil a ne zamlžil. Vědomě jsem pominul celou řadu důležitých věcí, třeba využívání dřívějších odhadů (a jejich úspěšnosti), ale domnívám se, že začít je třeba výše uvedeným. A pak už jen zlepšovat…

Generátor přístupových metod pro AX4

Pomalu se zabydluji ve svém novém působišti ve Velké Británii a tak se zas pokusím trochu vyprázdnit buffer věcí, o které bych se chtěl podělit. První z nich je velmi stručná - jelikož můj aktuální projekt běží na AX 4.0, připravil jsem .xpo generátoru přístupových metod i pro tuto verzi AX. Stahovat můžete zde.

Intelligent Data Management Framework

Na PartnerSource se objevila pre-release verze velmi zajímavé aplikace. Intelligent Data Management Framework for Microsoft Dynamics AX (IDMF) slouží ke správě databáze Dynamics AX, zejména archivaci a odstraňování historických záznamů, samozřejmě při zachování konzistence databáze. Taková funkcionalita byla zákazníky dlouhodobě (a oprávněně) žádána, protože z hlediska výkonu je vhodné udržovat co nejmenší transakční databázi. IDMF podporuje AX ve verzích 3 - 5 a SQL Server 2005/2008 (pravděpodobně kvůli Integration Services). Před archivací/vyčištěním dat je nutné definovat, které tabulky spolu souvisí a mají být zpracovány společně (to je úloha kritická pro zachování konzistence databáze). IDMF dohledává tyto informace pomocí křížových referencí a díky tomu stačí zadat „kořenovou“ tabulku a související tabulky jsou přidány automaticky (manuální změny jsou možné). Na základě tohoto stromu (Purge Object/Archive Object v originální terminologii) je pak prováděna vlastní archivace/vyčištění dat. Dalším krokem je definice filtru dat - například plně zaúčtované záznamy za loňský rok. Takto definovanou operaci je možné spustit jednorázově, nebo přímo v IDMF nastavit opakované spouštění. Z dalších schopností IDMF bych zmínil:

• Předpřipravené objekty - není tedy nutné (a ani doporučené) začínat od nuly.
• Analýza DB - informace o velikosti databáze, fragmentaci indexů atd., ale i např. počtu ukončených skladových objednávek. Lze také sledovat změny v čase.
• Restore - archivované záznamy je v případě potřeby možné vrátit zpět do produkční databáze.

Sice jsem neměl zatím možnost IDMF vyzkoušet prakticky, ale vypadá rozhodně velmi užitečně. Pokud vás také zaujal, doporučuji prostudovat Installation Guide a Administration Guide.

PowerShell - informace o AX aplikaci

Snažíte se psát skripty pro manipulaci s AX a nechce se vám udržovat informace o jménech aplikací, cestách k adresářům a podobně? Mně se tedy nechce a tak jsem si řekl, že bych mohl všechno zjistit automatizovaně jen na základě .axc souboru. Výstup mého skriptu vypadá následovně:

AppLocalPath       : C:\Program Files\Microsoft Dynamics AX\50\Application\Appl\JmenoAplikace
AosName            : JmenoAOS
AosNumber          : 03
AosServiceInstance : System.ServiceProcess.ServiceController
AosPort            : 2714
AosComputerName    : JmenoPocitaceSAos.domena
AppUncPath         : \\JmenoPocitaceSAos\C$\Program Files\(...)\Appl\JmenoAplikace

Základní informace o AOS zjistím se zadaného .axc souboru, instanci služby pomocí Get-Service a cestu k aplikačnímu adresáři z registrů počítače, kde je nainstalované AOS. Z toho také plyne, že je třeba mít nakonfigurovaný PowerShell remoting. Podrobnosti zde nebudu rozepisovat, zájemci si pročtou kód a nezájemci ušetří čas :-). Skript stahujte zde.

SysQueryRangeUtil

Třída SysQueryRangeUtil obsahuje několik užitečných metod, pomocí kterých lze vytvářet hodnoty filtrů (nad Query objekty). Jsou to například metody currentEmployeeId() nebo dayRange(). Ve všech případech jde o statické metody vracející řetezec a řada z nich má nepovinné parametry (pro určení rozsahů apod.). Tyto metody lze použít při vytváření Query v X++ kódu, třeba takto:

queryBuildRange.value(SysQueryRangeUtil::day());

To by nebylo nic zajímavého, vtip je v tom, že je lze použít i při filtrování dotazu pomocí dialogu (na formuláři, v RunBase třídách a podobně): a také v Queries v AOT: Jediná finta je v tom, že jejich volání musí být uzavřeno do závorek. Do třídy SysQueryRangeUtil lze také přidat další metody - ať už kvůli dodatečné funkcionalitě (např. weekRange()), nebo pro přidání aliasů metod (např. me() jako alias currentUserId()).

Hotfix Impact Analysis

Microsoft zveřejnil nový nástroj pro Dynamics AX, který pomáhá identifikovat, jaké mohou být dopady změněných objektů. Hlavní částí je formulář Impact Analysis (viz obrázek), který v horní části zobrazuje zvolené objekty a v dolní části křížové reference pro označený objekt. Formulář lze spustit z kontextového menu (Add-Ins > Impact analysis) pro jeden nebo více AOT objektů, pro jeden nebo více projektů, nebo z instalátoru hotfixu. Podívejme se na funkce, které lze z tohoto formuláře vyvolat:

• Compare - porovná různé vrstvy objektu. Narozdíl od "normálního" porovnání zobrazí dva panely vedle sebe (takže lze zároveň zobrazit např. porovnání SYP×Old SYP a SYP×VAR), naopak nejsou přístupné volby jako zobrazení čísel řádků).

• Load - zde se nachází funkce pro přidání objektů do analýzy - lze vybrat objekt z AOT nebo z projektu (a přetáhnout myší), přidat celé .xpo nebo dříve uložený stav.
• Remove - odebere označený objekt z analýzy
• Save - uloží seznam objektů (vybraných pro analýzu) do XML. Tento soubor lze pak nahrát funkcí Load > Load Impact Analysis State.
• Export - umožňuje exportovat seznam objektů nebo křížových referencí do XML.

Tlačítka v dolní části zpřístupňují standardní funkce pro křížové reference. Jak jsem již zmínil, analýzu dopadu je možné spustit přímo z instalátoru hotfixu: V následujícím kroku instalátoru je zobrazena stručná informace o zasažených objektech a je možné pomocí tlačítka přejít do výše popsaného formuláře v AX. Po analýze dopadu je možné pokračovat v instalaci hotfixu. Nástroj Impact Analysis je k dispozici jako samostatný hotfix (tak jsem ho získal já) a od dnešního dne by měl údajně být součástí veškerých nových hotfixů. Další informace: KB974255 (Impact Analysis feature for Dynamics AX 2009)