Ax 2012 op Windows Server 2016, Sharepoint 2013

Tot dusver is er geen support van Ax 2012 voor Windows server 2016, maar het is wel te installeren en te gebruiken. SQL Server 2016 wordt wel ondersteund vanaf R2 CU9 met een paar hotfixes.

Er is nog wel een uitdaging, op het moment dat Windows Server 2016 wordt gebruikt; het rollencentrum. Ax 2012 ondersteund geen Sharepoint 2016 en de ondersteunde versie 2013 wordt niet ondersteund op Windows server 2016. Naast dat je het rollencentrum nog op een 2012 server kan installeren, het kan ook werken op een 2016 server met een instructie.

Bij de installatie krijg je de volgende validatie:








De koppeling achter Microsoft SharePoint geeft een 404. Je kan deze nog wel downloaden:
https://www.microsoft.com/nl-nl/download/details.aspx?id=42039

Om sharepoint te installeren, heb je nog wat meer instructies nodig. Alle credits voor Roger: http://roger.dilsner.com/install-sharepoint-foundation-2013-windows-server-2016-solution/ Voor de details, ga naar deze post. Maar samengevat; de prerequisiteinstaller van Sharepoint 2013 kan niet de benodigde installaties doen van randsoftware. Een paar goed geplaatste powershell commando's doet dit wel:
Import-Module ServerManager

Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45

Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer



Met een andere dll vanuit deze link: https://download.microsoft.com/download/3/6/2/362c4a9c-4afe-425e-825f-369d34d64f4e/wsssetup_15-0-4709-1000_x64.zip die de wsssetup.dll in de root map van de installatie bestanden vervangt, lukt het wel om om Sharepoint 2013 met SP1 te installeren op Windows server 2016.

Sharepoint kan hiermee geïnstalleerd worden en daarna voldoet de omgeving aan de vereisten voor de installatie van het rollencentrum:




Zelf heb ik hierbij gebruik gemaakt van een slipstream installatie van 2012 R2 CU9;



Er was nog één laatste obstakel. De website werkte lokaal prima, maar remote niet. De Windows integrated authentication werkt niet naar behoren; als op IIS niveau middels Basic-authentication werd gewerkt, werkte de site wel. Maar bij wia kwam er 3x een login venster, een leeg scherm en geen reden:


Duurde even ,maar de website werkte met de volgende optie wel goed:


Deze vink stond uit.

En daarmee: Ax 2012 R2 CU9 op Windows server 2016, SQL Server 2016 en Sharepoint 2013. 

Bronnen
http://roger.dilsner.com/install-sharepoint-foundation-2013-windows-server-2016-solution/
https://blogs.technet.microsoft.com/dynamicsaxse/2016/08/02/announcing-support-for-office-2016-and-sql-server-2016-with-ax-2012-r3-and-r2/
https://download.microsoft.com/download/3/6/2/362c4a9c-4afe-425e-825f-369d34d64f4e/wsssetup_15-0-4709-1000_x64.zip
https://www.microsoft.com/nl-nl/download/details.aspx?id=42039

Modules niet langer aanwezig in navigatiemenu

Een gebruiker melde dat het navigatiescherm niet meer toegang gaf tot de verschillende modulen. Favorieten waren nog wel zichtbaar een gebruikbaar, maar er kon niet langer een module geopend worden. Het onderste deel van de modulen was weg;


Ook de slider was weg, dus het menu kon niet ophoog getrokken worden. De >> was er dus ook niet. AUC verwijderd en ook onder het account van de gebruiker zijn usersettings weggegooid. Geen effect. Onder weergeven \ Navigatievensteropties kan je het menu 'opnieuw instellen' maar dat had geen effect.

Oorzaak was wel de usersettings. Maar zoals normale usersettings worden deze opgeslagen als je het venster sluit. Het menu sluit je als je Ax herstart, dus dan worden usersettings weer opgeslagen. Dit had ik opgelost door Ax af te sluiten bij deze gebruiker, en met de tablebrowser van de resourcenodes de syslastvalue tabel te openen en de volgende records te verwijderen bij de geburiker:
Mogelijk was de NavPaneOpionsButtons al voldoende.

Het is mij vaker opgevallen dat usersettings 'corrupt' lijken. Schermen die een vaste grootte hebben die ineens alleen een titelbalk hebben als voorbeeld. Niet alleen Ax 4.0, ook 2009 en 2012.

Performance compileren productbuilder

In Ax 4.0 genereerd de productbuilder effectief een class welke middels code de bepaling zoals visueel is weergegeven in X++ vertaald. Bij complexe modellen kan het zijn de class hierdoor 1000-en methoden krijgt. Dit is onvoorkomenlijk, inherent aan de technische realisatie van deze functionaliteit.

Het kan echter voorkomen dat het compileren van een productmodel het systeem laat bevriezen. Een model dat 2975 methoden genereerd, gaf ik na 30 minuten de opdracht tot afbreken. De oorzaak zit hem in de compiler van deze funcionaliteit;



Effectief: ga alle methodes langs en verwijder deze. Bij 2975 methoden doet dit meer dan een seconde per methode, dus ongeveer 50 minuten. Dat is slechts één onderdeel van de stappen, maar de oorzaak waarom het lang duurt.

Dit heb ik vervangen door het volgende:



Effectief: verwijder de class en maak deze opnieuw aan met behoud van ID. Anders gaat het ID's gebruiken en dat is minder makkelijk als in dezelfde laag ook nog ontwikkeld wordt in een DEV omgeving en er ID conflicten gaan ontstaan.

code:
    TreeNode            methodNode;
    TreeNodeIterator    nodeIterator;
    UtilIdElements  utilIdElements; // INT561
    TreeNode tn;
    ;
    if (useClasses)
    {
        classBuild.classNode().AOTrestore();
        classBuild.classNode().AOTsave();
        // INT561
        // Drop & recreated with existing ID much more efficient then
        //  delete all subnodes (methods).
        utilIdElements.initValue();
        utilIdElements.Name = classBuild.classNode().name();
        utilIdElements.recordType = UtilElementType::Class;
        utilIdElements.Id = classbuild.classNode().iD();
        classBuild.classNode().AOTdelete();
        utilIdElements.insert();
        tn = xUtilIdElements::getNode(utilIdElements);
        if (tn)
        {
            tn.AOTcompile(1);
            tn.AOTsave();
        }
        classBuild = new classBuildConfigurator(utilIdElements.name, true);
        // INT561
        this.addSource2TreeSource(PBA::_pbaSourceArgs() + PBA::cr() + PBA::start() + PBA::cr() + PBA::tabSpace() + PBA::callSuper() + PBA::cr() + PBA::tabSpace() + PBA::PBAInitCall(useClasses) + PBA::cr());
Hierbij heb ik gebruik gemaakt van deze link:
 http://www.axaptapedia.com/ClassBuild_Class

Applicatie lagen corrupt

Ax maakt gebruik van een mooi lagen-systeem, waarbij de basis applicatie in de SYS laag zit, oplossing van partners in onder andere de BUS, de VAR voor de value-added-reseller, CUS voor klant specifiek en USR voor de gebruikers. Om maar een paar te noemen, want met Ax 2012 komen er nog een paar bij. Nu is het normaal zo dat een ontwikkelaar in een bepaalde laag AX opstart en code daarin alleen maar in die laag komt. Maar soms doet Ax rare dingen. Zo liep ik tegen het probleem aan dat ik een methode niet kon verwijderen die ik net had aangemaakt. Ax beweerde dat deze in een andere laag zat. Als ik inlogde in die laag, dan was die methode er niet. Samengevat had ik het terug kunnen brengen tot dit:

Ik log in in de CUS laag:


Nieuw form, override de run:


Zoals je ziet aan de AddressCountryRegion, worden alle lagen getoond van een element. Form1 bestaat enkel in de CUS laag. Ik verwijder de RUN:

 De run zit in de VAR? Samengevat; ik krijg deze run er niet meer uit.

Diverse zaken geprobeerd. UAC file verwijderen, AOI file verwijderen, AOS herstart uiteraard andere terminal server, zelfs de nieuwste kernel van Ax 2009. 

Uiteindelijk heb ik de applicatie opnieuw opgebouwd. Dit deed ik in de volgende stappen in een TEST ogmeving:

1. Bepaal de lagen waarin code zit. In dit geval: CUS, VAP, VAR, BUS en SYP/SYS.
2. Op volgorde van USR tot de SYP (SYS/SYP dit zelf niet):
      a. Maak een project met alle elementen in de laag
      b. Exporteer het project, met behoud van ID's. _alles_; dus niet alleen die laag
      c. Stop de AOS, verwijder de AOI en AOD file uit de applicatie, start de AOS

Nu had ik per laag de elementen van die laag en een Ax omgeving met enkel de SYS/SYP laag.
TIP: zet nu een breakpoint in de Application.dbSynchornize:

Bij een grote test database is het nogal een zware operatie en het is zonde als applicatie nog niet af is. Een return true; werkt ook, maar als de Application class is aangepast in de laag dan wordt deze code ongedaan gemaakt. Zet variabele 'ok' op true en sleep de executiepointer naar de volgende regel (dus de super niet uitvoeren)

Vanaf het laatste laag-project dat gemaakt is, per laag-project:
3. Importeer met behoud van ID's de elementen en verwijderen elementen. Soms zijn meerdere keren import nodig; een EDT verwijst naar een tabel en dezelfde tabel naar een EDT, krijg je bij een eerste import compilatie problemen.
4. Compileer het project en controleer op compilatie fouten.


Het kan zo zijn (in mijn geval) dat de partner code in de VAR laag had gebasseerd op code in de CUS laag. Dus bij de import in de VAR kreeg ik dus fouten en moest elementen uit de CUS in de VAR laag overzetten. Bij database tabellen/velden is dit lastig vanwege databehoud, dus ik had besloten delen in de CUS laag al op te leveren voordat de VAR laag compileerde. Het was bij mij zelfs zo, dat de BUS laag enkele marco's uit de SYP laag had verwijderd die in de VAR laag weeg waren toegevoegd. Even logisch verstand gebruiken bij deze gevallen.

Bij de 2e import van de CUS laag liep ik nog tegen een melding aan:
 Bezig met importeren van class INTEditLinesView met ID 41375. ID is al geactiveerd door class INTEditLinesDialog. In de AOT is er inderdaad een INTEditLinesDialog met ID 41375, de XPO:

Vanwege onduidelijke redenen is er een verschil in de export tussen deze waarden. Na correctie met notepad in de xpo ging het wel goed.

Na de laatste laag een volledige compilatie en synchronisatie. Omdat de ID's van de dataelementen hetzelfde zijn, zou je nu een database restore kunnen doen van Live of Dev om de applicatie te testen. Er zou geen dataverlies mogen optreden, wat uiteraard onwenselijk is.

Nu was het wel mogelijk methoden weer te verwijderen.