Dynamics 365 Business Central 2022 Welle 2: Das Böse des neuen Feldes verändert das Verhalten

Im Jahr 2001, nach meinem Master-Abschluss in Computer Engineering, trat ich einem neuen Team in meiner damaligen Firma (mit Sitz in Turin) bei, das ein sehr aufregendes Projekt übertragen hatte: die Umstellung einer großen verteilten Anwendung für die Kinoindustrie, die in Visual Basic 6 und geschrieben wurde mit SQL Server als Backend zu einer neuen verteilten Architektur basierend auf .NET 1.0 und Webservices.

Ich erinnere mich, dass wir dieses sehr große Projekt gestartet haben (große Namen der Kinoindustrie waren von diesem neuen Redesign betroffen) und Microsoft direkt um einige Beratungen gebeten haben, wie man am besten mit dem Design der Softwarearchitektur umgeht (wie man am besten die Anwendungsschicht entwirft, Datenschicht, Datenbankzugriff, Webdienstschicht usw.). Ein Jahr später hatte ich das Vergnügen, dieses Team zu leiten und etwa 1,5 Jahre später ging das Projekt in die Go-Live-Phase. Aber das ist eine andere Geschichte.

Aus dieser Zeit erinnere ich mich an die vielen Lektionen, die Redmonds Leute beim Entwerfen einer skalierbaren und mehrschichtigen Windows-Anwendung mit .NET und in Bezug auf die Datenschicht gelernt haben (mein Fokus bei diesem Projekt lag auf dem Design und der Entwicklung des Backends, also der Datenschicht). und die Webdienstschicht) Ich erinnere mich an einige Prinzipien:

  • Erwerben Sie spät und geben Sie früh frei: Halten Sie die Nutzung der gemeinsam genutzten Ressource durch Ihren Ausführungsthread so kurz wie möglich. Erwerben Sie die Verbindung, die Sie für Ihre Daten benötigen, so spät wie möglich in Ihrem Code, und sobald Sie damit fertig sind, geben Sie sie frei.
  • Vermeiden Sie zu viele Roundtrips zum Backend.

Warum schreibe ich diese Dinge in einem Business Central-bezogenen Beitrag?

Gestern fiel mir folgende Folie ins Auge:

Ich muss zugeben, dass ich diesen Aspekt trotz der Tests während der Preview-Schritte von Version 21 völlig verpasst hatte. Feldänderungen werden jetzt beim Verlassen des Feldes in der Datenbank gespeichert? Meine erste Reaktion war: aber dieses Verhalten unterscheidet sich von Version 20 (und davor) und dies kann nicht nur Anwendungen (Erweiterungen), sondern auch Benutzer betreffen!

Warum sage ich das?

Um die Änderungen zu erklären, habe ich auf zwei verschiedene Umgebungen (Version 20.5 und Version 21) eine einfache Erweiterung hochgeladen, die eine Aktion hinzufügt Kundenkarte Seite zum Ausdrucken Gen. Bus. Buchungsgruppe Feldwert:

Das Adatum Corporation Kunde hat die Gen. Bus. Buchungsgruppe mit dem eingestellten Wert als NATIONAL in der IT-Lokalisierung:

Stellen Sie sich nun folgendes Szenario vor: Ein Benutzer der Verwaltungsabteilung von CRONUS (hier Benutzer A genannt) öffnet die Kundenkarte für Kunde 10000 ändert sich die Gen. Bus. Buchungsgruppe Feld auf einen neuen Wert (z EU) und beginnt ein langes Telefonat mit einem Kollegen, ob der UE-Wert stimmt oder nicht.

Wenn während dieser Zeit eine andere Sitzung (Benutzer B) die Gen. Bus. Buchungsgruppe Feld des Kunden 10000, das ist das Verhalten in Version 20.x:

Das Feld wird in der Sitzung von Benutzer A in UE geändert, aber Benutzer B liest beim Lesen des Datensatzes Kunde 10000 den Wert, der an die Datenbank übergeben wird (NATIONAL).

Daten werden an die Datenbank übergeben, wenn der Benutzer die Seite schließt.

Lassen Sie uns nun das gleiche Szenario in einer Umgebung der Version 21 durchführen, in der das neue Verhalten zum Speichern von Arbeit vorhanden ist. Was passiert jetzt? Dies:

Benutzer A ändert das Feld in EU und Benutzer B sieht die Änderungen sofort beim Lesen des gleichen Datensatzes in seiner Sitzung, auch wenn Benutzer A die nicht geschlossen hat Kundenkarte Seite.

Sie können das neue Verhalten auch überprüfen, indem Sie eine erstellen Tischverlängerung Objekt der Kunde Tabelle und Hinzufügen einer Nachricht in der OnAfterModify Auslöser der Tabelle. Sie werden sehen, dass dies für Version 20 ausgelöst wird, wenn die Seite geschlossen wird. in Version 21 wird dies bei jeder Feldänderung ausgelöst.

Gutes oder schlechtes Benehmen?

Ich mag dieses Verhalten ehrlich gesagt nicht. Ich denke, dass dies viele Roundtrips zur Datenbank erzeugt und die Leistung beeinträchtigen kann. Aber trotzdem gibt es zwei weitere wichtige Nebenwirkungen:

  • Dies kann Auswirkungen auf Ihren Erweiterungscode/Ihr Verhalten haben, wenn ein Datensatz geändert wird.
  • Dies wirkt sich auf die Arbeitsweise Ihrer Benutzer aus: Sie müssen die Benutzer darüber informieren, dass jetzt jede Änderung, die sie vornehmen, sofort physisch in der Datenbank gespeichert wird. Und wenn sie falsche Dinge tun (wie anfangen, die Gen. Bus. Buchungsgruppe eines Kunden auf einen falschen Wert und dann ein Telefongespräch mit einem Kollegen beginnen, der denkt, dass diese Änderung vorübergehend und für andere nicht sichtbar ist), liegen sie falsch und können Geschäftsprozesse unterbrechen.

Wenn Sie über ein Änderungsverfolgungssystem verfügen, das Änderungen an Datensätzen überwacht, berücksichtigen Sie dies bitte ebenfalls.

Und was ist, wenn Sie die abonnieren OnAfterModify Auslöser einer Tabelle, um Aktionen in Ihren Erweiterungen auszuführen? Auch das kann Auswirkungen haben.

Dieses Verhalten kann in der On-Premise-Version geändert werden, indem die SaveValueToDatabasePromptly opton auf FALSE in der navsettings.json Datei im Business Central-Webserverordner (C:inetpubwwwrootYOURBCFOLDER), aber für SaaS können Sie sie nicht deaktivieren.

Das SaveValueToDatabasePromptly flag weist den Webserver an, jedes Feld an die Dienstebene zu senden und in der Datenbank zu speichern, wodurch auch alle zugehörigen Ereignisse ausgelöst werden.

Ich hoffe ehrlich, dass die Möglichkeit, dieses Verhalten auch für SaaS zu deaktivieren, in Zukunft verfügbar sein wird, da dies kein optimales Verhalten ist und dies kein Verhalten ist, das viele Kunden wünschen. Öffnen Sie in der Zwischenzeit eine Benachrichtigung dazu.

.

Author: admin

Leave a Reply

Your email address will not be published. Required fields are marked *