Dynamics AX Blog - Dynamics AX 2009 - Seite 19

Wenn man in Dynamics AX versucht die Eigenschaft AllowDuplicates eines Tabellen-Indexes von No auf Yes zu ändern, kann folgende Fehlermeldung auftreten:

Illegal property value

In diesem Fall ist vermutlich der betroffene Index als PrimaryIndex oder ClusteredIndex der Tabelle eingetragen. Eigentlich auch logisch :-)

Man braucht es immer wieder, und genau darum findet Ihr im folgenden eine kurze - und bestimmt auch nicht ganz vollständige - Übersicht, wie dieses RunBaseBatch-Framework benutzt werden kann. Erste Anlaufstelle sollte übrigens in jedem Fall die Klasse Tutorial_RunBaseBatch sein, dort werden die wichtigsten Methoden verwendet und man kann sich so zumindest einen groben Überblick verschaffen, was wie möglich ist.

Um eine stapelverarbeitungsfähige Klasse zu schaffen, ist diese in erster Linie von RunBaseBatch abzuleiten. Dadurch stehen eine Reihe von Methoden zur Verfügung, von welchen ich einige versuche im Folgenden zu erklären.

Manchmal ist es notwendig, in AX externe Programme (zb. per WinApi::shellExecute) aufzurufen und deren Rückmeldung abzuwarten. Mir ist z.B. in letzter Zeit immer wieder der Fall untergekommen, daß ich über ein externes Programm eine Datei erstellen musste, und diese anschließend in AX einlesen bzw. weitervearbeiten musste.

Für diesen Fall habe ich eine ganz simple Logik gebastelt, die eine bestimmte Anzahl Sekunden lang prüft, ob es die benötigte Datei schon gibt und erst dann mit den weiteren Schritten fortfährt.

static void WaitForFileExists(Args _args)
{
    int         startTime;
    int         endTime;
    int         seconds2Wait = 5;
    boolean     fileExists = false;
    fileName    searchFileName = "c:\\temp\\ax.txt";
    ;
 
    startTime   = timeNow();
    endTime     = startTime + seconds2Wait;

    while (!fileExists && timeNow() <= endTime)
    {
        fileExists = WinApi::fileExists(searchFileName);
    }

    // ...continue...
    if(fileExists)
    {
        info(strFmt("File '%1' exists", searchFileName));
    }
    else
    {
        warning(strFmt("File '%1' does not exist and time is up", searchFileName));
    }
}

Container sind ja was feines, und aus diesem Grund verwende ich sie immer wieder gerne beim Programmieren unter Dynamics AX. Durch einen Blog-Beitrag bei SysDictCoder bin ich auf einen kleinen Trick gestossen, der mir in Zukunft etwas Tipp-Arbeit ersparen wird.

Und zwar habe ich bisher Container immer ähnlich wie im folgenden befüllt:

Wesentlich rascher ist die folgende Schreibweise:

SysDictCoder geht in seinem Artikel etwas mehr ins Detail, deshalb meine Empfehlung dort mal vorbeizuschauen.

Diese Woche genoß ich einen eintägigen Ausflug in die neue Welt von Dynamics AX 2009 und lernte einige Aspekte der neuen Version aus technischer Sicht kennen. Anbei eine kurze Liste der für mich herausragensten Neuerungen:

• Teilweise neue bzw. zumindest veränderte Oberfläche, sicherlich etwas gewöhnungsbedürftig
• Grids sind scheinbar standard-mässig nach Excel exportierbar
• Einführung der UTC-Timestamps, womit Zeitzonen-übergreifende Applikationen über einen AOS laufen können
• Der Task-Rekorder ist scheinbar nun fixer Bestandteil von AX, wodurch zumindest rudimentäre Dokumentationen von Abläufen ermöglicht werden
• Das neue Fill-Utility für Massenaktualisierungen
• Erweiterung und Verbesserung im Umgang mit RecordSets
• Erweiterung und Verbesserung im Umgang mit Queries (z.b. Union-Selects)
• Einführung eines neuen, ax-basierenden Versionskontrollsystem namens MorphX VCS
• Cross-Company-Support ermöglicht Formularen und Berichten mandantenübergreifend Daten anzuzeigen
• Stapelverabeitung läuft komplett am AOS und wurde in einigen Belangen verbessert

Diese Liste ist weder vollständig noch wirklich validiert, hoffe in den nächsten Wochen etwas mehr Zeit mit der neuen Version verbringen zu dürfen :-)

In der Auftragserfassung gibt es im Auftragskopf Felder, die, wenn sie aktualisiert werden, entweder vollautomatisch bzw. nach Rückfrage beim Benutzer in den Auftragszeilen ebenfalls aktualisiert werden. Welche Felder das sind kann in den Debitorenparametern, Register Aktualisierungen über die Schaltfläche Auftragspositionen aktualisieren eingesehen werden. Dort kann auch parametriert werden, wie sich Dynamics AX bei der Aktualisierung dieser Felder verhalten soll.

Um nun ein weiteres Feld in diese Logik mitaufzunehmen bedarf es einiger Schritte. Im folgenden demonstriere ich die notwendigen Änderungen anhand des neuen Feldes DevReceiptDateRequested (abgeleitet vom EDT DevSalesReceiptDateRequested):

• Neues Feld in Tabelle Salestable und Salesline anlegen
• Das neue Feld in der Salestable in die Fieldgroup HeaderToLineUpdate integrieren
• In der Klasse SalesTable2LineField die Methode lineUpdateDescription um das neue Feld erweitern (einfach die Logik eines bestehenden Feldes abschreiben)
• In der Klasse SalesLineType die Methode initFromSalesTable um das neue Feld erweitern (einfach die Logik eines bestehenden Feldes abschreiben)
• In der Klasse AxSalesline eine neue Methode wie folgt erstellen

  protected boolean isDevReceiptDateRequestedSet()
  {
       return this.isFieldSet(fieldNum(SalesLine, DevReceiptDateRequested)) ||
              this.AxSalesTable().isFieldModified(fieldNum(SalesTable, DevReceiptDateRequested));
  }

• In der Klasse AxSalesline eine weitere Methode wie folgt erstellen

  public DevSalesReceiptDateRequested DevReceiptDateRequested(DevSalesReceiptDateRequested _DevReceiptDateRequested = dateNull())
  {
     if (!prmisdefault(_DevReceiptDateRequested))
     {
         this.setField(fieldNum(SalesLine, DevReceiptDateRequested), _DevReceiptDateRequested);
     }
   
     return SalesLine.DevReceiptDateRequested;
  }

• In der Klasse AxSalesline eine dritte neue Methode wie folgt erstellen

  protected void setDevReceiptDateRequested()
  {
     if (this.isMethodExecuted(funcName(), fieldNum(SalesLine, DevReceiptDateRequested)))
     {
         return;
     }
     if (this.isDevReceiptDateRequestedSet())
     {
         this.DevReceiptDateRequested(this.AxSalesTable().DevReceiptDateRequested());
     }
  }

• In der Klasse AxSalesLine muss nun die Methode setTableFields um den Aufruf der zuvor angelegten Methode setDevReceiptDateRequested erweitert werden
• In der Klasse AxSalesTable eine neue Methode wie folgt anlegen

  protected void setDevReceiptDateRequested()
  {
      ;
      if (this.isMethodExecuted(funcName(), fieldNum(SalesTable, DevReceiptDateRequested)))
      {
          return;
      }
  }

• In der Klasse AxSalesTable eine weitere Methode wie folgt anlegen

  public DevSalesReceiptDateRequested DevReceiptDateRequested(DevSalesReceiptDateRequested _DevReceiptDateRequested = dateNull())
  {
      ;
      if (!prmisdefault(_DevReceiptDateRequested))
      {
          this.setField(fieldNum(SalesTable, DevReceiptDateRequested), _DevReceiptDateRequested);
      }
  
      return salesTable.DevReceiptDateRequested;
  }

• In der Klasse AxSalesTable muss nun die Methode setTableFields um den Aufruf der zuvor angelegten Methode setDevReceiptDateRequested erweitert werden
• Nun muß noch folgender Code einmalig ausgeführt werden (z.B. per Job) um das neue Feld in die Aktualisierungslogik einzubinden

  SalesTable2LineParameters salesTable2LineParameters;
  ;
  ttsbegin;
  salesTable2LineParameters.clear();
  salesTable2LineParameters.initValue();
  salesTable2LineParameters.fieldId           = fieldNum(SalesTable, DevReceiptDateRequested);
  salesTable2LineParameters.table2LineUpdate  = Table2LineUpdate::Prompt;
  salesTable2LineParameters.insert();
  ttscommit;

Übrigens, die gleiche Logik gibt es natürlich auch einkaufsseitig. Die obige Abfolge und die Codebeispiele wurden unter AX3 entwickelt.

Update vom 28.07.2010: In Dynamics AX 2009 funktioniert die beschriebene Lösung genauso. Lediglich beim auszuführenden Job hat sich der Datentyp des Feldes table2LineUpdate geändert.

Immer wieder besteht die Notwendigkeit, ein Formular über ein anderes zu öffnen und aus diesem heraus Methoden des Aufrufers aufzurufen.

Einfaches Beispiel: Ich öffne aus der Auftragsmaske (Salestable) irgendein anderes Formular (über einen MenuItemButton) und möchte nun beim Schliessen dieses Formulares eine Methode in der Salestable-Maske aufrufen.
Um dies zu realisieren muß ich einfach in der Close-Methode des Subformulars folgenden Code einbinden. myMethod steht dabei für die aufzurufende Methode des Salestable-Formulares.

Achtung: IntelliSense funtioniert in diesem Fall nicht (außer ich möchte eine Methode aufrufen, die im FormRun-Objekt enthalten ist).

if (element.args() && element.args().caller())
{
    if (element.args().caller().name() == formStr(Salestable))
    {
        element.args().caller().myMethod();
    }
}