Get best of the week

Entwicklung des ersten Projekts auf der Plattform von Microsoft Dynamics 365 For Finance and Operations

Hallo alle zusammen! Mein Name ist Tanya, ich bin der Teamleiter des Axapta-Entwicklungsteams bei Lamoda. In diesem Artikel wird die Entwicklung unseres ersten Projekts auf der Microsoft Dynamics 365 For Finance- und Operations-Plattform erläutert.

Bild

Ich werde über die Ansätze sprechen, die wir verwendet haben, über die Fehler, die gemacht wurden, ich werde mein Wissen teilen und Erfahrungen sammeln. Dieser Artikel kann für diejenigen von Interesse sein, die mit der Entwicklung eines Projekts in D365 beginnen oder nur darüber nachdenken.

Dies ist eine kostenlose Abschrift des Berichts aus dem Mycrosoft Dynamics 365 & Power Platform Meetup-Meeting.

Projektziel und technische Grundlagen


Unsere deutsche Tochtergesellschaft kauft Waren und verkauft sie an eine russische juristische Person. Zuvor verwendeten wir das Tsenit-System, mit dem wir Aufzeichnungen nur auf der Ebene der Finanzdaten führen konnten, die Waren- und Logistikaufgaben jedoch nicht bewältigen konnten. Um diese Probleme zu lösen, hatten wir zusätzliche Tools. Die Daten wurden in mehreren Datenbanken gleichzeitig gespeichert. All dies wirkte sich negativ auf die Geschwindigkeit und Zuverlässigkeit des gesamten Systems aus.

Wir wollten, dass das Buchhaltungssystem der deutschen Niederlassung hilft, Berichte einzureichen, Steuern zu zahlen und Prüfungen zu bestehen. Das vergangene ERP hat diese Probleme kaum gelöst, daher haben wir beschlossen, ein eigenes Buchhaltungssystem zu entwickeln und einzuführen. Unser ERP sollte Finanz-, Buchhaltungs- und Filiallogistik in einem Kreislauf vereinen. Als Hauptsoftware haben wir Microsoft Dynamics 365 gewählt - die frühere Dynamics AX, auch bekannt als Axapta.

Die Geschäftskomponente ist im Artikel „Technologie, Outsourcing und Mentalität“ beschrieben . Hier werden wir über die technische Implementierung sprechen. Wir mussten also mehrere Geschäftsprozesse automatisieren:

  • Kauf von Waren von Lieferanten;
  • Verkauf an eine russische juristische Person;
  • Integration zwischen D365 und Ax2012, dem Rechnungsführungssystem einer russischen juristischen Person;
  • ;
  • .

Im Projekt haben wir uns für die Implementierung der Microsoft Dynamics 365-Cloud-Lösung entschieden, da das deutsche Büro weder über die IT-Infrastruktur für die Bereitstellung der Anwendung noch über die Verantwortlichen verfügte. Für kleine Remote-Niederlassungen ist das SaaS-Schema optimal, da Sie sofort nach Unterzeichnung des Vertrags mit dem Anbieter alle erforderlichen Software- und Entwicklungsumgebungen erhalten, um mit der Implementierung zu beginnen.

Wir hatten enge Fristen: Es war notwendig, die gesamte Entwicklung in 3 Monaten abzuschließen. Da im alten System die Warenbilanzierung in Tabellenkalkulationen durchgeführt wurde, wäre die Übertragung des gesamten Satzes historischer Daten Mitte eines Geschäftsjahres eine unmögliche Aufgabe. Zu Beginn des Berichtszeitraums reicht es jedoch aus, nur Salden zu überweisen. Daher war es notwendig, entweder den 1. Januar 2019 zu starten oder ihn um ein weiteres Jahr zu verschieben.

Unser Team hatte keine Entwicklungserfahrung bei D365. Trotz aller Umstände wollten wir dieses Projekt so schnell wie möglich starten. Als nächstes werde ich alle Entwicklungsstadien separat beschreiben. Ich werde auf jede Iteration im Detail eingehen: Welche Erfahrungen wir gemacht haben und welche Fehler wir gemacht haben.

Erste Iteration, Änderungen an der Anwendungsversion 7.3



BildUm schnell zur Sache zu kommen, haben wir zunächst eine einfache Anwendungsarchitektur entwickelt. Es bestand aus Entwicklungsumgebungen - DevBox 1-Tier-Umgebungen. Alle Komponenten wurden auf einem Server / einer virtuellen Maschine installiert: Application Object Server (AOS), Datenbank, Dynamics 365 Retail und Management Reporter.

Zum Testen haben wir uns für die SAT-Umgebung entschieden - Standard Acceptance Test 2-Tier-Umgebung.

Die 2-Tier-Umgebung ist eine Multi-Box-Umgebung, deren Komponenten in mehreren Cloud-Diensten installiert sind und normalerweise mehr als einen Application Object Server (AOS) enthalten. Tatsächlich ist es so nah wie möglich an einer produktiven Umgebung, daher haben wir uns entschlossen, es zu testen.

Wir haben die ersten Entwicklungsumgebungen in der vorhandenen lokalen Infrastruktur bereitgestellt, aber die Kapazität reichte für die weitere Entwicklung des Projekts nicht aus. Als zwei weitere Entwickler dem Projekt beitraten, haben wir DevBox schnell und elegant für sie in der Cloud bereitgestellt.

Unsere Cloud-Umgebungen wurden über das Lifecycle-Serviceportal verwaltet.

Nachdem die Umgebung fertig war, begann sich das Team zu entwickeln. Wir haben die Entwicklungsumgebung in Visual Studio eingerichtet und sie mit der Versionskontrolle von Azure DevOps verbunden, nachdem wir zuvor einen Zweig zum Herunterladen des Codes erstellt hatten. Als nächstes entwickelten wir einen Ansatz zur Entwicklung und Übertragung von Änderungen in die SAT-Umgebung.

Die D365-Architektur enthält keine Ebenen. Der gesamte Standardcode wurde im Modell festgelegt. Änderungen wurden über das LCS-Portal mit einem Paket, das ein kompiliertes Modell enthielt, in die SAT-Umgebung übertragen.
– , – , .

Zunächst haben wir die einfachste und häufigste Änderung implementiert: Hinzufügen eines neuen Felds zur Standardtabelle, Initialisieren beim Erstellen des Datensatzes und Ausgeben in das Standardformular.

Bild

Selbst in einem so einfachen Projekt gibt es neue Arten von Objekten. Wir haben eine Erweiterung vorgenommen, um der Standardtabelle neue Felder hinzuzufügen. Um das Feld in das Standardformular zu bringen, haben wir einen neuen Objekttyp erstellt - eine Erweiterung für das Formular. Um das Feld zu initialisieren, haben wir eine Klasse erstellt, die Tabellenmethoden erweitert. Er durfte das Feld beim Erstellen des Datensatzes initialisieren.

Bild

Bei einer so einfachen Modifikation haben wir eines der Grundprinzipien von D365 gesehen - keine Änderung, sondern eine Erweiterung von Standardobjekten.

Die nächste Änderung war die Erstellung eines neuen Formulars. Beim Erstellen eines Formulars musste nun dessen Muster angegeben werden.Ein Muster ist ein Muster, das die Entwurfsstruktur eines Formulars vollständig definiert. Bis wir die in der Vorlage festgelegte Struktur vollständig reproduziert haben, wird unser Formular nicht kompiliert. Es ist unmöglich, die Vorlage des fertigen Formulars zu ändern. Daher haben wir uns vor Beginn der Entwicklung im Voraus überlegt, wie unsere Form aussehen würde.

Bild

Bild

Bild

Wir haben auch die Möglichkeit behalten, das Design des Formulars selbst zu verwalten. Wenn wir Muster - Benutzerdefiniert angegeben haben, waren wir voll verantwortlich für das Design des Formulars: Welche Objekte befanden sich darauf und mit welcher Verschachtelung.

Bild

Bild

Bild

Schlussfolgerungen nach der ersten Iteration


1. Ändern Sie den Standard nicht, sondern erweitern Sie ihn nur.

2. Beziehen Sie sich auf das Modell, wenn wir seine Objekte in einem anderen Modell verwenden. Dies ist einer der Unterschiede zwischen D365-Modellen gegenüber früheren Versionen: Ein Objekt ist nur in einem Modell vorhanden.

3. Das Ändern der Eigenschaften von Standardobjekten unterliegt Einschränkungen. Nicht alle Eigenschaften von Standardfeldern können in ihren Erweiterungen von Standardobjekten geändert werden. Die Erweiterung der PurchTable-Tabelle ist beispielsweise das LineDisc-Feld. Wir können die Sichtbarkeit des Felds und der Beschriftung steuern, und Eigenschaften wie obligatorisch und bearbeitbar können nicht geändert werden.

Bild

4. In D365 gibt es keine Jobs, alles wird durch Klassen erledigt.

5. Wir haben die Modelle zu fein geschlagen, und es stellte sich heraus, dass unser Prinzip „eine Modifikation = ein Modell“ nicht funktioniert.

Zweite Iteration und Übergang zu einem Modell


Zu Beginn der zweiten Iteration hatten wir zwei Modelle, die sich aufeinander bezogen. Aus diesem Grund konnten wir diese Änderungen nicht mehr unabhängig voneinander übertragen. Aus diesem Grund haben wir uns entschlossen, in einem neuen Modell zu arbeiten, in das alle vorhandenen Änderungen übertragen werden mussten.
Ein Modell in D365 ist eine Sammlung von Quelldateien, die sich in einem separaten Verzeichnis befinden. Beim Kompilieren werden sie in einer separaten Bibliothek gesammelt, die mit anderen Bibliotheken verknüpft ist.

Beim Zusammenführen mit einem Modell in DevBox mussten daher Dateien von einem Verzeichnis in ein anderes übertragen und alte Verzeichnisse gelöscht werden.

Also haben wir ein neues Modell erstellt, die neueste Version auf jeder DevBox erhalten und dann im Rahmen eines Modells in Entwicklungsumgebungen weitergearbeitet.

Natürlich haben wir bereits einige Modelle zum Testen in der SAT-Umgebung übertragen. Daher war es notwendig, sie zu entfernen und eine neue freizugeben.

Alle Aktualisierungen der SAT-Umgebung wurden mithilfe von Paketen durchgeführt, einschließlich des Entfernens von Modellen. Wir haben ein Paket mit leeren Modellen erstellt, die entfernt werden müssen, und ein Skript mit den Namen dieser Modelle hinzugefügt. Dann haben wir ein Paket mit einem neuen Modell gesammelt und es auf die SAT-Umgebung gerollt. Damit hat SAT ein neues Modell bekommen.

Bei der Kombination der Modelle haben wir festgestellt, dass jeder Entwickler die Erweiterungen von Objekten auf seine eigene Weise benennt. Wir haben uns auf die Regeln für die Benennung von Objekten gemäß der Vorlage geeinigt : PurchTable.LamodaModelFormExtension, PurchTableTypeLamodaModelClass_Extension .

Wir haben uns im Team auch darauf geeinigt, dass wir für ein Standardobjekt nur eine Erweiterung erstellen und Änderungen daran vornehmen.

Ich habe einige interessante Änderungen ausgewählt, die wir zu diesem Zeitpunkt vorgenommen haben. Sie zeigen mögliche Entwicklungsansätze in D365.

Aufgabe 1

Bei der Buchung der Rechnung für den Kundenauftrag musste die Rechnungsnummer durch die Nummer aus dem Auftrag ersetzt werden. Zu diesem Zweck haben wir eine Standardklasse mit der Möglichkeit der Erweiterung definiert, mit der wir diese Änderung durchführen konnten.

Bild

Wir haben die Standardklasse SalesInvoiceJourCreate erweitert. Es gibt Next in seiner Methode getNumAndVoucher () - dies ist unser neues Super, er spricht über das Aufrufen des Standardmethodencodes. Nach dem Aufrufen des Standardcodes haben wir die Rechnungsnummer durch den gewünschten Wert ersetzt.
Dies ist einer unserer Entwicklungsansätze: Verwenden von Erweiterungen und Hinzufügen Ihres eigenen Codes vor oder nach (optional - sowohl vor als auch nach) der Ausführung von Standardcode.

Aufgabe 2

Es war notwendig, die Anzeige der Summen der Bestellung zu ändern: Gruppieren Sie die Summen nach der Rechnungsnummer des Lieferanten aus den Bestellpositionen. In diesem Fall haben wir keinen Platz für Erweiterungen gefunden, ohne die Leistung zu halbieren. Daher haben wir unsere eigene Version der Ergebnisse erstellt, ohne die Standardergebnisse zu berühren.

Bild

Aufgabe 3
Eine weitere interessante Änderung: In den Zeilen des Bestellformulars mussten Felder aus der Liste der Artikel mit Filterfunktion hinzugefügt werden. In früheren Versionen war die Änderung völlig uninteressant und wurde gelöst, indem einfach eine Tabelle als Datenquelle zum Formular hinzugefügt und die beiden Methoden überlappt wurden.

In Version 7.3 konnten wir die Methoden nicht auf eine Standardformulardatenquelle erweitern. Um zu filtern und kein neues Formular dafür zu erstellen, haben wir dem Formular die Ansicht als Datenquelle hinzugefügt.

Die Möglichkeit, Methoden auf Datenquellen zu erweitern, wurde in Version 8.1 von D365 vorgestellt.

Bild

Schlussfolgerungen nach der zweiten Iteration


In dieser Phase haben wir die grundlegenden Änderungen entwickelt, die zum Starten des Projekts erforderlich sind.

  1. Wir haben die Regeln für die Benennung von Erweiterungen eingeführt. Sie haben nicht nur dazu beigetragen, die Namen konsistent und verständlich zu machen, sondern auch die Aktualisierung weiter vereinfacht, da unsere Namen nicht mit den Namen der Standardobjekte aus dem Service Pack übereinstimmten.
  2. Ich war erfreut darüber, wie schnell Querverweise beim Erstellen eines Projekts oder Modells auftreten - es ist in dieser Version sehr bequem organisiert.
  3. Das Aktualisieren von Modellen in verschiedenen Umgebungen erfolgt auf unterschiedliche Weise. Wir waren davon an einem Beispiel für die Zusammenführung von Modellen überzeugt.
  4. Bevor Sie mit der Entwicklung einer neuen Modifikation beginnen, müssen Sie die neueste Version des Modells herunterladen, da die Entwicklung im Rahmen eines Modells erfolgt.
  5. Der Mechanismus der Datenentität zum Laden und Entladen von Daten in Excel beim Aktualisieren von Daten auf dem Produkt erwies sich als sehr praktisch. Unsere Data & Analytics-Abteilung verwendet es jetzt, um Daten von unserem Cloud-basierten D365 abzurufen.

Wir haben die Hauptentwicklung pünktlich gemacht. Go Live kam heraus, das Modell ist in Prod. Und wir standen vor dem Problem, nur getestete Modifikationen innerhalb des Modells freizugeben. Wir wollten auch den Debugging-Prozess beim Testen von Änderungen vereinfachen und die Aktualisierung der Testumgebung beschleunigen.

Wie es jetzt funktioniert


In der letzten Iteration haben wir zwei Umgebungen hinzugefügt: Build und Test. Nachdem alle Umgebungen konfiguriert und überprüft wurden, haben wir das Testen vereinfacht und gelernt, nur getestete Änderungen innerhalb des Modells freizugeben.

Zum Testen haben wir eine einstufige Umgebung bereitgestellt und sie mit dem Entwicklungszweig im Versionskontrollsystem verbunden. Das Update bestand nun darin, die neueste Version des Modells selbst und seiner Baugruppe zu erhalten. In dieser Umgebung haben wir wie in der üblichen DevBox debütiert.

Bild

Build-Pakete für die Veröffentlichung werden jetzt in einer neuen Build-Umgebung ausgeführt. Die getesteten Änderungen wurden durch Änderungssätze (Änderungspakete, die in das Versionskontrollsystem hochgeladen wurden) nach einem Prinzip vom frühesten bis zum letzten in einen neuen Zweig im Versionskontrollsystem übertragen.

Anschließend haben wir das Paket in der SAT-Umgebung bereitgestellt, in der Benutzertests durchgeführt wurden. Anschließend haben wir das Paket auf dem LCS-Portal für die Veröffentlichung auf dem Produkt geplant. Also haben wir den Release-Prozess mithilfe der Build-Umgebung eingerichtet.

Und wir haben beschlossen, nicht die Projekte zu überarbeiten, sondern die Änderungssätze zur Änderung, die in die Versionskontrolle hochgeladen wurden.

Das erste Update der Cloud-Version


Wir haben an der Cloud-Version gearbeitet, daher mussten wir regelmäßig aktualisiert werden. Das erste Update war ein Übergang von Version 7.3 zu Version 8.0. Es dauerte ungefähr zwei Wochen.

Natürlich haben wir die Hauptprobleme für uns selbst geschaffen, aber wir haben auch gewonnen:

  1. Wir haben uns nicht sofort auf die Regeln für die Benennung von Standardobjekten geeinigt. Bei der ersten Aktualisierung stimmten unsere Objektnamen mit den Namen der Objekte im Service Pack überein.
  2. Beim Aktualisieren von Cloud-Umgebungen müssen wir uns unbedingt von AOS-Computern abmelden, da sonst der Aktualisierungsvorgang mit einem angemeldeten Benutzer nicht abgeschlossen werden konnte.
  3. Das Update-Paket für Produkt- und SAT-Umgebungen musste mit dem Modellpaket kombiniert werden.

Die Aktualisierung aller unserer Umgebungen dauert heute etwa drei bis vier Tage und erfolgt ohne Beteiligung von Entwicklern. Wir können sogar eine Veröffentlichung gleichzeitig mit dem Update veröffentlichen. Hauptsache, Build, SAT und Prod haben dieselbe Version.

Der Update-Vorgang besteht aus dem Herunterladen des Update-Pakets auf das lcs-Portal. Die DevBox und der Test werden zuerst aktualisiert, dann wird der Build aktualisiert, die letzten sind SAT und Prod.

Ergebnisse des gesamten ersten Projekts


  • Wir haben Erfahrung beim Aufbau der D365-Anwendungsarchitektur gesammelt.
  • Entwicklung eines neuen Ansatzes zur Codeüberprüfung.
  • Wir haben die Regeln für die Übertragung von Datenbanken an DevBox festgelegt (in D365 ist es wichtig, erste Tests mit DevBox durchzuführen, und jetzt testen wir sogar Entwickler mit DevBox).
  • Schrieb Entwicklungsrichtlinien bei D365.
  • Ich habe gelernt, mich in der Cloud zu entwickeln.

All diese Erfahrungen haben uns geholfen, das Projekt nachdenklicher zu entwickeln. Jetzt kennen wir die Funktionen des Systems, können die Architektur korrekter erstellen oder vielmehr Aufgaben festlegen. Die aufgebauten Prozesse rund um das Projekt machen es einfach genug, Entwickler zu verbinden, die zum ersten Mal unter D365 schreiben.

More articles:


All Articles