1.4.1. Änderungen

Änderung am Setzen des Primary Flags von Relationen

Bisher wurde die Primary-Flags der Relationen erst beim Speichern des Datensatzes gesetzt. Nun werden die Flags schon beim Setzen einer Relation gesetzt. Damit ist sichergestellt, das zu Jederzeit eine Relation auch die primäre ist. Dabei ist die Bevorzugung einer Relation ohne Relationskategorie für das isPrmary weggefallen, was unterumständen nun zu unerwünschten primären Relationen führt.

Um bestimmte Relationen als primär zu kennzeichnen, können die entsprechenden Flags bei den AddSource Methoden genutzt werden. Diese stellen nun sicher, das immer nur eine Relation als primär gekennzeichnet wird.

NuGet PortCMIS deinstallieren

Die Business App Nugets benötigen das NuGet PortCMIS nicht und. Es kann deinstalliert werden.

Neuer “Custom” Ordner

Jedes Projekt sollte einen Ordner mit dem Namen “Custom” erhalten. Dieser enthält Installations spezifische Datein, wie dem neuen Theme oder Icons wie den Hintergrund beim Anmelden. Damit dieser Ordner beim Installieren nicht entfernt wird, müssen die CustomSkipRules in den “csproj” Dateien folgendermaßen angepasst werden:

 <Target Name="AddCustomSkipRules">
    <ItemGroup>
      <MsDeploySkipRules Include="CustomSkipFile">
        <ObjectName>filePath</ObjectName>
        <AbsolutePath>/[^\\]+\\Custom</AbsolutePath>
      </MsDeploySkipRules>
      <MsDeploySkipRules Include="CustomSkipFile">
        <ObjectName>dirPath</ObjectName>
        <AbsolutePath>/[^\\]+\\Custom</AbsolutePath>
      </MsDeploySkipRules>
    </ItemGroup>
  </Target>

Theme Beispiel

Die Projektvorlage erhält ein Beispiel für die Theme Datei. Damit in den Installationen der Projekte die Beispielsdatei mit ausgeliefert wird, muss diese eingefügt werden. Dazu unter “Custom/Styles” folgende Datei ablegen.

DevExpress Theme aus der web.config entfernen

Der Eintrag <themes> in der Sektion <devExpress> muss ersatzlos aus der web.config entfernt werden.

<themes enableThemesAssembly="false" styleSheetTheme="" theme="GI" customThemeAssemblies="GI" />

Aktualisierung der NLog-Konfiguration

Die NLog-Konfiguration muss aktualisiert werden, damit unter amderem Sonderzeichen korrekt funktionieren. Diese steht in der Datei web.config und sollte zukünftig so aussehen:

Download

Entfernung von UseForDI Attribute

Das Attribut UseForDI wird nicht mehr benötigt. NInject-Module werden jetzt automatisch gefunden und in der Assembly-Load-Order ausgeführt.

Zeilen der Art

[assembly: UseForDI(AssemblyType.Module)]

müssen entfernt werden. Typischerweise stehen diese in DIInit.cs.

Reduzierung unterstützter Datentypen

Die Anzahl der unterstützen numerischen Datentypen in BA.Core wurde deutlich reduziert. Ab Release 6.0 können die folgenden Datentypen in Datentabellen nicht mehr verwendet werden:

Nicht mehr unterstützter Typ	Ersatztyp
„Einzelnes Zeichen“ (char)	„Text“ mit Länge 1 (string mit [Size(1)])
„Ganze 16-Bit-Zahl mit Vorzeichen“ (short)	„Ganze Zahl“ (int = Int32)
„Ganzzahliger Byte Wert mit Vorzeichen“ (sbyte)	„Ganze Zahl“ (int = Int32)
„Gleitkommazahl mit einfacher Genauigkeit“ (float)	„Gleitkommazahl“ (double)
„Vorzeichenlose 16-Bit Ganzzahl“ (ushort)	„Ganze Zahl“ (int = Int32)
„Vorzeichenlose 32-Bit-Ganzzahl“ (uint)	„Ganze Zahl“ (int = Int32) oder, falls Werte >= 2^31 in der DB, Int64
„Vorzeichenlose 64-Bit-Ganzzahl“ (ulong)	„Ganze 64-Bit-Zahl“ (long = Int64)
„Vorzeichenloser ganzzahliger Byte Wert“ (byte)	„Ganze Zahl“ (int = Int32)

Konfigurierte Tabellenspalten

Bei konfigurierten (Custom_) Datenspalten erfolgt die Migration nach obigem Schema automatisch.

Programmierte Tabllenspalten

Falls einer der obigen Datentypen in programmierten Tabellen verwendet wurde, ist eine Anpassung des Codes erforderlich. Die Datentypen sind im Code bzw. im DevExpress XPO Designer gemäß obiger Tabelle zu ersetzen. Wird einer der nicht mehr unterstützten Typen noch verwendet, kommt beim Anwendungsstart ein Fehler wie:

For given type 'System.Single' there is no mapping to orm field control.

Die Migration der Datenbank auf den neuen Typ übernimmt der Core auch bei programmierten Tabellen automatisch.

Einführung von Auswahlspalten für Einzelwerte

Umbau programmierte Enum-Spalten

Enum-Spalten in (Teil)Datentabellen

• OrmEnumFieldAttribute anpassen
  • Typ umstellen. “Normal” gibt es nicht mehr. Man wählt nun “Multiple”.
  • Wenn man nur einen Enum-Wert haben möchte, ist statt dessen “Single” zu verwenden.
  • Dies wird bei der Migration einer älteren Datenbank automatisch einmalig berücksichtigt, ebenso beim Import von älteren Konfigurationen.
• Alle “_AllValues”-Spalten im allen XPO Datenmodellen entfernen. Der Core legt die automatisch an, wenn er sie braucht.
  Falls irgendwo im Programmcode auf diese Spalten direkt zugegriffen wurde, ist dies spätestens jetzt auf die Enum-Funktionen Add/Set/Remove/GetEnumValue(s) etc. unzustellen.
• Enums streng typisieren (empfohlen). Statt Typ ValueEnum sollten immer der konkrete Typ des Enums wie er auch im OrmEnumFieldAttribute angegeben ist verwendet werden. Das macht Cast-Expressions unnötig und vermeidet Programmierfehler.
  • Der Typ muss dazu vorher im XPO Diagramm explizit als External-Type hinzugefügt werden.
  • Wenn ein Enum streng typisiert ist, kann der Parameter für den Typ im OrmEnumFieldAttribute einfach weggelassen werden. (optional)

!Enum-Spalten in Teiltabellen, die als eindeutiger Schlüssel verwendet werden müssen auf “Single” umgestellt werden.

Enum Common-Fields

Bei programmierten EnumCommonFields Extensions ist der Spaltentyp anzupassen. Der ursprüngliche Typ “Enum” heißt jetzt “MultiEnum”. Wenn eine gemeinsame Spalte gewünscht wird, die nur Einzelwerte aufnehmen kann, dann muss statt dessen “SingleEnum” gewählt werden.
Die Änderung auf “SingleEnum” triggert die Migration der Spalte bei der ersten Inbetriebname einer Datenbank mit Release 6.0.

Kennzeichnung von Formel-Feldern

Haben eigene Steuerelemente Formel Properties müssen diese zukünftig mit dem [CriteriaProperty] gekennzeichnet werden, damit erkannt werden kann, an welchen Stellen sich Criteria-Expression in Konfigurationen befinden, um sie ggf. zu migrieren.

Eigene Enum-Controls

Wenn ein Projekt eigene Enum-Controls programmiert hat, müssen diese ggf. bei der Feldauswahl auf Einzel- oder Mehrfachwert-Spalten eingeschränkt werden. Das geht, indem man CDPOrmFieldsProperties.EnumMultiValue true (nur Mehrfachwerte) oder false (nur Einzelwerte) zuweist. Standardmäßig werden beide Typen akzeptiert.

Enum-Relationen separieren

Die Relationen für Mehrfach-Enumwerte befinden sich jetzt nicht mehr in der Tabelle OrmRelation, sondern in individuellen Tabellen für jede Mehrfach-Enum-Spalte. Alle Enum-API-Funktionen funktionieren wie bisher. Falls der Projektcode Joins auf OrmRelation zum Lesen von Enum-Relationen enthält, sind aber Anpassungen erforderlich. Dabei sollten soweit irgend möglich API-Funktionen verwendet werden, z.B. CriteriaOperatorBuilder.GetEnumMulti. Letztere Funktion gab es schon vorher, allerdings hat sich die Signatur leicht geändert.

OrmEnumValue nicht mehr OrmBABase

Wenn in einem Projekt Queries auf Datenbankwerte der Enums manuell programmiert sind (nicht empfohlen), dann müssen diese möglicherweise angepasst werden, da OrmEnumValue und auch OrmEnumMaster nicht mehr von OrmBABase erben. Daher kann die API-Funktion Api.ORM.GetQuery(session) nicht mehr verwendet werden. Statt dessen muss man die XPO Funktion session.Query() direkt verwenden.

Eigene Enum Migrationen umstellen

Falls Migrationen Enumwerte oder -Klassen entfernen, hängt es vom Zeitpunkt der Migrationsausführung ab, ob sie das neue oder das alte Datenmodell vorfinden.
Es wird empfohlen alle derartigen Migrationen auf SQLHelper.DropEnumValues bzw. SQLHelper.DropEnumClass umzustellen, das sich um alle Varianten kümmert.

Änderungen am ControlFilter Attribut

In der Enum EnumControlFilterApplyState wurden die Optionen IfPositive und IfNegative geändert, da das Verhalten nicht eindeutig war. Das neue Verhalten ist in diesem Kapitel beschrieben. In der Regel wurde EnumControlFilterApplyState.IfPositive im ControlFilter Attribut für Aktionen der Ribbon bar verwendet. In diesem Fall kann man es einfach auf EnumControlFilterApplyState.OptIn ändern.

Icons

Icons werden jetzt immer in schwarz geholt und die Farbe per css gesetzt, den Style Helper gibt es generell nicht mehr, und GetIconUrl im Icon Helper hat eine neue Signatur ohne die Optionale Farbe. Wenn man die GetIconURL Methode bisher genutzt hat oder eigene Icons eingebunden hat, sollte man sich das geänderte Icon Kapitel anschauen.

Änderungen an Workern

Es gibt einige neue Status für Hintergrundprozesse. (Siehe Dokumentation)

Normalerweise werden diese automatisch behandelt. Bei bestimmten eigenen Implementierungen ist aber Vorsicht geboten.

Worker müssen abbrechbar sein

Auch wenn ein Worker IsCancellable = false hat, sollte er immer abbrechbar sein, denn der Status ShutdownRequest kann immer eintreten. Andernfalls ist das Verhalten bei einem Anwendungsneustart, während der Worker läuft, nicht transaktionssicher und verzögert jeden Anwendungsneustart um eine Minute.

Dazu ist wie bisher regelmäßig die Bedingung State != EnumWorkItemState.Running zu prüfen und ggf. die Arbeit sofort zu beenden. Der Prozess wird dann nach dem Anwendungsneustart automatisch neu eingeplant.

override WorkItemFinished

Wenn diese Methode überschrieben wurde, muss darauf geachtet werden dass der neue Status ShutdownConfirmed entweder an base.WorkItemFinished weitergegeben oder korrekt behandelt wird.

override WorkItemShouldFinish

Diese Methode kann zukünftig auch mit dem neuen Status ShutdownRequest aufgerufen werden.

Des Weiteren kann es unter bestimmten Umständen mehr als einen Aufruf pro Work-Item geben, wenn sich der Grund für den Abbruch ändert. Das passiert z.B. dann, wenn einer Zeitüberschreitung zufällig unmittelbar einem Abbruch durch den User folgt.

EnumWorkItemState.Idle umbenannt

Das heißt jetzt WaitingForStart.

Sonstiges

• ISubAddressesHelperImplementation hat eine weitere Methode erhalten.
• Die Methode Api.User.CreateUserProfile existiert nicht mehr. Statt dessen ist über die “üblichen” API Methoden ein neuer OrmUserProfile-Datensatz anzulegen und zu speichern.
• EnumRelationTypeExtension.AssignTo Relation aus dem Follow Up in den Core verschoben EnumRelationType.AssignTo
• Wird auf Cpa_EmailAddress programmatisch zugegriffen, bekommt der Aufrufer jetzt ein Object, dass ein List ist, anstelle von vorher nur ein object.

© by GEDYS IntraWare GmbH 2017