Ax 2009 performance bij opbouwen formulier met grid

Performance is nooit te goed en als je iets snel moet doen is het systeem altijd wel te traag. Maar soms is het ook raar. Normaal kan je performance terug leiden tot een index, tot een display/edit methode of veel client/server communicatie. Maar soms ook niet.

Bij een Ax 2009 gebruiker waren al diverse reputabele partijen geweest vanwege performance problemen die al diverse punten hebben aangehaald. Voornamelijk netwerk topologie punten. Maar alsnog geen soelaas.

Situatie schets; de servers worden gehost in een datacenter. Gebruikers hebben een thin client die een remote desktop verbinding maken met een terminal server (TS) in dit datacenter. In dit datacenter staat de Ax AOS met op diezelfde server de database. Zelf als externe Ax consultant had ik via RDP toegang tot de servers. Aangezien de TS nog wat extra software had voor de eindgebruikers het melden even waard. De TS zelf is Windows 2012 R2, de server zelf is Windows 2008. 

Eigenlijk kwam het terug tot dit; een standaard tabel, de InventJournalTrans op een schoon formulier met enkel een tab en een grid als admin ging de performance dramatisch onderuit als alle velden op de grid werden opgenomen. Als je het opende:

Her duurde tot wel 30 seconden voordat het scherm verder werd opgebouwd. En dan nog; het scherm werd zichtbaar opgebouwd:


Het klikken tussen de records zat merkbaar een vertraging in: duurde soms enkele seconden voordat een regel gearceerd werd. Eigenschappen van het form:
 - Kaal formulier met één tab, één grid, > 40 velden
 - Geen edit/display methoden enkel velden dit in de tabel zitten. 
 - Openen vanuit AOT, geen rechten, geen methoden geïmplementeerd(init, run, active, executeQuery, linkactive), eigen queries, sortering or andere properies van de componenten.Zelfs niet eens de moeite genomen de tab een label te geven.
Via de tabel-browser van Ax was de tabel met al zijn velden wel snel benaderbaar.

Bij minder velden (< 20) ging het goed en snel. De situatie is echter, dat na minimaliseren en restoren van het form de performance ineens goed was bij meer dan 20 velden. Deze code opgenomen onder een knop:
    WinAPI::showWindow(element.hWnd(), 6); // 6 = minimize
    WinAPI::showWindow(element.hWnd(), 9); // 9 = restore
Het scherm knippert even, maar de performance is uitstekend. Het opstarten van het formulier is echter nog steeds traag.

Het feit dat de schermen snel zijn na een minimize/restore  geeft mij aan dat het probleem niet in Ax of in de netwerk verbinding zit. Maar waarom is de tabel-browser dan wel snel? Deze velden worden dynamics toegevoegd...Uiteindelijk kwam ik er achter dat verborgen velden hetzelfde effect had:


In de run:


De refreshForm:


Het direct zichtbaar maken in de run (de na de super in de run meteen refreshForm aanroepen) maakte het systeem al wel wat sneller, maar het selecteren van andere records bleef traag.

Een aantal dingen die ik geprobeerd heb:
- Kernel AOS/client bijwerken (laatste versie op dit moment: 5.0.1600.3696)
- Al het maatwerk in de basis zoals SysSetupFormRun, Info, Application etc. die eventueel problemen zou kunnen veroorzaken verwijderen (echt de laag zelf verwijderen).
- Diverse calls zoals yield(), winapi calls die ik kon vinden die mogelijk messages voor een form afhandelde / opschoonde. 
- Applicatie zaken (verwijderen UAC, verwijderen *.I, met herstart AOS uiteraard)

Andere bevindingen;
- Vanaf de TS was het sneller dan rechtstreeks op de server. Dit kan verklaard worden doordat resources op de server beperkter zijn (SQL server wil nogal geheugen claimen). Het scherm opende wel sneller, maar het selecteren van andere records bleef traag tot het scherm geminimaliseerd / gerestored is.
-  Het maakt niet uit voor de server: Windows 2012 R2 met client applicaties en de Ax client die verbinding maakt met een Windows 2008 AOS+DB heeft dezelfde eigenschap als alles op één Windows 2008 machine (client en AOS en DB)
- Aangezien het minimaliseren / restoren van het Form al het euvel verhelpt en de kaalheid van het form, is het mijn insteek dat het niet in de applicatie van Ax zit maar mogelijk in de Ax client zelf icm windows al-dan-niet icm een derde applicatie.

Uiteindelijk heb ik deze functionaliteit meegenomen in de applicatie;





Dus alleen velden dit zicthbaar zijn aan het eind van de init -> verbergen


Dus alles dat inzichtbaar is gemaakt, weer zichtbaar maken. Een minimize/restore kan ook, zie uitgecommentarieerde code. Maar dat flikkert wel het scherm dus.

De timeout in de run:


Dit is geen oplossing voor het probleem, maar meer een workaround voor de symptomen. Tot zover... mocht iemand zoeken naar performance problemen, kan je hier misschien wat mee. Als iemand anders nog ideeën of tips heeft,  dan hoor ik dat ook graag.

Verkeerde BIN directory

Bij het gebruik van externe DLL bestanden maak ik gebruik van Reflection. Deze laad ik daarmee dynamics vanuit de client BIN directory. Dit omdat .NET assemblies die je toevoegt als Reference fouten geeft bij ontwikkelaars die de DLL niet hebben.

Om de DLL te laden, gebruik ik mede de code : xinfo::directory(DirectoryType::Bin)

Echter was na een server upgrade een batchproces ontregeld. Reden was dat een DLL niet gevonden kon worden. Het bleek dat deze code een oude, 32-bit Bin directory terug gaf. Vanaf dezelfde machine, zelfde account vanaf mijn machine RDP:

 Op dezelfde server, door een gebruiker RDP: 

Oorzaak was een fout in het configuratie bestand. De klant gebruikte een configuratie bestand welke een fout had: 

 

Hier ontbrak de (x86) markering die de juiste locatie bevat. 

Lege label waarde

Soms wil je een label maken wat alleen een waarde in een bepaalde taal heeft. Als je dan een andere taal niet opgeeft, krijg je de leuke '@xxx15' melding dat je erop attendeert dat een bepaalde label geen vertaling heeft. Maar soms op rapportages wil je nou juist dat bepaalde talen geen label hebben.

Als je probeert een spatie op te voeren bij een label, trimt Ax standaard de invoer. Dus je kan niet even een spatie erin zetten.

Simpele oplossing: bij een lege label waarde, gebruik dan een NBSP (non-breaking space). Houd de linker ALT ingedrukt, voer 255 in op je numpad en voila: een spatie welke Ax niet trimt.













Simpel maar effectief:

Kopieer een groot binair bestand naar de server

De meest makkelijke manier om een binair bestand naar de server te communiceren is met behulp van de bindata componenten:

Effectie wordt deze wijze ook gebruikt om documenten in de database op te slaan in document-verwerking functionaliteit. Hier gebruik ik even de 'appendToFile'. Vreemd genoeg is in Ax 2009 (SP1) geen FileIOPermission nodig, maar dat is even niet het punt. Het punt is als het bestand te groot wordt (12MB):

"The Dynamics Ax session is no longer valid" op het moment dat de setData wordt aangeroepen. Dit gebeurd ook als je documentverwerking opslaat in de database en even het limiet hoog genoeg zet.

Je kan proberen de getData eerst toe te wijzen aan een container, maar wederom gaat bij setData dit fout.

Het bindata object heeft een methode: copyData. Leuke functie met een offset en grootte. Zou je de buffer in delen naar de server kunnen sturen, maar helaas:

Dit is zelfs erger. Deze actie zorgt ervoor dat de AOS gewoon crashed.

De enige oplossing die ik zover heb gevonden is het eerst kopieren naar een kleine buffer en die dan serverside toe te voegen:

Code:

static void Example_File2_C(Args _args)
{
    BinData clientBin    = ClassFactory::makeObjectOnClient(classnum(BinData));
    BinData clientBinTmp = ClassFactory::makeObjectOnClient(classnum(BinData));
    BinData serverBin    = ClassFactory::makeObjectOnServer(classnum(BinData));
    str fileName = @"C:\Ax\Client\file2.bin";
    str fileNameServer = @"C:\Ax\Server\file2.bin";
    int fileSize;
    int offset;
    int bufferSize = 1024*1024; // 1MB;
    ;
    #file

    clientBin.loadFile(fileName);
    fileSize = clientBin.size();
    offset = 0;
    while (offset < fileSize)
    {
        clientBinTmp.copyData(clientBin, offset, bufferSize);

        serverBin.setData(clientBinTmp.getData());
        serverBin.appendToFile(fileNameServer);

        offset += bufferSize;
    }

    info('Done!');
}
Dit behoud niet de bestandsinformatie (gemaakt op datum, NTFS beveiliging etc.) maar de data is serverside. Nog een leuke progress-bar om de gebruiker tevreden te houden en je hebt een manier. 

Unable to load page–Ax portal via business connector

Een nieuwe installatie van een Ax 4.0 sharepoint omgeving op een windows 2008 machine gaf een fout bij het maken van de PDF: ‘Unable to load page.’ in de eventlog. De PDF zelf is intern zo goed als leeg::

Er zijn veel artikelen te vinden over dit onderwerp, en de fout leek veroorzaakt te worden door de Ax client, of in dit geval de business connector gezien dat het een portal is. Maar SP2 met de hotfix is geïnstalleerd en bij het starten van de setup zegt de setup-util dat de versie al geïnstalleerd zijn. De business connector DLL in de client bin bevestigt dit verhaal:

    Version 4.0.2503.1872.

Middels een simpele info in een portal webform kreeg ik echter een andere versie:

    Kernel version: 4.0.2163.0

Runtime was de versie dus 4.0.2163.0 (SP1). In de GAC (Global Asembly Cache) was inderdaad een andere DLL geïnstalleerd:

Oplossing was simpel: opnieuw registeren van de DLL in de client bin map. Maar deze productie server had geen powerhell of .NET SDK toolkit (gacutil.exe) om een DLL te registreren. Daarop heb ik tijdelijk even de toolkit van mijn laptop (Windows 10) gekopieerd naar de server::

C:\Program Files (x86)\Microsoft SDKs\Windows

Er zijn 3 mappen: gacutil zit in 2 van deze mappen(v7.0a en v8.0a). Gebruik hier de v7.0a, bij de v8.0a krijg je een melding: :

entry point was not found

De volgende DLL's heb ik geregistreerd:

• C:\Program Files\Microsoft Dynamics AX\40\Client\Bin\Microsoft.Dynamics.BusinessConnectorNet.dll
• C:\Program Files\Microsoft Dynamics AX\40\Client\Bin\Microsoft.Dynamics.ClrBridge.dll
• C:\Program Files\Microsoft Dynamics AX\40\Client\Bin\NL\Microsoft.Dynamics.BusinessConnectorNet.resources.dll

En nu is de portal het met mij eens over welke versie er is:

En de PDF wordt weer juist gegenereerd.  

Actie uitvoeren in een actieve Ax client van extern

Soms is het wenselijk dat Ax iets doet, wat wordt getriggerd vanuit een externe applicatie. Een proces dat communiceert met een andere proces wordt ook wel IPC (Inter-process-communication) genoemd. Een voorbeeld; de telefoon gaat. Op basis van het telefoonnummer kan worden herleid welke klant belt en je wilt direct zien wat er speelt bij een klant. Nu heeft Ax wel een TAPI interface, maar als dat niet mogelijk is…
Standaard heeft Ax een zogenaamde ‘named pipe’. Een named pipe kan je zien als een message-queue in standaard Windows die je aanmaakt en een listener op zet. Beetje vergelijkbaar met een map die actief gepolled wordt; zodra er een bestand binnenkomt wordt dit herkent en kan je er iets mee. Er staat al een goede blog van Max Belugin online die dit omschrijft: http://axcoder.blogspot.nl/2010/10/how-to-open-form-in-running-ax-from.html

Samengevat:
Elke Ax client maakt named-pipe aan met het formaat: Dynamics\Event\0S-1-5-5-x-xxxxxx

• Dynamics\Event – dit is een vaste waarde
• 0 – dit is de waarde ingericht in Ax. Basis \ Instellingen \ Waarschuwingen \ Waarschuwingsparameters:

• S-1-5-5-x-xxxxxx – dit is een Security Id (SID) voor de logon sessie. Dit is dus _niet_ de SID van de gebruiker. Dit is even interessant: de sessie is per gebruiker uniek op een terminal server, zodat de named pipe expliciet voor die gebruiker is en niet andere gebruikers gaat aansturen. Maar: als een gebruiker meerdere Ax sessies open hebt staan (zelfde of meerdere omgevingen), dan lijkt het de langst-actieve client die de queue afhandelt. Met de vorige parameter (Doel voor drilldown) zou je wel een test-omgeving een andere Id kunnen geven. 

De blog van Max omschrijft het mooi met een voorbeeld .NET applicatie. Daar ga ik dan ook niet verder op in. Het ophalen van de logon-session-SID heb ik even bekeken, maar ik kan het zo ook niet mooier maken.

Wat iets meer in de oplossing zit van Max maar niet is verwoord, is wat er nou gebeurt in Ax:
1. De class ‘EventDrillDownPoller’, methode ‘scheduledPoll’

 1 void scheduledPoll()
 2 {
 3     str pipeData;
 4     SysStartUpCmd cmd;
 5     ;
 6     if (pipe)
 7     {
 8         pipeData = pipe.read();
 9         if ('' != pipeData)
10         {
11             cmd = SysStartUpCmd::construct(pipeData);
12             if (cmd) // INT - check null value
13                 cmd.infoRun(); 
14             this.createPipe(); // Re-create the pipe in order to be ready for the next command.
15         }
16         infolog.addTimeOut(this, methodstr(EventDrillDownPoller, scheduledPoll), #idleTimeBetweenExternalDrillDownPolls);
17     } 
18 }

Deze methode wordt regelmatig (<1 seconde) indien de Ax client is idle uitgevoerd. Regel 12 heb ik toegevoegd; de SysStartupCmd kan namelijk null terug geven als het commando niet herkend wordt. Op zich is de nullpointer fout iets dat je een gebruiker niet wilt geven, maar het echte probleem is dan dat de createPipe en addTimeOut niet aangeroepen wordt en daarmee stopt deze queue. Het is ook best-practice om data (en commando’s) van externe applicaties te valideren voordat je deze verwerkt, zou ik zeggen.

2. De SysStartUpCmd en afstammeling doet eigenlijk het werk:

 1 static SysStartupCmd construct(str startupCommand) 
 2 { 
 3     str             s = strLRTrim(startupCommand); 
 4     int             p = strscan(s,'_',1,strlen(s));
 5     str             parm;
 6     SysStartupCmd   sysStartupCmd; 
 7     ; 
 8     if (p)
 9     {
10         parm    = substr(s,p+1,strlen(s));
11         parm    = strrem(parm,'"');
12         s       = substr(s,1,p-1);
13     } 
14     setprefix(s);
15     switch (s) 
16     { 
17         case 'setbuildno': 
18             sysStartupCmd = new SysStartupCmdBuildNoSet(s,parm);
19             break; 
20         ... 
21         case 'callincomming':
22             // INT - process call
23             sysStartupCmd = new SysStartupCmdCallIncomming(s,parm); 
24             break; 
25     }
26     if (sysStartupCmd) 
27     { 
28         if (sysStartupCmd.canRun())
29             return sysStartupCmd; 
30         error(strfmt("%1, %2", s, parm)); 
31         error("@SYS81158");
32     } 
33     return null;
34 }

Regels bij 20 even voor de overzichtelijkheid wat code weggehaald. In deze methode wordt op basis van de aangeleverde waarde een commando uitgevoerd. Hier zit je al in de actieve thread van Ax en kan je alles doen. Open een form, geef een alert, maak een record aan, wat je wil. Maar je kan het ook doen zoals de reeds bekende commando’s, maak een SysStartupCmd subclass aan en beperkt de aanpassing tot een extra case in de switch. Nu het commando: deze bestaat uit minimaal één en maximaal twee delen: <command>_<parameter>, dus met underscore. In dit voorbeeld: als je het commando “callincomming_0221234567” dan splitst standaard Ax in regels 10 t/m 12 het commando en wordt de parameter als zodanig doorgegeven. Je kan zelf dit weer met een sub-scheidingsteken splitsen en in je eigen class verwerken.

Of als je veel commando’s denkt nodig te hebben, dan kan je de code beperken met de volgende switch:

 1     ClassName       className; 
 2     ClassId         classId; 
 3     SysDictClass    sysDictClass; 
 4     ;
 5     ... 
 6     default: 
 7         // INT - use action name for classname
 8         className = classid2name(classnum(SysStartupCmd)); 
 9         className += s; 
10         classId = classname2id(className); 
11         sysDictClass = new SysDictClass(classId);
12         if (sysDictClass
13         &&  sysDictClass.allowMakeObject())
14         { 
15             sysStartupCmd = sysDictClass.makeObject(s,parm); 
16         } 
17         break;

Workflow Werknemer-ID is niet ingesteld of de record voor %1, %2 is niet gevonden.

Bij het aanbieden van bijvoorbeeld een inkooporder aan de workflow worden verschillende automatische controles uitgevoerd. De foutmelding Werknemer-ID is niet ingesteld of de record voor %1, %2 is niet gevonden. geeft heel feitelijk aan wat er fout is.

Voor elke medewerker moet een bijbehorende gebruiker zijn aangemaakt. Of anders gezegd aan elke gebruiker moet een medewerker zijn gekoppeld.

Controleer bij systeembeheer, gebruiker



Optie Relaties:

Gebruiker zonder relatie

Voor deze gebruiker bestaat geen relatie, zoals de foutmelding "Werknemer-ID is niet ingesteld of de record voor %1, %2 is niet gevonden." ook duidelijk aangeeft.

De volgende situatie geeft echter ook dezelfde foutmelding:  

Gebruiker met een relatie

In de situatie hierboven wordt dezelfde foutmelding gegeven. Dit lijkt incorrect immers er is toch relatie voor de gebruiker? Inderdaad is aan de gebruiker een relatie gekoppeld. Echter de relatie is niet van het type werknemer. Dit is alleen te zien door het ontbreken van een afbeelding onder het kopje medewerker.

Gebruiker met een correcte relatie

Alleen indien een medewerker gekoppeld is aan de gebruiker zal de foutmelding Werknemer-ID is niet ingesteld of de record voor %1, %2 is niet gevonden. niet voorkomen. Het verschil met de voorgaande koppeling is het icoontje onder de kolom medewerker.