Bodo's Dynamics NAV Blog

Dynamics NAV und das Ausdrucken externer Dateien

Fri, 20 Apr 2012 10:07:47 +0200

Durch Zufall bin ich auf msdynamics.de über einen Artikel gestolpert, der die unterschiedlichen Möglichkeiten diskutiert, externe Dateien (z.B. PDFs, Word-Dokumente, Excel-Dokumente) direkt aus Dynamics NAV zu drucken: http://www.msdynamics.de/viewtopic.php?f=14&t=1950.

Seit mit Dynamics NAV 2009 R2 der DotNet-Datentyp eingeführt wurde, können wir diesen Möglichkeiten noch eine weitere Variante hinzufügen: Die direkte Verwendung der .NET Framework Process-Klasse (http://msdn.microsoft.com/en-us/library/ccf1tfx0.aspx) und der ProcessStartInfo-Klasse (http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.aspx).

Mit Process.Start wird die mit der Endung (z.B. .pdf, .docx, .xlsx) der zu druckenden Datei verknüpfte Anwendung gestartet. Das StartInfo.Verb „PrintTo“ sorgt dafür, dass die Datei automatisch auf dem angegebenen Drucker ausgegeben wird. Alternativ können Sie auch „Print“ verwenden. Dann erfolgt die Ausgabe immer auf dem Standarddrucker. Process.WaitForExit wartet maximal die angegebene Dauer in Millisekunden. Bis dahin muss die Anwendung das Dokument an den Drucker übertragen haben. Bei sehr großen Dokumenten müssen Sie eventuell den Timeout-Parameter höher setzen.

Den vollständigen Quellcode können Sie hier herunterladen: Codeunit 50.507 Print Document.txt

Fehlende Icons in der Toolbar der Seitenansicht für die Berichte

Sat, 10 Mar 2012 13:50:54 +0100

Sicherlich sind Ihnen auch schon die beiden unterschiedlichen Varianten der Toolbar in der Seitenansicht für die Berichte des Role Tailored Client von Dynamics NAV 2009 aufgefallen.

Variante 1:

Variante 2:

In der Variante 2 fehlen die Icons für „Drucken“, „Drucklayout“, „Seite einrichten“ und „Speichern unter“.

Ursache? Sobald in der Programmierung des Berichts die Funktion CurrReport.PREVIEW verwendet wird, zeigt der Role Tailored Client die Variante 2 an.

Ach! (Loriot, 1923 – 2011)

Dynamics NAV Web Services und die Reihenfolge der Ereignistrigger

Mon, 13 Feb 2012 21:26:14 +0100

Annahme: Wir haben einen Web Service auf Basis eine Page (Property PageType=List, Editable=Yes) veröffentlicht.

Quizfrage: In welcher Reihenfolge werden beim Aufruf einer Web Service Methode die Ereignistrigger der Page und der zugrundeliegende Datenbanktabelle ausgelöst?

Web Service - Create
Nr.	Objekt	Ereignis	Hinweis
1	Page	OnInit	Falls Sie versuchen sollten, in diesem Ereignistrigger in die Datenbank zu schreiben, bekommen Sie die Fehlermeldung „Sie können keine Änderungen an der Datenbank vornehmen, ehe eine Transaktion gestartet wurde.“
2	Page	OnOpenPage
Impliziter Start der Datenbanktransaktion
3	Page	OnNewRecord
4	Table	<Column Name> - OnValidate	Auf dem Table-Objekte wird das OnValidate-Ereignis der Primärschlüsselspalte ausgelöst.
5	Page	<Column Name> - OnValidate	Auf dem Page-Objekt wird das OnValidate-Ereignis der Primärschlüsselspalte ausgelöst.
6	Page	OnInsertRecord
7	Table	OnInsert
8	Table	<Column Name> - OnValidate	Gem. der Reihenfolge der Spalten auf dem Page-Objekt werden die OnValidate-Ereignisse aller Spalten ausgelöst, deren Werte Sie gesetzt haben. Jeweils zunächst das OnValidate-Ereignis des Table-Objekts und anschließend des Page-Objekts.
9	Page	<Column Name> - OnValidate	Siehe oben.
10	Page	OnModifyRecord
11	Table	OnModify
Implizites COMMIT der Datenbanktransaktion
12	Page	OnAfterGetRecord	Falls Sie versuchen sollten, in diesem Ereignistrigger in die Datenbank zu schreiben, bekommen Sie die Fehlermeldung „Sie können keine Änderungen an der Datenbank vornehmen, ehe eine Transaktion gestartet wurde.“

Web Service - Update
Nr.	Objekt	Trigger	Hinweis
1	Page	OnInit	Falls Sie versuchen sollten, in diesem Ereignistrigger in die Datenbank zu schreiben, bekommen Sie die Fehlermeldung „Sie können keine Änderungen an der Datenbank vornehmen, ehe eine Transaktion gestartet wurde.“
2	Page	OnOpenPage
Impliziter Start der Datenbanktransaktion
3	Page	OnAfterGetRecord	Falls Sie versuchen sollten, in diesem Ereignistrigger in die Datenbank zu schreiben, bekommen Sie die Fehlermeldung „Sie können keine Änderungen an der Datenbank vornehmen, ehe eine Transaktion gestartet wurde.“
4	Table	<Column Name> - OnValidate	Gem. der Reihenfolge der Spalten auf dem Page-Objekt werden die OnValidate-Ereignisse aller Spalten ausgelöst, deren Werte Sie geändert haben. Jeweils zunächst das OnValidate-Ereignis des Table-Objekts und anschließend des Page-Objekts.
5	Page	<Column Name> - OnValidate	Siehe oben.
6	Page	OnModifyRecord
7	Table	OnModify
Implizites COMMIT der Datenbanktransaktion
8	Page	OnAfterGetRecord	Falls Sie versuchen sollten, in diesem Ereignistrigger in die Datenbank zu schreiben, bekommen Sie die Fehlermeldung „Sie können keine Änderungen an der Datenbank vornehmen, ehe eine Transaktion gestartet wurde.“

Web Service - Delete
Nr.	Objekt	Trigger	Hinweis
1	Page	OnInit	Falls Sie versuchen sollten, in diesem Ereignistrigger in die Datenbank zu schreiben, bekommen Sie die Fehlermeldung „Sie können keine Änderungen an der Datenbank vornehmen, ehe eine Transaktion gestartet wurde.“
2	Page	OnOpenPage
Impliziter Start der Datenbanktransaktion
3	Page	OnAfterGetRecord	Falls Sie versuchen sollten, in diesem Ereignistrigger in die Datenbank zu schreiben, bekommen Sie die Fehlermeldung „Sie können keine Änderungen an der Datenbank vornehmen, ehe eine Transaktion gestartet wurde.“
4	Page	OnDeleteRecord
5	Table	OnDelete
Implizites COMMIT der Datenbanktransaktion

Schlussbemerkung: Der Test basiert auf der Version 2009 R2, Build 32441.

Bemerkenswert ist

dass im Fall der Create()-Methode eine Kombination aus Rec.INSERT() und Rec.MODIFY() durchlaufen wird und
dass in keinem Fall das OnClosePage-Ereignis ausgelöst wird.

Der Unterschied zwischen den Sicherheitsmodellen Standard und Enhanced

Fri, 13 Jan 2012 13:49:47 +0100

In meinen Schulungen für angehende Dynamics NAV Entwickler wird regelmäßig die Frage gestellt, worin der Unterschied zwischen den Sicherheitsmodellen Standard und Enhanced der Datenbank besteht. Antwort:

Zunächst grundsätzliches. Der NAV Client nutzt für den Zugriff auf die SQL Server Datenbank das Konzept der Anwendungsrollen (siehe dazu http://msdn.microsoft.com/de-de/library/ms190998.aspx). Die in NAV eingerichteten Datenbank- und Windows-Anmeldungen haben keine Berechtigungen für die Datenbanktabellen, sondern tragen lediglich die SQL Server Rolle Public. D.h. nach erfolgreicher Anmeldung des NAV Clients über einen Datenbank- bzw. Windows-Benutzer, erfolgt der Zugriff auf die Datenbanktabellen über die Anwendungsrolle. Das Kennwort der Anwendungsrolle kennt nur der NAV Client, so dass die Anwendungsrolle nicht von anderen Anwendungen genutzt werden kann. Gleichzeitig können die Benutzer mit ihrer Benutzerkennung über ein externes Tool nicht auf die NAV Tabellen zugreifen.

Die Anwendungsrollen finden wir im SQL Server Management Studio unter Datenbanken -> [Name der Datenbank] -> Sicherheit -> Rollen -> Anwendungsrollen.

Und nun zum Unterschied zwischen den Sicherheitsmodellen Standard und Enhanced. Wenn wir Standard einstellen, gibt es genau eine einzige Anwendungsrolle und diese wird von allen Benutzern verwendet. Wenn wir Enhanced einstellen, verwendet jeder Benutzer eine eigene Anwendungsrolle.

Das bedeutet für das Sicherheitsmodell Standard:

Die eine Anwendungsrolle hat die Berechtigungen zum Lesen, Einfügen, Ändern und Löschen von Datensätzen für alle Datenbanktabellen.
Die tatsächlichen Berechtigungen eines Benutzers gemäß seiner NAV Rollen werden vom NAV Client geprüft.
Wenn wir eine neue Datenbanktabelle anlegen, wird diese automatisch der Anwendungsrolle hinzugefügt. Das gilt sowohl für das Anlegen über den Table Designer als auch bei Importieren von Tabellen über das Import Worksheet (.fob und .txt).
Synchronisieren (Extras -> Zugriffsrechte -> Synchronisieren im NAV Client) löscht die Anwendungsrolle und baut diese neu auf.
Wir können unsere Active Directory Gruppen als Windows-Anmeldungen verwenden.

Das bedeutet für das Sicherheitsmodell Enhanced:

Jede Anwendungsrolle bildet genau die Berechtigungen eines Benutzers gemäß der Zugriffsrechte seiner NAV Rollen ab.
Die Prüfung der Berechtigungen kann daher vom SQL Server übernommen werden und muss nicht durch den NAV Client erfolgen.
Wenn wir eine neue Datenbanktabelle anlegen, wird diese nicht automatisch den Anwendungsrollen hinzugefügt. D.h., wir müssen anschließend alle Benutzerkennungen synchronisieren. Damit werden alle Anwendungsrollen gelöscht und neu aufgebaut.
Wenn wir die Zugriffsrechte einer NAV Rolle ändern, müssen wir alle Benutzerkennungen synchronisieren, die diese NAV Rolle verwenden.
Wenn wir die NAV Rollenzuordnung einer einzelnen Benutzerkennung ändern, müssen wir diese Benutzerkennung synchronisieren.
Um einzelne Benutzerkennungen zu synchronisieren, können wir „Einfache Anmeldung synchronisieren“ wählen. Dazu die Datenbank- bzw. Windows-Anmeldungen öffnen und die gewünschte Benutzerkennung auswählen.
Wir können nicht mit Active Directory Gruppen arbeiten. Es ist zwingend notwendig, für jede Benutzerkennung eine eigene Windows-Anmeldung zu haben.

Fazit: Der administrative Aufwand ist mit dem Sicherheitsmodell Enhanced deutlich höher. Und wir haben gegenüber dem Sicherheitsmodell Standard keine Vorteile, sondern eher Nachteile, da wir auch keine Active Directory Gruppen verwenden können. Ich rate daher jedem zur Verwendung des Sicherheitsmodells Standard. Und bitte daran denken, dass bei einer neuen Datenbank die Standardeinstellung Enhanced und nicht Standard ist…

PS: Es würde mich nicht wundern, wenn Microsoft mit NAV „7“ das Konzept der Anwendungsrollen nicht mehr verwenden wird.

NAV 2009 R2 – Login-Dialog für den Role Tailored Client

Sat, 17 Dec 2011 13:58:57 +0100

Wenn sich mehrere Anwender einen PC-Arbeitsplatz teilen, taucht regelmäßig die Anforderung auf, dass sich jeder Anwender mit seinem eigenen Benutzernamen an Dynamics NAV anmelden soll - und zwar ohne die Anmeldung an Windows zu wechseln.

Mit NAV 2009 R2 hat Microsoft diese Möglichkeit geschaffen. Der neue Parameter „ClientCredentialType“ in der Konfigurationsdatei „ClientUserSettings.config“ kann für diese Zwecke verwendet werden. Ändern Sie einfach den Wert von „Windows“ auf „UserName“:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appSettings>
<add key="Server" value="SPIDERMAN" />
<add key="ServerInstance" value="DynamicsNAV" />
<add key="ServerPort" value="7046" />
<add key="ProtectionLevel" value="EncryptAndSign" />
<add key="UrlHistory" value="" />
<add key="CompressionThreshold" value="64" />
<add key="ChunkSize" value="28" />
<add key="AllowNtlm" value="true" />
<add key="ServicePrincipalNameRequired" value="true" />
<add key="OpenConnectionTimeout" value="00:00:30" />
<add key="ClientCredentialType" value="UserName" />
<add key="DnsIdentity" value="" />
<add key="UnknownSpnHint" value="(net.tcp://spiderman:7046/DynamicsNAV/Service)=Spn;" />
</appSettings>
</configuration>

Die Konfigurationsdatei finden Sie im Verzeichnis „C:\Users\<Benutzername>\AppData\Local\Microsoft\Microsoft Dynamics NAV“ (Hinweis: Das Verzeichnis „AppData“ wird standardmäßig nicht angezeigt. Der Verzeichnisname gilt nur für Windows 7 und Windows Server 2008 R2).

Im Ergebnis bekommen Sie beim Start des Role Tailored Client einen Login-Dialog:

[UPDATE] NAV 2009 – Kritischer Fehler in Berichten für den Role Tailored Client

Thu, 15 Dec 2011 13:54:48 +0100

[Update zu NAV 2009 - Kritischer Fehler in Berichten für den Role Tailored Client]

Microsoft Support hat dieses Verhalten bestätigt. Betroffen ist nicht nur der Datentyp Decimal wie im Artikel beschrieben, sondern auch der Datentyp Date. Die Ursache liegt in der Interpretation der Filterangabe durch den Dynamics NAV Server. Dieser erwartet die Filterangabe im XML Format (siehe dazu die Beschreibung in der Microsoft Dynamics NAV Dokumentation zum Property „Format“). Diese Erwartung kollidiert mit dem eingegebenen Format. Während es bei Date zur Laufzeit zu der Fehlermeldung „Mindestens ein Filter ist ungültig und wird ignoriert“ kommt, wird Decimal falsch interpretiert und der Bericht ohne Fehlermeldung ausgeführt.

Microsoft wird dieses Verhalten nicht ändern, und empfiehlt auf die Verwendung von Date und Decimal Filterkriterien in der Eigenschaft DataItemTableView zu verzichten. Stattdessen soll der Filter im Trigger OnPreDataItem über SETFILTER gesetzt werden.

NAV 2009 – Kritischer Fehler in Berichten für den Role Tailored Client

Sat, 19 Nov 2011 20:41:27 +0100

[Update vom 15. Dezember 2011]

Microsoft Support hat dieses Verhalten bestätigt. Betroffen ist nicht nur der Datentyp Decimal wie unten beschrieben, sondern auch der Datentyp Date. Die Ursache liegt in der Interpretation der Filterangabe durch den Dynamics NAV Server. Dieser erwartet die Filterangabe im XML Format (siehe dazu die Beschreibung in der Microsoft Dynamics NAV Dokumentation zum Property „Format“). Diese Erwartung kollidiert mit dem eingegebenen Format. Während es bei Date zur Laufzeit zu der Fehlermeldung „Mindestens ein Filter ist ungültig und wird ignoriert“ kommt, wird Decimal falsch interpretiert und der Bericht ohne Fehlermeldung ausgeführt.

[Originaltext]

In einem aktuellen Upgrade-Projekt auf Dynamics NAV 2009 R2 sind wir über einen kritischen Fehler in den Berichten für den Role Tailored Client gestolpert.

Falls Sie auf einem Report-DataItem über die Eigenschaft DataItemTableView einen Filter auf eine Spalte vom Typ Decimal legen, wird der Filter nicht korrekt angewendet, wenn es sich bei dem Filterwert um einen Dezimalwert mit Nachkommastellen handelt.

Der Beispielbericht (Download hier) zeigt eine einfache Liste der Sachposten der CRONUS AG. Dabei ist ein Filter aktiv, der nur die Sachposten anzeigt, deren Betrag > 10.000,50 EUR ist.

Wenn Sie die beiden Screenshots unten vergleichen, stellen Sie fest, dass die gelb markierten Posten in der Seitenansicht des Role Tailored Client fehlen.

Die Abbildung oben zeigt das Ergebnis in der Seitenansicht des Dynamics NAV Role Tailored Client.

Die Abbildung oben zeigt das Ergebnis in der Seitenansicht des Dynamis NAV Classic Client.

Wenn Sie den Filter in der DataItemTableView-Eigenschaft auf einen ganzzahligen Wert ändern, z.B. Betrag > 10.000, ist die Berichtsausführung korrekt.

Wir werden das Problem Microsoft melden. Sobald ich Neuigkeiten zu diesem Thema habe, werde ich diese hier berichten.

NAV 2009 – Security Filter, Buchungsdatum und Rec.READPERMISSION

Mon, 24 Oct 2011 12:53:49 +0200

Szenario: Der Betriebsprüfer vom Finanzamt steht vor der Tür. Es soll das Geschäftsjahr 2010 geprüft werden. Ihre Aufgabe ist es, eine Dynamics NAV Rolle für den Betriebsprüfer einzurichten und dabei die Zugriffsrechte auf das Geschäftsjahr 2010 einzuschränken.

Für diese Art von Anforderungen kennt Dynamics NAV das Konzept der Security Filter. Security Filter definieren Sie in den Zugriffsrechten für Table Data-Objekte. Die unten stehende Abbildung zeigt die Definition für die Sachposten mit der Einschränkung des Buchungsdatums auf das Geschäftsjahr 2010. Wir haben für den Betriebsprüfer eine Rolle „FA“ (Finanzamt) angelegt. Die zusätzlichen Berechtigungen für die Table Data-Objekte Währung, Sachkonto und Bemerkungszeile sind notwendig, um den Kontenplan bzw. die Sachkontoarte öffnen zu können.

Zusammen mit der vordefinierten Rolle „ALLE“ des Demomandanten CRONUS AG sind die Berechtigungen ausreichend. Könnte man meinen.

Allerdings kommt es beim Öffnen des Kontenplans zu folgender Fehlermeldung:

Was ist die Ursache? Auf dem Kontenplan haben wir u.a. das Flow Field „Saldo“. Bekanntlich berechnet sich der Saldo aus allen Sachposten des Kontos. Da wir den Zugriff auf die Sachposten über den Security Filter eingeschränkt haben, können nicht mehr alle Sachposten gelesen werden und Dynamics NAV bringt die Fehlermeldung „Sie haben keine Berechtigung zum Lesen der Tabelle Sachposten“.

Und die Lösung? Wir brauchen eine zweite Rolle „FA-INDIREKT“ (Finanzamt – indirekte Rechte), mit der wir indirekte Leserechte auf die Sachposten erteilen, ohne einen Security Filter zu setzen. Damit erlauben wir dem Flow Field sich zu berechnen.

Die neue Rolle weisen wir ebenfalls unserem Benutzer zu.

Jetzt kann der Betriebsprüfer den Kontenplan öffnen. Die Spalte Saldo zeigt zwar per Definition immer den aktuellen Saldo an, wenn Sie allerdings den Drill Down auf die Sachposten machen, werden nur die Bewegungen des Geschäftsjahres 2010 angezeigt.

Diese Lösung lässt sich noch verfeinern: 1) Die Spalte „Saldo bis Datum“ soll immer den Saldo per Ende der Prüfungsperiode anzeigen. 2) Der Betriebsprüfer soll nicht die Möglichkeit haben, durch das Setzen des Flow Filters „Datumsfilter“ in der Spalte „Bewegung“ einen Wert für eine Bewegung außerhalb der Prüfungsperiode anzuzeigen.

Beide Anforderungen lassen sich erfüllen, wenn wir einen Security Filter für Sachkonto definieren und den Datumsfilter auf das Geschäftsjahr 2010 einschränken.

Geschafft. Könnte man meinen. Leider sind Teile des Dynamics NAV Standards nicht für den Einsatz von Security Filtern vorbereitet. So zum Beispiel das Navigate-Formular. Wenn Sie auf einem beliebigen Sachposten stehen und „Navigate“ ausführen, bekommen Sie die folgende Fehlermeldung:

Die Fehlermeldung kann einen wundern. Zumindest der eine Sachposten auf dem wir aktuell stehen, enthält unsere Kombination aus Belegnummer und Buchungsdatum. Ein Blick hinter die Kulissen des Navigate-Formulars verrät das Problem (Funktion „FindRecords“):

...
IF GLEntry.READPERMISSION THEN BEGIN
GLEntry.RESET;
GLEntry.SETCURRENTKEY("Document No.","Posting Date");
GLEntry.SETFILTER("Document No.",DocNoFilter);
GLEntry.SETFILTER("Posting Date",PostingDateFilter);
InsertIntoDocEntry(
DATABASE::"G/L Entry",0,GLEntry.TABLECAPTION,GLEntry.COUNT);
END;
...

Rec.READPERMISSION liefert FALSE zurück, wenn für die Tabelle ein Security Filter definiert ist. In solchen Fällen muss vorher Rec.SETPERMISSIONFILTER aufgerufen werden. Gleichzeitig dürfen wir danach kein Rec.RESET machen, damit der Rec.COUNT auch den Security Filter berücksichtigt und nicht die bekannte Fehlermeldung „Sie haben keine Berechtigung zum Lesen der Tabelle Sachposten“ liefert. Der Programmcode kann also wie folgt umgebaut werden:

// --- 001
GLEntry.RESET;
GLEntry.SETPERMISSIONFILTER;
// +++ 001
IF GLEntry.READPERMISSION THEN BEGIN
// --- 001
// GLEntry.RESET;
// +++ 001
GLEntry.SETCURRENTKEY("Document No.","Posting Date");
GLEntry.SETFILTER("Document No.",DocNoFilter);
GLEntry.SETFILTER("Posting Date",PostingDateFilter);
InsertIntoDocEntry(
DATABASE::"G/L Entry",0,GLEntry.TABLECAPTION,GLEntry.COUNT);
END;

Doch halt. Es geht auch anders. Weiter oben haben wir mit der Rolle „FA-INDIREKT“ indirekte Leserechte für die Sachposten definiert. Diese Berechtigung können wir nutzen, wenn wir dem Navigate-Formular über das Permissions-Property Leserechte auf die Sachposten einräumen:

Beide Varianten führen zum Erfolg.

Epilog. Das hier vorgestellte Konzept müssen Sie selbstverständlich auf Debitoren, Debitorenposten, detaillierte Debitorenposten, Kreditoren, Kreditorenposten, detaillierte Kreditorenposten und nicht zu vergessen, die Mehrwertsteuerposten, übertragen.

NAV 2009 – Funktion FORMAT, Datentyp OPTION und unterschiedliches Verhalten von Classic Client und Role Tailored Client

Mon, 12 Sep 2011 17:03:54 +0200

Der folgende Quellcode erscheint auf den ersten Blick unverdächtig, führt allerdings bei der Ausführung über den NAV Server, d.h. über den Role Tailored Client oder über einen Web Service, zu einer Fehlermeldung:

Kurze Erläuterung des Quellcodes: Wir nehmen eine Variable SalesHeader vom Typ Record der Tabelle 36, setzen den Status auf „Freigegeben“, lesen anschließend diesen Status über die Datentypen RecordRef und FieldRef wieder aus, weisen den Wert der Variable OptionNo vom Typ Integer zu und zeigen das Ergebnis an.

Leider fliegt Ihnen eine Fehlermeldung um die Ohren, wenn Sie diesen Code über den Role Tailored Client (oder über einen Web Service) ausführen:

Wo liegt das Problem? Der Ausdruck „FORMAT(FldRef.VALUE)“ liefert den Wert „Freigegeben“ also den OptionCaption zurück. Darüber kann man sich wundern. Dynamics NAV Versionen vor 2009 und der Classic Client von NAV 2009 liefern für den gleichen Ausdruck den Index der Option zurück. Das können Sie einfach testen, in dem Sie den Quellcode oben über den Classic Client ausführen:

Dieses Problem ist bei Microsoft bekannt und unter der Bug-ID 208030 registriert. Es soll mit einem Hotfix für Dynamics NAV 2009 SP1 bzw. R2 behoben werden. Sobald dieser Hotfix verfügbar ist, werde ich einen entsprechenden Link an dieser Stelle veröffentlichen.

Als Workaround bis zur Veröffentlichung des Hotfix müssen Sie die Zeile „EVALUATE(OptionNo, FORMAT(FldRef.VALUE));“ durch „OptionNo := FldRef.VALUE;“ ersetzen. Die implizite Typumwandlung führt in beiden Welten zum gleichen Ergebnis.

Mein besonderer Dank gilt Tobias. Wenn er mir nicht den Tipp gegeben hätte, das Änderungsprotokoll auszuschalten, würde ich wahrscheinlich heute noch nach dem Fehler suchen. In Codeunit 423 Change Log Management ist mit Dynamics NAV 2009 genau der oben beschriebene Workaround von Microsoft eingebaut worden. Nur leider war unser Quellcode noch auf Basis von Version 4…

NAV 2009 – Quellcode des Transformation Tools veröffentlicht

Fri, 19 Aug 2011 10:48:28 +0200

Microsoft hat bereits am 5. Juli den Quellcode des Transformation Tools veröffentlicht - nur hat es kaum einer bemerkt.

Man sieht es diesem Link http://www.microsoft.com/download/en/details.aspx?id=26681 und der Beschreibung auch wirklich nicht direkt an, aber hinter diesem Download verbirgt sich wirklich der Quellcode.

Anhand des Quellcodes lässt sich das eine oder andere Mysterium des Transformation Tools aufklären.

Ein Beispiel: Aufgrund welcher Information setzt das Transformation Tool das Group-Property „ShowAsTree“ einer Page auf „Yes“?

Die Antwort finden Sie, wenn Sie einen Blick in die Datei „PageControl.cs“ des Projektes „ObjectTransformation“ werfen. Dort finden Sie die folgende Funktion:

private static void SetTreeViewProperties()
{
MetadataDocumentManagement metaDataDocMgt = MetadataDocumentManagement.Instance;
XmlNode expansionControl = metaDataDocMgt.XmlCurrentFormNode.SelectSingleNode(
    @".//a:Group/a:Properties[../a:Control/a:Properties/a:BitmapList = '47,46']",
    metaDataDocMgt.XmlNamespaceMgt);

if (expansionControl != null)
{
    expansionControl.AppendChild(XmlUtility.CreateXmlElement("ShowAsTree", "Yes"));
}

RemoveThisNodeFromParent(metaDataDocMgt.XmlCurrentFormNode.SelectSingleNode(
    @".//a:Group//a:Control[./a:Properties/a:BitmapList = '47,46']",
    metaDataDocMgt.XmlNamespaceMgt));
}

Auch wenn Sie kein Experte für C# oder XPath-Ausdrücke sind, werden Sie feststellen, dass das Setzen der Properties von der BitmapList und den Bitmaps 47 und 46 abhängt. Das Plus-Icon und das Minus-Icon werden zum Aufklappen und Zusammenklappen verwendet. Zur Veranschaulichung, es handelt sich um die folgenden Bitmaps:

In die Falle stolpern Sie dann, wenn Sie eine Transformation einer NAV Installation der Version 4 durchführen. In der Version 4 wurden nämlich noch die Bitmaps 16 und 4 zum Aufklappen und Zusammenklappen verwendet:

Fazit: Ohne die Bitmaps zu ändern, werden Sie das Transformation Tool nicht dazu bewegen, das „ShowAsTree“-Property korrekt zu setzen.

NAV 2009 – Copy & Paste und böse Zeichen in Text- und Code-Feldern

Fri, 12 Aug 2011 09:57:02 +0200

In den Zeiten zunehmender Beliebtheit von Copy & Paste möchte auch ich mich diesem Thema annehmen und auf ein Problem im Zusammenhang mit Dynamics NAV hinweisen.

Machen wir ein Beispiel. Besuchen Sie unser Impressum (http://www.comporsys.de/impressum) und kopieren den Firmennamen „Comporsys Hansa GmbH“ (Namen markieren und dann Strg+C drücken). Danach starten Sie den NAV 2009 Classic Client, legen einen neuen Debitor an und fügen den gerade kopierten Inhalt ein (Strg+V). Das Ergebnis sieht wie folgt aus:

Ich habe in der Abbildung oben extra den Namen markiert, damit das Problem offensichtlich wird. Beim Kopieren sind zwei nicht sichtbare Zeichen mit kopiert worden: Carriage Return (ASCII Code 13) und Line Feed (ASCII Code 10). Böse Zeichen.

Wenn Sie diesen Zeichen nicht entfernen, haben Sie den Salat, sobald Sie zum Beispiel die Daten als Textdatei exportieren. Dann haben Sie unerwartete Zeilenumbrüche in der Textdatei. Das führt unter anderem beim GDPdU-Export zu Programmfehlern, die sehr schwer zu lokalisieren sind.

Wie sieht die Lösung aus?

In Codeunit 1 finden Sie eine Funktion „MakeText“. Diese Funktion wird vom NAV Client aufgerufen, wenn Sie Zeichen in einem Text-Feld eingeben. Und hier ist die richtige Stelle einzugreifen, um die bösen Zeichen aus dem Text zu entfernen. Dazu rufen wir unsere eigene Funktion „RemoveBadChars“ auf. Siehe unten.

Der Quellcode der Funktion „RemoveBadChars“ sieht wie folgt aus. Neben den bereits genannten Zeichen Carriage Return und Line Feed entfernen wir auch noch das Tabulator-Zeichen.

PROCEDURE RemoveBadChars@1000000001(t@1000000000 : Text[250]) : Text[250];
VAR
  Ch@1000000001 : Text[3];
BEGIN
    Ch[1] := 9;   // TAB
    Ch[2] := 10; // LF
    Ch[3] := 13; // CR
    EXIT(DELCHR(t, '=', Ch));
END;

Und wie sieht die Lösung für Code-Felder aus? Eine Funktion „MakeCode“ gibt es in Codeunit 1 nicht. Sie können diese aber mit der ID 109 erstellen. Diese Funktion wird der NAV Client dann aufrufen.

PROCEDURE MakeCode@109(VAR CodeText@1000000000 : Text[250]) : Integer;
BEGIN
CodeText := RemoveBadChars(CodeText);
EXIT(0);
END;

PS: Der NAV 2009 Role Tailored Client kennt das Problem der bösen Zeichen nicht.

NAV 2009 – Unerwartetes Verhalten von Codeunit.RUN

Mon, 18 Jul 2011 12:21:20 +0200

Heute schreibt mein lieber Kollege Christian: In der Microsoft Dynamics NAV Dokumentation (C/SIDE Reference Guide) können Sie über die Funktion Codeunit.RUN nachlesen:

[Ok :=] Codeunit.RUN(Number[, Record])

“…If you include the return value and an error occurs, the calling C/AL code continues to run. This means that you must handle any errors.”

Das ist leider nur die halbe Wahrheit. Ein durch Rec.INSERT ausgelöster Fehler, bricht die Verarbeitung im Gegensatz zur Beschreibung ab und der aufrufende C/AL Code wird nicht weiter ausgeführt. Das können Sie mit dem folgenden Beispielcode nachstellen.

Die Codeunit 50503 „Run Insert Demo Record“ simuliert den Aufruf…

OBJECT Codeunit 50503 Run Insert Demo Record
{
OBJECT-PROPERTIES
{
    Date=12.07.11;
    Time=14:46:29;
    Modified=Yes;
    Version List=BLOG;
}
PROPERTIES
{
   >
            IsOk@1000000000 : Boolean;
          BEGIN
            IsOk := CODEUNIT.RUN(CODEUNIT::"Insert Demo Record");
            IF IsOk THEN BEGIN
              MESSAGE('Ok');
            END ELSE BEGIN
              MESSAGE('Error: %1', GETLASTERRORTEXT);
            END;
          END;

}
CODE
{

    BEGIN
    END.
}
}

…von Codeunit 50502 „Insert Demo Record“, die einen Datensatz einfügt…

OBJECT Codeunit 50502 Insert Demo Record
{
OBJECT-PROPERTIES
{
    Date=12.07.11;
    Time=14:46:37;
    Modified=Yes;
    Version List=BLOG;
}
PROPERTIES
{
   >
            Demo@1000000000 : Record 50500;
          BEGIN
            // ERROR('Hello World!');
            Demo.INIT;
            Demo.INSERT;
          END;

}
CODE
{

    BEGIN
    END.
}
}

…in die Tabelle 50500 „Demo“.

OBJECT Table 50500 Demo
{
OBJECT-PROPERTIES
{
    Date=12.07.11;
    Time=14:39:33;
    Modified=Yes;
    Version List=BLOG;
}
PROPERTIES
{
}
FIELDS
{
    { 1   ;   ;Entry No.           ;Integer        }
}
KEYS
{
    {    ;Entry No.                               ;Clustered=Yes }
}
FIELDGROUPS
{
}
CODE
{

    BEGIN
    END.
}
}

Den Quellcode finden Sie auch hier zum Download.

Wenn Sie die Codeunit 50503 „Run Insert Demo Record“ zweimal aufrufen, erhalten Sie beim zweiten Aufruf die Fehlermeldung, dass der Datensatz bereits existiert. Das sollte einen nicht wundern. Wundern sollte einen, dass die Verarbeitung abgebrochen wird:

Das ist nicht das erwartete Verhalten. Das erwartete Verhalten können Sie simulieren, wenn Sie in der Codeunit 50502 „Insert Demo Record“ die Kommentarzeile mit dem „Hello World!“-Error ein kommentieren. Dann bekommen Sie die folgende Mitteilung:

Weitere Nachforschungen haben folgendes ergeben:

Von diesem Verhalten sind zumindest die Versionen NAV 2009 SP1 und R2 betroffen. Ältere Versionen haben wir nicht getestet.
Es scheint nur ein Problem von Rec.INSERT zu sein. Fehler durch ERROR oder auch Rec.MODIFY oder Rec.DELETE verhalten sich wie erwartet.
Nur der NAV Client für den SQL Server ist betroffen. Der vom Aussterben bedrohte NAV Client „fin.exe“ verhält sich wie erwartet.

NAV 2009 – Notizen und Benachrichtigungen an Active Directory Gruppen

Mon, 11 Jul 2011 20:27:09 +0200

Mit dem NAV 2009 Role Tailored Client hat Microsoft die Notizen erfunden, die man an jeden beliebigen Datensatz hängen kann, und gleichzeitig die Möglichkeit geschaffen, andere Benutzer über die angehängte Notiz zu benachrichtigen.

Dabei werden bei der Auswahl des Benachrichtigungsempfängers die eingerichteten Windows Anmeldungen angezeigt. Sowohl die Active Directory Benutzer (z.B. der Administrator) als auch die Active Directory Gruppen (z.B. das Dynamics NAV Team), wie die folgende Abbildung zeigt:

Unglücklicherweise verschwinden Benachrichtigungen an Active Directory Gruppen im Nirwana und werden nicht den Gruppenmitgliedern zugestellt.

Diese Einschränkung wollte ich durch eine kleine Umbaumaßnahme beseitigen und bin dabei zunächst auf ein anderes Problem gestoßen, dass ich in meinem letzten Artikel dokumentiert habe: NAV 2009 – Interner Fehler 12 in Modul 40. Mit Hilfe der dort entwickelten .NET Assembly ist der Rest allerdings ein Kinderspiel.

Die Notizen werden in der Tabelle 2000000068 Record Link gespeichert. Wir müssen daher nur das OnInsert-Ereignis dieser Tabelle so erweitern, dass Record Links für alle Mitglieder der gewählten Active Directory Gruppe generiert werden.

OnInsert-Trigger
RecordLink    Record Record Link
Search        DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.Search
List          DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.WindowsGroupMemberList
Member        DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.WindowsGroupMember
WinObj        DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.WindowsObject
i             Integer

// --- 001
IF NOT Notify THEN BEGIN
EXIT;
END;

Search := Search.Search('comporsys-hansa'); // ToDo: Servername sollte konfigurierbar sein
WinObj := Search.FindUserOrGroup("To User ID");
IF WinObj.Type = 'user' THEN BEGIN
EXIT;
END;

List := Search.FindGroupMember("To User ID");
FOR i := 0 TO List.Count - 1 DO BEGIN
Member := List.Item(i);
CLEAR(RecordLink);
RecordLink.COPY(Rec);
RecordLink."To User ID" := Member.MemberId;
RecordLink.INSERT;
END;
// +++ 001

Hierzu nur noch folgende Anmerkungen:

1) Der Primärschlüssel „Link ID“ der Tabelle Record Link ist auf „AutoIncrement“ gesetzt und muss bzw. darf daher nicht manuell gesetzt werden.
2) Die Methode COPY() des Record-Datentyps kopiert auch den Inhalt der BLOB-Spalte „Note“ um.

OnInsert-Trigger

RecordLink Record Record Link

Search DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.Search

List DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.WindowsGroupMemberList

Member DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.WindowsGroupMember

WinObj DotNet 'Comporsys.LdapSearch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdf4f6702c4e909e'.Comporsys.LdapSearch.WindowsObject

i Integer

// --- 001

IF NOT Notify THEN BEGIN

EXIT;

END;

Search := Search.Search('comporsys-hansa'); // ToDo: Servername sollte konfigurierbar sein

WinObj := Search.FindUserOrGroup("To User ID");

IF WinObj.Type = 'user' THEN BEGIN

EXIT;

END;

List := Search.FindGroupMember("To User ID");

FOR i := 0 TO List.Count - 1 DO BEGIN

Member := List.Item(i);

CLEAR(RecordLink);

RecordLink.COPY(Rec);

RecordLink."To User ID" := Member.MemberId;

RecordLink.INSERT;

END;

// +++ 001

NAV 2009 – Interner Fehler 12 in Modul 40

Sun, 19 Jun 2011 17:54:59 +0200

Am Sonntagvormittag befasste ich mich mit einer doch gefühlt einfachen Aufgabe: Zu ermitteln, welche Benutzer Mitglied einer Active Directory Gruppe sind, kann nicht schwierig sein. Dynamics NAV kennt dafür eine virtuelle Tabelle „Windows Group Member“ (2000000052). Erstellen Sie ein Formular für diese Tabelle und Sie können sich die Mitglieder einer Gruppe anzeigen lassen:

Wenn Sie auf Basis dieser Tabelle eine List-Page für den Role Tailored Client erstellen und diese starten, bekommen Sie die Fehlermeldung „Interner Fehler 12 in Modul 40“:

Das Problem ist gar nicht so sehr die Page, wie weitere Tests gezeigt haben, sondern die Tatsache, dass Sie über den Role Tailored Client zwar ein Rec.FIND (Rec.FINDFIRST, Rec.FINDLAST oder Rec.FINDSET) auf diese Tabelle ausführen können, aber ein Rec.NEXT die Fehlermeldung auslöst. Und der Rec.FIND funktioniert auch nur dann, wenn kein Filter gesetzt ist. Weitere virtuelle Tabellen wie z.B. „Windows Object“ (2000000050) sind ebenfalls von diesem Fehler betroffen.

Eingeleitete Sofortmaßnahmen:

Eine Aktualisierung auf den letzten Hotfix für Dynamics NAV 2009 R2 (Build 32441) hat keine Besserung gebracht.
Sich an den Systemadministrator zu wenden, wie in der Fehlermeldung empfohlen, wird wohl auch keine Hilfe bringen.

Und so langsam dämmert es mir, dass die Lösung der vermeintlich einfachen Aufgabe, die Mitglieder einer Active Directory Gruppe anzuzeigen, wohl doch mehr Zeit als nur den Vormittag in Anspruch nehmen wird.

Wie sieht die Lösung aus? Der Zugriff auf einen Verzeichnisdienst wie Active Directory erfolgt über LDAP (Lightweight Directory Access Protocol). Eine sehr gute Einführung in dieses Thema finden Sie hier: http://www.selfadsi.de. Auf weitere Erläuterungen zu LDAP verzichte ich daher. Die Idee ist also, eine .NET Assembly zu erfinden, die den Zugriff auf das Active Directory über LDAP implementiert und uns die benötigten Daten liefert, um die Tabelle „Windows Group Member“ zu füllen, zumindest temporär. Den ganzen Quellcode möchte ich hier aus Platzgründen nicht abdrucken. Das vollständige Visual Studio 2008 Projekt finden Sie daher hier zum Download.

Bitte denken Sie daran, für die Installation der .NET Assembly die Datei „Comporsys.LdapSearch.dll“ sowohl in das „Add-Ins“ Verzeichnis des Classic Clients als auch des Servers zu kopieren.

Mit den Klassen der .NET Assembly können Sie anschließend die folgende List-Page 50503 aufbauen. Die Funktion „Fill()“ füllt dabei die virtuelle Tabelle „Windows Group Member“, die wir temporär für diese Page verwenden.

Starten Sie die Page und Sie erhalten das gewünschte Ergebnis:

Für die Leser, die sich fragen sollten, wozu ich diese Funktionalität überhaupt benötige: Fortsetzung folgt in meinem nächsten Artikel.

NAV 2009 Form Transformation – Wo sind die deutschen (DEU) Captions hin?

Tue, 24 May 2011 09:21:19 +0200

Sicherlich haben Sie bereits mit dem Form Transformation Tool für Dynamics NAV 2009 gearbeitet, um aus einem Form-Objekt ein Page-Objekt zu generieren. Dabei wird Ihnen aufgefallen sein, dass bei der Umwandlung eines Form-Objektes des Standards, die deutschen (DEU) Captions der Actions in der Action Pane und der Command Bar teilweise flöten gehen. Das Beispiel unten zeigt dieses Problem beispielhaft für die Sachkontokarte (Form ID 17) nach ihrer Transformation:

Woran liegt das? Das Form Transformation Tool von Dynamics NAV 2009 liefert schlicht und ergreifend keine deutschen (DEU) Captions mit. Und damit bekommen alle Actions, die im Rahmen der Transformation zusätzlich einer Karte oder Übersicht hinzugefügt werden, nur englische (ENU) Captions. Schade. Siehe Abbildung unten:

Wenn Sie sich jetzt fragen sollten, wie denn wohl die deutschen (DEU) Captions ihren Weg auf die Page-Objekte gefunden haben (immerhin ist die Demo-Datenbank CRONUS AG ja vollständig übersetzt): Offensichtlich wurden bei der Lokalisierung von Dynamics NAV 2009 die Page-Objekte lokalisiert und nicht die Transformationsregeln des Form Transformation Tools. Sehr schade.

Die Lösung. Eine Stapelverarbeitung holt die Übersetzung nach. Dazu werden die Captions von den Objekten geholt und als zusätzliche CaptionML auf den Page Actions hinterlegt.

Stapelverarbeitung Report 50007 Fill Page Action - CaptionML

Wenn Sie die Stapelverarbeitung ausführen, werden die fehlenden deutschen (DEU) Captions eingetragen, wie die Abbildung unten zeigt:

Und nach erneuter Transformation sieht auch unsere Sachkontokarte wieder so aus wie sie aussehen soll:

PS: Vielen Dank an Silas für die Programmierung der Stapelverarbeitung.

NAV 2009 und die Frage, warum die Anzahl der Inforegister PAGE.RUNMODAL beeinflusst

Mon, 18 Apr 2011 21:09:35 +0200

Heute habe ich mich über einen Bug in NAV 2009 R2 geärgert, den ich an dieser Stelle nicht undokumentiert lassen möchte. Der Aufruf einer einfachen Card Page mit PAGE.RUNMODAL hat mich fast an den Rand der Verzweiflung gebracht.

Für das folgende Beispiel habe ich die Tabelle „Country/Region“ genommen und eine schlichte Card Page „Country Card Sample 1“ gebaut:

Wenn Sie diese Page mit PAGE.RUN(PAGE::“Country Card Sample 1“) starten, wird es niemanden überraschen, dass das Ergebnis wie folgt aussieht:

Starten Sie die gleiche Page mit PAGE.RUNMODAL(PAGE::“Country Card Sample 1“) sollte man sich nicht über das automatische Auftauchen der Schaltflächen „Ok“ und „Abbrechen“ wundern. Das ist ja die Idee von „RUNMODAL“. Wundern sollte man sich aber über das Verschwinden des Inforegisters „Allgemein“:

Wohin ist das Inforegister verschwunden? Man weiß es nicht. Nach der Verschwendung von einigen Stunden Lebenszeit kam mir die Idee, ob das Verschwinden nicht etwas mit der Anzahl der Inforegister zu tun hat. Und tatsächlich. Wenn Sie ein zweites Inforegister „Details“ einbauen, bleiben die Inforegister auch bei einem Aufruf mit PAGE.RUNMODAL erhalten. Siehe dazu das zweite Beispiel „Country Card Sample 2“:

Aufruf mit PAGE.RUNMODAL(PAGE::“Country Card Sample 2“). Alles in Ordnung:

Fazit. Es gibt Diebe, die nicht bestraft werden und dem Menschen doch das Kostbarste stehlen: Die Zeit. (Napoleon Bonaparte, 1769 – 1821)

NAV 2009 Web Services und das Geheimnis der Extension Codeunits

Fri, 04 Mar 2011 12:52:29 +0100

Wenn Sie einen Web Service auf Basis einer Page veröffentlichen, bekommen Sie einen Standardsatz an Methoden zum Lesen und Schreiben des „SourceTable“ der Page.

Wenn Sie diesen Standardsatz um eigene Methoden ergänzen wollen, müssen Sie eine so genannte Extension Codeunit implementieren. Dabei gelten die folgenden Regeln:

Eine Extension Codeunit muss unter dem gleichen Servicenamen wie der Page-basierende Web Service in der Liste der Web Services eingetragen werden.
Das Attribut „Veröffentlicht“ muss für die Extension Codeunit nicht gesetzt sein.
Nur Funktionen deren erster Parameter vom Typ des „SourceTable“ des Page-Objektes ist, werden als Web Service Methoden veröffentlicht.

Das folgende Beispiel soll die Verwendung veranschaulichen. Wir veröffentlichen einen Web Service zum Lesen unserer gebuchten Rechnungen. Damit es übersichtlich bleibt, nur mit einer minimalen Anzahl von Feldern.

1. Los geht es mit der Page für den Sales Invoice Header. Beachten Sie bitte, dass ich bei den Namen die Sonderzeichen (Punkte und Leerzeichen) entfernt habe. Das ist nicht zwingend notwendig, da Sonderzeichen automatisch durch Unterstriche ersetzt werden. Mir gefallen nur die Unterstriche nicht.

OBJECT Page 50500 Sales Invoice Service
{
OBJECT-PROPERTIES
{
    Date=05.03.11;
    Time=12:00:00;
    Modified=Yes;
    Version List=;
}
PROPERTIES
{
    Editable=No;
    SourceTable=Table112;
    PageType=List;
}
CONTROLS
{
    { 1000000000;0;Container;
                ContainerType=ContentArea }

    { 1000000001;1;Group ;
                Name=Group;
                GroupType=Repeater }

    { 1000000002;2;Field ;
                Name=No;
                SourceExpr="No." }

    { 1000000003;2;Field ;
                Name=SellToName;
                SourceExpr="Sell-to Customer Name" }

}
CODE
{

    BEGIN
    END.
}
}

2. Als nächstes brauchen wir einen XmlPort, um die Sales Invoice Lines liefern zu können. Beachten Sie bitte, dass die Angabe des „DefaultNamespace“ zwingend notwendig ist.

OBJECT XMLport 50500 Sales Invoice Lines
{
OBJECT-PROPERTIES
{
    Date=05.03.11;
    Time=12:00:00;
    Modified=Yes;
    Version List=;
}
PROPERTIES
{
    Format/Evaluate=XML Format/Evaluate;
    DefaultNamespace=urn:microsoft-dynamics-nav/xmlports/SalesInvoiceLines;
    UseDefaultNamespace=Yes;
}
ELEMENTS
{
    { [{230B615F-189A-450A-88CD-444BFF23CD57}]; ;SalesInvoiceLines   ;Element ;Text    ;
                                                  VariableName=SalesInvoiceLines }

    { [{C89F38A1-E7AF-475F-AE8F-8C6E1C96E0AE}];1 ;SalesInvoiceLine    ;Element ;Table   ;
                                                  VariableName=SalesInvoiceLine;
                                                  SourceTable=Table113 }

    { [{D36EF3F5-FA9F-42B0-BD9B-CACB89CC9899}];2 ;DocumentNo          ;Element ;Field   ;
                                                  DataType=Code;
                                                  SourceField=SalesInvoiceLine::Document No. }

    { [{8859EBB5-7732-4F35-B6B3-AA53C464EEB5}];2 ;LineNo              ;Element ;Field   ;
                                                  DataType=Integer;
                                                  SourceField=SalesInvoiceLine::Line No. }
}
EVENTS
{
}
REQUESTPAGE
{
    PROPERTIES
    {
    }
    CONTROLS
    {
    }
}
CODE
{
    BEGIN
    END.
}
}

3. Und nun können wir die Extension Codeunit bauen. Da bei der Veröffentlichung der Funktion „GetLines()“ als Web Service Methode der erste Parameter zum „Key“ wird, habe ich ihn auch so benannt. Auch wenn das für eine Variable vom Typ „Record“ ungewöhnlich klingen mag. Weitere „Record“-Variablen als Parameter sind nicht zulässig. Daher verwenden wir einen XmlPort, um die Rechnungszeilen zu liefern.

OBJECT Codeunit 50500 Sales Invoice Service
{
OBJECT-PROPERTIES
{
    Date=05.03.11;
    Time=12:00:00;
    Modified=Yes;
    Version List=;
}
PROPERTIES
{
   >
          END;
}
CODE
{

    PROCEDURE GetLines@1000000000(Key@1000000000 : Record 112;VAR SalesInvoiceLines@1000000001 : XMLport 50500);
    VAR
      SalesInvoiceLine@1000000002 : Record 113;
    BEGIN
      SalesInvoiceLine.SETRANGE("Document No.", Key."No.");
      SalesInvoiceLines.SETTABLEVIEW(SalesInvoiceLine);
    END;

    BEGIN
    END.
}
}

4. Wir schreiten zur Veröffentlichung.

5. Kontrollieren die Veröffentlichung im Visual Studio 2008.

6. Und schreiben uns ein kleines VisualBasic.NET Programm zum Testen. Die Rechnung „103007“ sollte es in jeder CRONUS AG geben.

Module Application

    Sub Main()

        Dim ws As SalesInvoiceServiceNAV.SalesInvoice_Service = Nothing

        Try
            ws = New SalesInvoiceServiceNAV.SalesInvoice_Service
            ws.UseDefaultCredentials = True
            ws.Url = "http://spiderman:7047/DynamicsNAV/WS/CRONUS AG/Page/SalesInvoice"

            Dim invoice As SalesInvoiceServiceNAV.SalesInvoice
            invoice = ws.Read("103007")

            If Not invoice Is Nothing Then

                Console.WriteLine("Rechnung " & invoice.No & " an " & invoice.SellToName)

                Dim lines As New SalesInvoiceServiceNAV.SalesInvoiceLines
                ws.GetLines(invoice.Key, lines)

                For i As Integer = 0 To lines.SalesInvoiceLine.Length - 1
                    Dim line As SalesInvoiceServiceNAV.SalesInvoiceLine
                    line = lines.SalesInvoiceLine(i)
                    Console.WriteLine("Rechnung " & line.DocumentNo & " Zeile " & line.LineNo)
                Next

            End If

        Catch ex As Exception
            Throw
        Finally
            If Not ws Is Nothing Then
                ws.Dispose()
            End If
        End Try

        Console.ReadKey()

    End Sub

End Module

7. Ich habe fertig.

Der NAV-Client zeigt in der Übersicht der aktiven Sessions nur die eigene Session an

Fri, 11 Feb 2011 11:41:26 +0100

Kennen Sie in Microsoft Dynamics NAV 2009 SP1 und NAV 2009 R2 das Phänomen, dass die Datenbankinformationen als aktive Sessions nur die eigene Session anzeigen und nicht mehr alle Sessions wie in früheren Versionen?

Damit alle Benutzer und nicht nur Benutzer mit der Systemrolle „sysadmin“ alle aktiven Sessions sehen, muss das Traceflag 4616 für den SQL Server gesetzt sein. Während NAV 2009 (ohne Servicepack) und ältere Versionen beim Start des NAV-Clients noch eine Fehlermeldung ausgeben, wenn das Traceflag nicht gesetzt ist, erscheint bei den Versionen NAV 2009 SP1 und NAV 2009 R2 keine Fehlermeldung mehr.

Um dieses Verhalten zu verstehen, müssen wir zwei Dinge klären: Erstens, woher kommen die Informationen über die aktiven Sessions? Und zweitens, mit welchen Berechtigungen greift der NAV-Client darauf zu?

Für die Anzeige der aktiven Sessions verwendet der NAV-Client die Sicht [dbo].[Session] in der NAV-Datenbank. Diese Sicht wiederum verwendet die Systemsicht [dbo].[sysprocesses] in der MASTER-Datenbank des SQL Servers, um die aktiven Sessions zu ermitteln.

Für Zugriffe auf den SQL Server verwendet der NAV-Client eine Anwendungsrolle. Wenn Sie das Sicherheitsmodell „Standard“ für Ihre NAV-Datenbank eingestellt haben, lautet der Name der Anwendungsrolle [$ndo$shadow]. Diese wird für alle Benutzer verwendet.

Und damit haben wir auch die Ursache unseres Problems ermittelt. Anwendungsrollen stellen ein potentielles Sicherheitsrisiko dar, da das Kennwort der Anwendungsrolle im NAV-Client steckt und damit theoretisch von cleveren Schurken ausgespäht werden kann. Der Zugriff auf Systemtabellen des SQL Servers ist daher für Anwendungsrollen verboten bzw. eingeschränkt.

Durch das Setzen von Traceflag 4616 machen Sie die Systemtabellen für Anwendungsrollen zugänglich. Siehe dazu die Dokumentation zum SQL Server unter http://msdn.microsoft.com/de-de/library/ms188396.aspx. Wie Sie das Traceflag als Startoption für den SQL Server setzen, können Sie hier nachlesen: http://msdn.microsoft.com/de-de/library/ms190737.aspx.

Der NAV-Client versucht, eine externe Komponente auszuführen

Tue, 11 Jan 2011 14:19:17 +0100

Kennen Sie die in Microsoft Dynamics NAV 2009 R2 neue Warnmeldung „Der NAV-Client versucht, eine externe Komponente auszuführen“?

Offensichtlich hat Microsoft die Option „Zulassen und nicht mehr fragen“ nicht implementiert, so dass diese Warnmeldung jedes Mal aufs Neue erscheint. Ärgerlich. Frage: Warum ist diese Option nicht implementiert? Antwort: Weil diese Option überflüssig ist, wenn sich NAV Client und Dynamics NAV Server nur ausreichend vertrauen.

Mit Microsoft Dynamics NAV 2009 R2 wird einer neuer Datentyp „DotNet“ eingeführt. Mit Hilfe dieses Datentyps haben wir als NAV Entwickler eine elegante Möglichkeit, .NET-Assemblies in die C/AL Programmierung zu integrieren.

Bauen wir ein einfaches Beispiel und lassen uns den Maschinennamen mit Hilfe des Properties „MachineName“ der Klasse „System.Environment“ der Assembly „mscorlib“ anzeigen:

OBJECT Codeunit 50000 System Environment
{
OBJECT-PROPERTIES
{
    Date=11.01.11;
    Time=10:30:00;
    Modified=Yes;
    Version List=;
}
PROPERTIES
{
            SystemEnvironment@1000000000 : DotNet "'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.System.Environment";
            MachineName@1000000001 : Text[30];
          BEGIN
            MachineName := SystemEnvironment.MachineName;
            MESSAGE('MachineName = %1', MachineName);
          END;
}
CODE
{
    BEGIN
    END.
}
}

Welcher Maschinenname wird angezeigt? Richtig! Der Name der Maschine, auf der der Dynamics NAV Server läuft und nicht der Name unseres NAV Clients.

Der Grund ist das Property „RunOnClient“ der DotNet-Variable „SystemEnvironment“. Dieses Property steht standardmäßig auf „No“, so dass die Codeausführung auf dem Dynamics NAV Server und nicht auf dem NAV Client läuft.

Ändern wir dieses Property auf „Yes“, läuft die Codeausführung auf dem NAV Client. Allerdings erst, wenn wir die Warnmeldung oben quittiert haben. Damit kommen wir auf unsere eigentliche Fragestellung zurück, wie wir diese Warnmeldung unterdrücken.

Die Lösung besteht darin, den NAV Client zu einer Kerberos-Authentifizierung anstelle einer NTLM-Authentifizierung gegenüber dem Dynamics NAV Server zu bewegen. Dazu öffnen wir die Konfigurationsdatei „ClientUserSettings.config“ für den NAV Client im Verzeichnis „C:\Users\<Benutzername>\AppData\Local\Microsoft\Microsoft Dynamics NAV“ (Hinweis: Das Verzeichnis „AppData“ wird standardmäßig nicht angezeigt. Der Verzeichnisname gilt nur für Windows 7 und Windows Server 2008 R2). Und ändern den Eintrag für „ServicePrincipalNameRequired“ von „false“ auf „true“. Damit vertrauen sich NAV Client und Dynamics NAV Server und die Warnmeldung wird nicht mehr angezeigt.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appSettings>
<add key="Server" value="SPIDERMAN" />
<add key="ServerInstance" value="DynamicsNAV" />
<add key="ServerPort" value="7046" />
<add key="ProtectionLevel" value="EncryptAndSign" />
<add key="UrlHistory" value="" />
<add key="CompressionThreshold" value="64" />
<add key="ChunkSize" value="28" />
<add key="AllowNtlm" value="true" />
<add key="ServicePrincipalNameRequired" value="true" />
<add key="OpenConnectionTimeout" value="00:00:30" />
<add key="ClientCredentialType" value="Windows" />
<add key="DnsIdentity" value="" />
<add key="UnknownSpnHint" value="(net.tcp://spiderman:7046/DynamicsNAV/Service)=Spn;" />
</appSettings>
</configuration>