Oftmals besteht die Anforderung, über einen Zeitgesteuerten Job (Batchjob), das Generieren von statistischen Berichten, welche in einer Datei gespeichert werden soll, zu automatisieren.
Microsoft Dynamics AX stellt hierfür die Möglichkeit bereit, jeden Bericht mithilfe der Stapelverarbeitung zu einem definierten Zeitpunkt zu generieren und in einer Datei, z.B. in einem Netzwerklaufwerk, bereit zu stellen.
Soweit stellt dies kein Problem dar, da über den Standard von Dynamics AX diese Anforderung ohne weiteres erfüllt werden kann.
Leider wird hierbei oft vergessen, dass der entsprechende Batchserver (AOS) so konfiguriert werden muss, dass dieser das “Drucken auf dem Server” zulassen muss.
Dies ist eine Einstellungsoption des Serverkonfigurations-Utilities.
Weiterhin sollte bei der Angabe der Datei bzw. des Speicherortes der Datei immer ein UNC-Pfad verwendet werden, da die eigentlich Ausführung des Berichtes und somit auch die Erstellung der Datei über das Benutzerkonto des AOS-Dienstes geschieht.
Dies bedingt auch, dass entsprechende Berechtigungen für das Dienstkonto des Batchservers (AOS) für das freigegebene Verzeichnis vergeben werden müssen, damit die Datei und somit der Bericht erfolgreich erstellt werden kann.
Eine weiterführende Beschreibung hierzu ist auch im EMEA Dynamics AX Support Blog zu finden.
In Microsoft Dynamics AX existiert ein Feature, um Aufgaben (Jobs), welche durch entsprechende Klassen bereit gestellt werden, zu planen und zu einem geplanten Zeitpunkt auszuführen.
Dies wird in Dynamics AX als Stapelverarbeitung (Batch-Framework) bezeichnet.
Jeder Stapelverarbeitungsauftrag verfügt über einen Status, der angibt, in welchem “Zustand” sich der jeweilige Stapelverarbeitungsauftrag befindet.
Über die Funktion, “Funktionen –> Status ändern” kann dieser Status durch den Benutzer geändert werden.
Beim Auswählen des “neuen” Status ist leider ein wenig Vorsicht geboten, da bei einem falschen Klick der gesamte Stapelverarbeitungsauftrag unbrauchbar gemacht werden kann.
Drückt man zufällig nicht auf einen der durch die Maske angebotenen Werte, so wird der Status der Stapelverarbeitungsauftrags gelöscht.
Das unschöne hierbei ist, dass dieses “Status löschen “nicht mehr rückgängig gemacht werden kann (jedenfalls nicht durch die Dynamics AX Masken).
Bei dem Versuch, wieder einen korrekten Status zu vergeben (ebenfalls über die Funktion “Status ändern”) wird leider nicht der gewünschte Status gesetzt, sondern eine Fehlermeldung ausgegeben.
Die einzige Möglichkeit, wieder eine korrekten Status zu setzten, besteht leider darin, einen kleinen Job zu schreiben (mit X++), welcher den Status per Programmcode ändert.
Ist gerade kein Entwickler “zur Hand”, besteht nur die Möglichkeit, den Stapelverarbeitungsauftrag zu löschen und erneut anzulegen (dies kann aber von Fall zu Fall sehr aufwändig sein).
Wird Microsoft Dynamics AX 2009 mit Windows Server 2008 und SQL Server 2008 installiert, kann es zu einem Problem bei Bereitstellen der ODC-Dateien kommen.
Nach dem Aufruf der Funktion „ODC-Dateien bereitstellen“ meldet Dynamics AX 2009 einen Fehler im Infolog.
Diese Fehlermeldung wird ebenfalls im Ereignislog von Windows protokolliert.
Laut einem Artikel im EMEA Dynamics AX Support Blog ist hierfür ein Hot Fix erhältlich.
https://blogs.msdn.com/emeadaxsupport/archive/2009/04/23/unable-to-deploy-odc-files-to-enterprise-portal-even-after-installing-hotfix-kb960158.aspx
Wurde allerdings schon das Hot Fix Rollup 2 für Dynamics AX 2009 (SP1) installiert, wird das beschriebene Hot Fix nicht mehr benötigt.
Um nun die ODC-Dateien erfolgreich bereitstellen zu können muss wie folgt vorgegangen werden:
- Das bereits installierte Enterprise-Portal muss aktualisiert werden
(Verwaltung/Einstellungen/Internet/Enterprise Portal/Bereitstellungen verwalten/ Button „Aktualisieren“ wählen)
- Nun (sicherheitshalber) den IIS neu starten, z.B. durch Aufruf von „iisreset“
- Anschließend können die ODC-Dateien bereit gestellt werden.
(Verwaltung/Einstellungen/Unternehmensanalyse/OLAP/Olap-Verwaltung/ Button „ODC-Dateien bereitstellen“ wählen)
Ob das Bereitstellen der ODC-Dateien funktioniert hat, kann überprüft werden, indem man kontrolliert, ob die entsprechende Bibliothek im SharePoint die ODC Dateien enthält.
http://<servername>/websites/DynamicsAx/Data%20Connections/Forms/AllItems.aspx
Wie in einem Artikel auf der Microsoft Dynamics AX Webseite zu lesen ist wird der "alte" COM Business Connector nicht mehr in zukünftigen Versionen von Dynamics AX enthalten sein.
The COM Business Connector will be discontinued in future releases of Microsoft Dynamics AX
Bereits in der Version 2009 von Microsoft Dynamics AX wird der COM Business Connector vom "normalen" Setup nicht mehr angeboten.
Dieser muss manuell, wie im Microsoft Dynamics AX Developer Center beschrieben, nachinstalliert werden.
How to: Install COM Business Connector using Command-line Options
Somit ist es an der Zeit, bestehende Lösungen welche den COM Business Connector verwenden, auf den neueren .NET Business Connector zu portieren, um diese Lösungen auch in zukünftigen Versionen verwenden zu können.
Alle benötigten Informationen über die Verwendung des .NET Business Connectors können in der Library des Microsoft Dynamics AX Developer Centers gefunden werden
.NET Business Connector Overview
Das Application Integration Framework von Dynamics AX basiert auf Dokumenten (Axd<Document> Klassen).
Eigene Dokumente lassen sich reicht einfach per Hand oder mit Hilfe des Dokumenten-Wizards erstellen.
In der Version 2009 von Dynamics AX erstellt dieser Wizard auch gleichzeitig den benötigenten Service (WCF-Webservice) und andere benötigte Elemente wie (Serviceklassen und Macros).
Welche Schritte hierfür benötigt werden ist zum Beispiel im Microsoft Dynamics AX Developer Center beschrieben.
Ein kleines Problem entsteht, wenn das neue Dokument, genauer gesagt die Elemente oder Objekte des Dokuments, in einem Layer (zum Beispiel CUS-Layer) entwickelt wird und später, aus welchen Gründen auch immer, alle Objekte des Dokuments (Query, Ax<Table> Class, Axd<Document> Class) in einen anderen Layer (zum Beispiel VAR-Layer) verschoben werden.
Nach der "Verschiebung" des neuen Dokuments in einen anderen Entwicklungslayer werden durch die AIF-Konfigurationsmasken (siehe Maske Dienstleistungen) allerdings keine Operationen (Insert, Update, Delete, FindKey, etc.) mehr angezeigt.
Auch an anderen Stellen, wie zum Beispiel der Endpunktkonfiguration, sind die entsprechenden Operationen nicht mehr auswählbar oder vorhanden.
Der Grund hierfür liegt in der ClassId der Serviceklasse des neuen Dokuments. Dieser, wie auch jedem anderen Objekt, wird beim Import in einen anderen Layer eine neue ID zugewiesen, wenn nicht explizit angegeben wurde, dass der Export und Import mit ID's erfolgen soll. So kann es sein, dass die Klasse mit der ID 40001 nach dem Import in einen anderen Layer die ID 300001 zugeordnet ist.
Da wärend der Konfiguration des AIF's der AOT nach Dokumenten/Services durchsucht wird und für jedes Dokument bzw. jeden Service ein Datensatz in der Tabelle "AifService" sowie ein bis mehrere Datensätze in der Tabelle "AifAction" erzeugt wird, welche alle eine Referenz auf die ClassId der Serviceklasse enthalten, kommt es jetzt zu dem genannten Problem.
Der Id 40001 ist nun keine Klasse oder noch schlimmer eine andere Klasse zugewiesen. Auch eine "Aktualisierung" dieser Datensätze über die Aktualisierungsfunktion, welche auf der Maske Dienstleistungen bereit gestellt wird, führt nicht zum gewünschten Erfolg.
Genau in dieser Funktion scheint sich ein kleiner Fehler eingeschlichen zu haben. Dort wird zwar eine Aktulisierung der ClassId für die Datensätze der Tabelle "AifService", aber nicht für die Datensätze der Tabelle "AifAction", durchgeführt.
Um diese Verhalten zu reproduzieren, muss folgendes gemacht werden:
- Erstellen eines neuen AIF Dokuments bzw. AIF Services.
- Über die Maske Dienstleistungen, zu finden unter "Grundeinstellungen -> Einstellungen -> Application Integration Framework -> Dienstleistungen", Funktion "Aktualisieren" das neue Dokument / den neuen Service "aktivieren".
- Über den Button "Servicearbeitsgänge" können nun alle Operationen welche durch das Dokument / den Service bereit gestellt werden eingesehen werden.
- Verschieben aller Elemente des Dokuments / des Services in einen anderen Layer.
- Schritt 2 erneut druchführen.
- Über den Button "Servicearbeitsgänge" werden keine Operation mehr angezeigt.
Um dieses Problem zu lösen, gibt 2 Möglichkeiten.
Entweder manuelles Löschen alle zu diesem Dokument/Service gehörigen Datensätze der Tabelle "AifAction" oder aber man ergänzt die Methode "registerOperations" der Klasse "AifServiceGenerationManager" um ein wenig X++ Code (bei Zeile 43) welcher nicht nur den Namen der Operation aktualisiert sondern auch die ClassId.
Da dieser Code sehr einfach ist verzichte ich an dieser Stelle auf ein Beispiel.
Leider tritt dieses Problem auch mit Dynamics AX 2009 Service Pack 1 auf.
Im Standard von Microsoft Dynamics AX 2009 werden verschiedenste Business Intelligence Funktionen mitgeliefert.
Die hierfür benötigen Cubes und Dimensionen erstellt Dynamics AX 2009 unter Verwendung der Analysis-Extension direkt in den Analysis Services des SQL Servers.
Dies ist schon einmal sehr schön, da die meiste Arbeit durch die Installationsroutinen abgenommen wird.
Muss oder möchte man allerdings die mitgelieferten Cubes oder Dimensionen an die eigenen Gegebenheiten anpassen, muss zuerst ein BI-Projekt für Visual Studio erzeugt werden, da die Bearbeitung in Visual Studio erfolgt (über die Funktion „BI-Projekt generieren“).
Es können einige „allgemeine“ Einstellungen für die Erstellung eines BI-Projektes über die Funktion „Generierungsoptionen für BI-Projekt“ getätigt werden.
Beispielhaft sei hier die Einstellung der Zeitdimensionen genannt.
Allerdings kann es sein, dass man anstatt der erwartet Maske eine Fehlermeldung ausgegeben bekommt.
Dies kann besonders bei Verwendung, der für Dynamics AX 2009 bereit gestellten, Demo Daten der Fall sein.
Leider ist diese Fehlermeldung nicht sehr Aussagekräftig.
Hier hilft ein Blick in das Ereignisprotokoll des Dynamics AX Object Servers.
Dies lässt zumindest schon einmal den „groben“ Grund erkennen, was für ein Fehler verursacht wurde bzw. wo der Fehler liegen könnte.
Nach einem Blick in die Tabellendefinition und den Tabellebrowser der angegebenen Tabelle „BIUDMROLES“ wird man feststellen, dass es die angegeben Spalte wirklich nicht gibt. Es gibt aber einen Datensatz mit entsprechender UserGroupId (UserGroupId = PRComplete). Verwendet man nun die Funktion „Gehe zu Haupttabelle“, wird man feststellen, dass es diese Benutzergruppe nicht im System gibt.
Somit ist die Lösung recht einfach.
Nachdem der Fehlerhafte Datensatz gelöscht wurde, kann die Maske „Generierungsoptionen für BI-Projekt“ ohne Probleme geöffnet werden.
Im wieder taucht in den Newsgroups und einschlägigen Foren die Frage auf, ob es möglich ist, Dynamics AX 2009 unter Windows Server 2008 und/oder in Verbindung mit SQL Server 2008 zu betreiben.
Die Antwort auf diese Frage lautet eigentlich „Ja“, zugleich aber auch „Nein“.
Offiziell sind die beiden Produkte zwar noch nicht für die Verwendung mit Dynamics AX 2009 freigegeben, aber prinzipiell funktioniert Dynamics AX 2009 auch mit dieser Systemkonfiguration (Kernfunktionalität).
Allerdings muss auch erwähnt werden, dass der eine oder andere Punkt bei der Installation bzw. beim Betrieb von Dynamics AX 2009 mit Windows Server 2008 und/oder dem SQL Server 2008 für Verwirrung sorgen kann.
So wird, nach erfolgreicher Installation der Basiskomponenten von Dynamics AX 2009 und anschließendem AOS Start, eine Fehlermeldung im Ereignisprotokoll von Windows Server 2008 erzeugt, welche aussagt, dass Dynamics AX 2009 (genauer der AOS) das gewählte Betriebssystem nicht unterstützt.
Ungeachtet dieser Fehlermeldung, läuft der AOS Dienst von Dynamics AX 2009 unter Windows Server 2008 ohne weitere Probleme. Unschön ist nur, dass diese Meldung bei jedem Start des AOS erzeugt wird.
Für die Verwendung des Enterprise Portals bzw. des Rolecenters muss beachtet werden, dass wie im Installation Guide von Dynamics AX 2009 beschrieben, die Sharepoint Services 3.0 mit SP1 verwendet werden müssen, da frühere Versionen nicht richtig unter Windows Server 2008 laufen.
Ein weiterer Punkt der unbedingt beachtet werden sollte, sind die Reporting-Erweiterungen von Dynamics AX 2009.
Eine Installation der Reporting-Erweiterungen ist derzeit leider nur möglich, wenn die Reporting Services des SQL Server 2005 in der Service Pack Version 2 verwendet werden.
Sollen die Reporting Services des SQL Server 2008 verwendet werden, scheitert es schon an der Installation der Reporting-Erweiterungen von Dynamics AX 2009.
Diese lassen sich in einer solchen Systemumgebung erst gar nicht installieren. Das Setup wird durch eine entsprechende Fehlermeldung abgebrochen.
Dies hat zur Folge, dass die Reporting Services des SQL Server 2008 nicht mit Dynamics AX 2009 verwendet werden können.
Gleiches gilt für die Analysis Extensions von Dynamics AX 2009 in Kombination mit den Analysis Services des SQL Server 2008.
Diese lassen sich zwar ohne Problem installieren, aber eine Verarbeitung der Cubes ist nicht möglich, da diese auf Grund von Verarbeitungsfehlern abgebrochen wird.
Schlussendlich bedeutet dies, dass die Verwendung von Windows Server 2008 als Betriebssystem für Dynamics AX 2009 keine Probleme bereiten sollte.
Für die reinen Datenbankdienste von SQL Server 2008 trifft dies ebenfalls zu. In meinen Test konnte ich keinerlei Probleme beim Betrieb mit Dynamics AX 2009 erkennen.
Anderes gilt für die Reporting und Analysis Services von SQL Server2008. Deren Verwendung ist leider noch nicht möglich und es müssen weiterhin die Reporting und Analysis Services des SQL Server 2005 verwendet werden um alle möglichen Funktionalitäten von Dynamics AX 2009 zur Verfügung stellen zu können.
Wie bereits im diesem Artikel "Fehlermeldung beim Starten des Microsoft Dynamics AX Clients" beschrieben, kann es zu Fehlermeldungen beim Starten des Dynamixs AX 4.0 Client kommen.
Eine weitere Fehlermeldung, welche erzeugt werden kann ist "Incompatible ext. version".
Es ist auch möglich, dass diese sogar mehrfach ausgegeben wird.
Grund hierfür ist meist ein Problem mit der TAPI-Integartion des CRM Moduls, bzw. genauer gesagt, ein Problem mit den eingestellten Wählregeln/Standorte der Windows Telefon- und Modemoptionen.
Die Behebung des Fehlers ist eigentlich ganz einfach.
- Wenn die TAPI-Integration nicht genutzt wird, kann diese deaktiviert werden.
Wie dies genau geht kann in diesem Artikel "Fehlermeldung beim Starten des Microsoft Dynamics AX Clients" nachgelesen werden.
- Wenn die TAPI-Integration verwendet werden soll, muss ein neuer Standort in den Windows Telefon- und Modemoptionen erstellt werden.
Das Erstellen eines neuen Standorts erfolgt über "Start -> Systemsteuerung -> Telefon- und Modemoptionen" auf dem jeweiligen Clientcomputer (pro Benutzer).
Dort sollte, wenn vorhanden, ein bestehender Standort gelöscht werden und ein neuer angelegt werden.
Manchmal ist es möglich, dass beim Starten des Microsoft Dynamics AX 4.0 Clients eine oder meherer Fehlermeldungen in einem Infolog-Fenster ausgegeben werden.
Diese Fehlermeldung könnten z.B. "Corrupted ini file" sein.
Die große Frage ist nun, woher kommt diese Fehlermeldung bzw. wodurch wird diese erzeugt.
Leider ist die Fehlermeldung, welche im Ereignisprotokoll gefunden werden kann, meist auch nicht besonders hilfreich.
Sollten solche, eher unerklärlichen Fehlermeldungen beim Starten des Dynamics AX Client ausgegeben werden, lohnt sich oft ein Blick in die Systemkonfiguration, welche über Verwaltung, Einstellungen, System, Konfiguration aufgerufen werden kann.
Der Grund für diese Fehlermeldung könnte die aktivierte Telefonieintegration des CRM Moduls sein.
Wird diese deaktiviert, sollte die Fehlermeldung nicht mehr erzeugt werden.
Wenn bei der Entwicklung mit Microsoft Dynamics AX 4.0 die Quellcodeverwaltung mittels Visual SourceSafe 2005 eingeschaltet wurde, besteht die Möglichkeit einzelne Versionen eines Objekts miteinander zu vergleichen.
Hierbei kann es aber bei einer "ungünstigen" Konfiguration des lokal Repository-Verzeichnisses sein, dass bei einem Vergleich von zwei Objektversionen die Fehlermeldung "Fehler: Fortsetzen nicht möglich" ausgegeben wird.
Diese Fehlermeldung wird immer erzeugt, wenn sich das lokale Repository-Verzeichnis und das Verzeichnis, in dem die temporären Internetdateien (Temporary Internet Files) gespeichert werden, nicht auf der gleichen Partition (Datenträger) befinden.
Beispiel:
Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = D:\VSSRepository\Test
-> Die Fehlermeldung wird ausgegeben.
Ordner der Temporary Internet Files = C:\Dokumente und Einstellungen\UserXY\Lokale Einstellungen\Temporary Internet Files
Ordner des lokalen Repositories = C:\VSSRepository\Test
-> Die Fehlermeldung wird nicht ausgegeben und der Versionvergleich funktioniert problemlos.
Dieses Problem wird durch ein Update für Visual SourceSafe 2005 behoben. Es empfiehlt sich, bei Verwendung der Quellcodeverwaltung mit Visual SourceSafe 2005 als VC-System, dieses Update einzuspielen.
Einen ersten Ausblick auf die "neuen" Quellcodeverwaltungsfeatures in Microsoft Dynamics AX 5.0 zeigt der Screencast "Version control in MorphX" auf Channel9.
http://channel9.msdn.com/Showpost.aspx?postid=367024
Ich zitiere:
"This screencast is a preview of the version control system integration options in the next release of MorphX - the IDE of Dynamics AX.
It shows a side-by-side comparison of the integration options with Team Foundation Server, Visual Source Safe, and MorphX VCS.
The latter is a simple, yet powerful alternative without any additional infrastructure requirements. The last half of the screencast gives a demonstration of MorphX VCS."
Durch die neuen Features die MorphX VCS mit sich bringt, sowie die Möglichkeit Visual Studio Team System, oder genauer der Team Foundation Server, (nicht nur) als Quellcodeverwaltung zu verwenden, sollte nun für jeden ein "passendes" Quellcodeverwaltungsystem bereit stehen.
Vielen Dank an dieser Stelle an Michael Fruergaard Pontoppidan (http://blogs.msdn.com/mfp/default.aspx) für diesen und die bisherigen Screencasts über Microsoft Dynamics AX.
Erhält man bei seiner täglich Arbeit die Fehlermeldung „Ein Befehl der Datendefinitionssprache kann nicht für () ausgeführt werden. Die SQL Datenbank hat einen Fehler gemeldet.“ oder auf englisch „cannot excecute a data definition language command on (). The SQL database has issued an error.” stellt sich einem meist eine große Hürde in den Weg, weil aus dieser Fehlermeldung nicht eindeutig zu erkennen ist, wo ein Fehler entstanden ist bzw. wieso der Fehler auftritt.
Durch Zufall bin ich drauf gestoßen, wie man genau diese Fehlermeldung produzieren kann und somit Rückschlüsse auf die Ursache des Fehlers schließen kann.
Das Folgende Vorgehen...
- Erstellen eines EDT’s vom Typ „string“ mit dem Namen „MY_BaseId“.
- Verwenden des EDT’s in einer Tabelle (Name: MY_BaseTable).
- Erzeugen von mehreren Datensätzen in der Tabelle.
- Löschen des EDT’s „MY_BaseId“.
- Erstellen eines EDT’s vom Typ „real“ mit dem Namen „MY_BaseId“ (gleicher Name wie der gelöschte EDT vom Typ „string“ hatte).
- Kompilieren oder synchronisieren der Tabelle „MY_BaseTable“.
...ergibt die genannte Fehlermeldung.
Daraus ist zu schließen, dass der Fehler immer Auftritt, wenn der Typ eines vorhandenen EDT’s den bereits eine oder mehrere Tabellen verwenden, geändert wird.
Ich konnte die Fehlermeldung bzw. den Fehler aber nur reproduzieren, wenn die jeweilige Tabelle ein oder mehrere Datensätze enthielt. War in der Tabelle kein Datensatz vorhanden kam es nicht zu der Fehlermeldung.
Um besagten Fehler oder besagte Fehlermeldung zu beheben müssen entweder alle Datensätze in der Tabelle oder die Tabelle selbst gelöscht werden.
Möchte man die schon gepflegten Daten eines Dynamics AX 3.0 System über exportieren/importieren in ein Dynamics AX 4.0 SP1 System übernehmen, wird bei diesem Vorgang leider eine Fehlermeldung erzeugt, dass ein Importieren in das Dynamics AX 4.0 SP1 System nicht möglich ist, da die Daten aus einem älteren System stammen.
Dies ist soweit auch in Ordnung, da sich Tabellen und Felder von Version 3.x zu Version 4.0 SP1 verändert haben (Namensänderungen, Feldergänzungen, etc.).
Da bei einigen Tabellen aber nur Felder weggenommen wurden, könnte man theoretisch die Daten aus dem „alten“ 3.x System übernehmen. Ein Beispiel hierfür ist der Kontenplan (LedgerTable).
Damit dies funktioniert muss aber eine Änderung an der aus dem Dynamics AX 3.x System exportierten „.def“ Datei vorgenommen werden. Die erste Zeile der „.def“ Datei muss so bearbeitet werden, dass diese wie folgt lautet:
Wenn beim Export als Dateityp „Binär“ gewählt wurde:
"EXPFORMAT VER. 4.01","Binary"
Wenn beim Export als Dateityp „Komma“ gewählt wurde:
"EXPFORMAT VER. 4.01","Comma"
Wurde die „.def“ Datei entsprechend angepasst, kann es zwar sein, dass beim Import Fehlermeldungen über nicht vorhandene Felder erzeugt werden aber der Importvorgang an sich funktioniert nun.
Anzumerken ist nur noch, dass diese Version der „Datenübernahme“ nur für Spezialfälle gewählt werden sollte. Ein Datenupdate, mit den von Microsoft bereitgestellten Tools, sollte vorgezogen werden.
Für Microsoft Dynamics AX 4.0 SP1 stehen auf den Microsoft Webseiten 2 PDF Dokumente zur Verfügen, welche die Hardwareanforungen an eine Systemumgebung mit 100 und 200 Benutzern beschreiben.
http://www.microsoft.com/dynamics/ax/product/hardwaresizing.mspx
Man sollte die dort getätigten Aussagen aber eher als eine Art "grundlegende Richtlinie" verstehen, da die realen Hardwareanforderungen eines einzelnen Dynamics AX System, bedingt durch die spezifischen Anpassungen, in einzelnen Punkten variieren können.
Ab der Version 4.0 von Dynamics AX ist es möglich, an einem AOS, die Neuanmeldung von Benutzern zu sperren.
Um Benutzern die Anmeldung an einem AOS zu untersagen muss der entsprechende AOS auf dem Reiter „Serverinstanzen“ der Maske „Onlinebenutzer“ angewählt werden und der Button „Neue Clients ablehnen“ betätigt werden.
Hierbei wird der AOS in den Status „Belastung“ geschaltet.
Ab diesem Zeitpunkt akzeptiert dieser AOS keine Neuanmeldungen mehr.
Mit dem Button „Neue Clients akzeptieren“ kann dies Rückgängig gemacht werden.
Der AOS wird in den Status „Aktiv“ gesetzt.
Allerdings bringt das Untersagen von Neuanmeldungen in einer Dynamics AX Umgebung mit nur einem AOS auch einige Gefahren mit sich.
Wird der Client bzw. die Benutzersitzung des Benutzers mit administrativer Berechtigung geschlossen, und hat dieser keine weiteren aktiven Sitzungen mit ebenfalls administrativen Berechtigungen geöffnet, so hat sich der Administrator selbst vom System ausgesperrt.
Die Sperrung von Neuanmeldungen kann nun nicht mehr rückgängig gemacht werden.
Es ist dann nur noch möglich, den AOS neu zu starten um sich wieder anmelden zu können, da bei einem Neustart eines AOS dessen Status automatisch wieder auf „Aktiv“ gesetzt wird.
Möchte man nach einem Upgrade von Microsoft Dynamics AX 4.0 auf Microsoft Dynamics AX 4.01 einen neuen Benutzer anlegen erhält man die Fehlermeldung "".
Dies läßt erst einmal auf ein Problem im Quellcode von Microsoft Dynamics AX schließen.
Grund für die Fehlermeldung ist aber kein Fehler im Quellcode, sondern ein fehlerhafter Datensatz in der Tabelle "SysPerimeterNetworkParms". In diesem Datensatz steht im Feld "PNType" ein ungültiger Wert.
Wird dieser Wert auf einen gültigen Wert (None) geändert, können auch wieder neue Benutzer im System angelegt werden.
Folgender Job kann zur Behebung des Problems verwendet werden:
(Verwendung auf eigene Gefahr. Es wird keine Garantie oder Haftung für die Funktion und Richtigkeit des Quellcodes gegeben. )
static void CorrectAxaptaUserImportError(Args _args)
{
SysPerimeterNetworkParams p;
DataArea a;
;
while select a
{
changecompany(a.Id)
{
p = null;
ttsbegin;
while select forupdate p
{
p.PNType = PerimeterNetworkType::None;
p.update();
}
ttscommit;
}
}
}
Im Microsoft PartnerSource ist ein Dokument erhältlich, welchen den Updateprozess beschreibt, der durchzuführen ist, wenn man ein Update von Microsoft Dynamics AX 4.0 auf Microsoft Dynamics AX 4.01 durchführen möchte. Alles in allem ist dieses Dokument eine sehr gute Informationsquelle, die fast alle Einzelheiten, die bei dem Update zu beachten sind, erläutert. Bedauerlich ist nur, dass eine sehr wichtige "Kleinigkeit" nicht in diesem Dokument erwähnt wird. Hält man sich strickt an die Dokumentation, so wird man leider feststellen, dass sich der AOS nach der Installation von Microsoft Dynamics AX 4.01 nicht mehr starten lässt. Es wird zwar ein Eintrag im EventLog erzeugt, dieser ist aber nicht besondern hilfreich (Error 110). Grund für diese Fehlermeldung sind die beiden StoredProzedures die ab Microsoft Dynamics AX Version 4.0 in jeder Microsoft Dynamics AX Datenbank vorhanden sein müssen. Da die Datenbank an sich nicht "geupdatet" wird, werden diese SP`s ebenfalls nicht geändert und bleiben damit auf dem Stand von Microsoft Dynamics AX 4.0. Und leider scheint Microsoft Dynamics AX 4.01 genau mit diesen SP`s nicht zusammen arbeiten zu können. Die Lösung des Problems gestaltet sich zum Glück recht einfach: Die SP's müssen einfach nur gegen die beiden SP's einer Microsoft Dynamics AX 4.01 Datenbank ausgetauscht werden und schon funktioniert der AOS wie erwartet.
Ein weiteres Problem beim Update auf die neue Version Microsoft Dynamics AX 4.0 kann der Name des Unternehmenskontos sein. Wird ein Unternehmenskonto verwendet, dass in seinem Namen ein „&“ enthält, z.B. „A&B“, werden einige Prozesse beim „Datenaktualisierung nachsynchronisieren“ mit einem Fehler abgebrochen. Im Ereignislog ist dann ein Eintrag des Dynamics AX 4.0 Servers zu finden, der wie folgt lautet (Ausschnitt): „…[Microsoft][ODBC SQL Server Driver][SQL Server]Falsche Syntax in der Nähe von '&'.. The SQL statement was…“ Daraus wird ersichtlich, das dass „&“ Zeichen als SQL Statement erkannt wird und die SQL Anweisung so fehlerhaft interpretiert wird. Dieses Problem kann nur gelöst werden, indem man in dem zu updatenden Microsoft Dynamics AX 3.0 ein neues Unternehmenskonto erstellt das kein „&“ Zeichen beinhaltet (Am einfachsten geht dies mit der Dublizierfunktion der Unternehmenskonten).
Für die Planung und Durchführung eines Updates stehen folgende Informationsquellen zur Verfügung:
- Microsoft Dynamics AX Upgrade Tools Guide (PDF Dokument, Erhältlich im PartnerSource)
- Microsoft Dynamics AX 4.0 Implementation Guide (CHM File, Dynamics AX 4.0 Dokumentation)
- Inside Microsoft Dynamics AX 4.0 (Buch, Microsoft Press)
Diese enthalten eine gute Beschreibung der einzelnen Schritte die erforderlich sind, um von der Version 3.0 auf die Version 4.0 von Microsoft Dynamics AX zu updaten.
Allerdings können noch einige Probleme bei dem Updateprozess entstehen, die leider nicht Besprochen werden und für die auch in den bekannten Newsgroup, Blogs und Communitys noch keine Lösungsvorschläge gibt.
So sollte ein Upgrade immer in dem Layer durchgeführt werden, in dem die Anpassungen durchgeführt wurden (z.B. CUS oder VAR). Dies hat zur Folge das man u.U. die Anwendung mehrfach kompilieren muss, da man erst nach dem einlesen der Lizenzdatei zugriff auf diese Layer erhält.
Weiterhin kann man beim Durchführen der Synchronisierung folgenden Fehler erhalten:
"Cannot execute a data definition language command on (). The SQL database has issued an error."
Ursache hierfür kann sein, dass der ConfigurationKey "CSESpain" ist in dem Microsoft Dynamics AX 3.0 System, welches geupdatet werden soll, nicht angeschaltet ist/war.
Dadurch sind drei Felder ("Action", "CustVendParameter", "CustVendAccount") der Tabelle "SalesPurchaseCycle" deaktiviert, die allerdings den eindeutigen Index "SalesPurchaseCycle" bilden. Dadurch werden Datensätze in die Tabelle geschrieben, die nicht dem eindeutigen Index entsprechen. Beim Update auf Microsoft Dynamics AX 4.0 wird dieser Index überprüft bzw. neu geschrieben und das Synchronisieren wird mit einem Fehler abgebrochen, da die Datensätze der Tabelle nicht eindeutig sind.
Das Problem kann gelöst werden, indem man auf der Tabelle "SalesPurchaseCycle" den eindeutigen Index "SalesPurchaseCycleIdx" auf "Enabled = NO" setzt.
Anschließend sollten alle Datensätze in dieser Tabelle in allen Unternehmen gelöscht werden und der Index "SalesPurchaseCycleIdx" wieder auf "Enabled = YES" gesetzt werden.
Die Deaktivierung des ConfigurationKey "CSESpain" reicht leider nicht aus, da es dann zu Problemen beim "Datenaktualiserung nachsynchronisieren" kommen kann, da dort die einzelnen Datensätze überprüft werden (5 Prozesse werden deswegen mit einem Fehler beendet).
Weiterhin sei noch angemerkt, dass alle Anpassungen in Bereich der "Forms" zu erheblichen Problemen beim Codeupgrade führen können.
Viele Formelemente wurden in der neuen Version 4.0 unbenannt, was dazu führen kann, dass eine einzige Anpassung (z.B. Änderung nur einer Formproperty) mehrere hundert Fehler erzeugen kann.
Bsp.: Änderung einer Property der Form "CompanyInfo" im upzudatenden Microsoft Dynamics AX 3.0 System führte zu 126 Fehlern im Microsoft Dynamics AX 4.0 System.
Deswegen sollte man vor einem Update genauestens überlegen/überprüfen, ob es überhaupt Sinn macht die getätigten Anpassungen mit zur neuen Version (4.0) zu migrieren.
Oft können getätigte Anpassungen durch Erweiterungen im Standard abgelöst werden, die eine ähnliche Funktionalität bieten. In machen Fällen ist es unter Berücksichtigung der benötigten Zeit sogar Sinnvoller, die Anpassung erneut im Microsoft Dynamics AX 4.0 System vorzunehmen.
Eine Migration der Anpassungen sollte nur in Erwägung gezogen werden, wenn keine andere Lösung gefunden werden kann.
Wer auf der Suche nach Dokumentation zu / über Dynamics Ax 4.0 ist, sollte mal einen Blick auf diese Seite werfen:
Using Microsoft Dynamics AX
Um den Text, der in der Titelleiste des Dynamics AX Clients angezeigt wird, zu ändern muss man folgendes machen:
- Auf dem Clientrechner in das Axapta Client Installationsverzeichnis wechseln.
- Im Unterverzeichnis "Client\Bin" die Datei "Axsys$$.KTD" mit einem Texteditor öffnen.
($$ steht hierbei für das entsprechde Länderkürzel. Z.B. de)
- Das Label "#1076" wie gewünscht anpassen.
Nach einem (Neu)Start des Dynamics AX Clients wird nun der in dem Label eingetragene Text in der Titelleiste des Dynamics AX Clients angezeigt.
Um auf einen Dynamics Ax Object Server, der durch eine Firewall gesichert ist, zugreifen zu können müssen in der Firewall folgende Regeln vorhanden sein.
1. Allow all incoming TCP traffic on AOS Port to AOS IP.
2. Allow all outgoing TCP traffic.
3. Allow all incoming UDP traffic on Port 2712 to AOS IP.*
4. Allow all outgoing UDP traffic.*
Weiterhin muss die Firewall UDP NAT unterstützen.*
Möchte man weiterhin noch eine lokale Firewall auf den jeweiligen Clients betrieben sollte diese wie folgt Konfiguriert sein.
1. Allow all outgoing TCP traffic on AOS Port to AOS IP.
2. Allow all incoming TCP traffic for Dynamics Ax Client (ax32.exe).
3. Allow all outgoing UDP traffic on Port 2712 to AOS IP.*
4. Allow all incoming UDP traffic for Dynamics AX Client (ax32.exe).*
* Sollte die verwendete Firewall kein UDP NAT untestützen bzw. sollten die entsprechenden UDP Regeln nicht eingepflegt werden können, besteht noch die Möglichkeit, dass man dem Dynamics Ax Client mittels -aos=host:port direkt einem AOS zuweißt.
Damit versendet der Dynamics AX Client keine Broadcast mehr über UDP, um die im Netz befindlichen Dynamics AX Object Server zu ermitteln, sondern Verbindet sich direkt mit dem über "host:port" angegebenen AOS. Allerdings gibt es hierbei die Einschränkung, dass keine AOS Cluster verwendet werden können, da der Client sich immer auf den angegebenen AOS verbindet.
Dynamics Ax erlaubt das mehrmalige Anmelden unter einer Benutzerkennung.
So kann ein Benutzer eine beliebige Anzahl an Sitzungen mit seiner Benutzerkennung öffnen.
Möchte man aber die mögliche Anzahl an Sitzungen unter einer Benutzerkennung begrenzen, ist dafür
eine Anpassung der Info Klasse notwendig.
Fred Shen beschreibt in seinem Blog, wie diese Anpassung auszusehen hat.
|