Anwendungsspezifische Konfiguration
Nachfolgende Konfigurationen in der Konfigurationsdatei appsettings.json sind optional und je nach Anwendungsfall notwendig oder nicht.
Duplikatsprüfung
Unter "ObjDuplicateCheck" kann konfiguriert werden, welche Objekte als Duplikat erkannt werden sollen.
Standardmässig wird ein gefundenes Duplikat im Zielsystem als neues Referenzobjekt für die Migrationsdaten verwendet. Das Duplikat wird im Zielsystem nicht importiert.
In anderen Worten: wenn z.B. ein Duplikat zu einer Person im Zielsystem gefunden worden ist, wird diese Person aus dem Zielsystem verwendet und die identische Person aus den Migrationsdaten wird nicht erneut importiert. Alle Referenzen (Assoziationen) zur Person aus den Migrationsdaten werden neu auf das gefundene Person-Objekt aus dem Zielsystem ausgerichtet (Assoziationen in den Migrationsdaten werden mit der Guid der Person aus dem Zielsystem verknüpft).
Pro Typdefinition kann konfiguriert werden, was als Duplikat gilt.
"ObjDuplicateCheck":
{
"Definitions": [
{
"TypeKey": "Person",
"ComparisonFields": [ "Vorname", "Name", "Geburtsdatum" ]
},
{
"TypeKey": "Stammdaten",
"ComparisonFields": [ "Bezeichnung" ]
},
{
"TypeKey": "Land",
"ComparisonFields": [ "Name" ]
},
{
"TypeKey": "Heimatort",
"ComparisonFields": [ "Name", "Kantonskuerzel" ]
}
]
}
ComparisonFields
Die Angabe der ComparisonFields ist für jede Duplikats-Definition obligatorisch. Hiermit wird definiert, welche Felder aus den Migrationdaten mit dem Zielsystem verglichen werden sollen, um Duplikate zu ermitteln.
Im folgendem Beispiel wird eine Person als Duplikat erkannt, wenn Vorname, Name und Geburtsdatum alle gleich sind.
{
"TypeKey": "Person",
"ComparisonFields": [ "Vorname", "Name", "Geburtsdatum" ]
}
Es können auch mehrere identische Typdefinitionen konfiguriert werden. Z.B. kann der Kontakt ein Duplikat sein, wenn Vorname, Name und Geburtstag identisch ist oder wenn die AHV-Nummer die gleiche ist oder wenn der FremdKey der gleiche ist.
{
"TypeKey": "Person",
"ComparisonFields": [ "Vorname", "Name", "Geburtsdatum" ]
},
{
"TypeKey": "Person",
"ComparisonFields": [ "SozialversNr" ]
},
{
"TypeKey": "Person",
"ComparisonFields": [ "Fremdkey" ]
}
Conditions
Es können optional Conditions konfiguriert werden. Diese definieren, dass ein Objekt nur unter gewissen Bedingungen als Duplikat erkannt werden soll.
Im folgenden Beispiel wird ein Geschäft nur dann als Duplikat erkannt, wenn dessen Signatur nicht mit dem Kürzel "SK" beginnt.
{
"TypeKey": "Geschaeft",
"ComparisonFields": [ "Signatur" ],
"Conditions": [
{
"Field": "Signatur",
"Regex": "^(?!SK).+"
}
]
}
Hinweis: wenn mehr als 1 Condition definiert wird, werden diese UND-verknüpft.
UpdateFields
Es können optional "UpdateFields" konfiguriert werden. Diese definieren, welche Felder bei einem allfälligen Duplikat mit den entsprechenden Werten aus den Migrationsdaten überschrieben werden sollen.
Im folgenden Beispiel wird ein Geschäft nur dann als Duplikat erkannt, wenn dessen Signatur mit Kürzel "SK" beginnt. Die angegebenen Felder aus "UpdateFields" werden bei allen gefundenen Duplikaten im Zielsystem mit den Werten aus den Migrationsdaten überschrieben (DirectImport-Vorgang).
{
"TypeKey": "Geschaeft",
"ComparisonFields": [ "Signatur" ],
"Conditions": [
{
"Field": "Signatur",
"Regex": "^SK"
}
],
"UpdateFields": [ "CustomAlteLaufnummer", "CustomAlteObjektID", "Geschaeftseigner.Organisationseinheit.Parentkey", "Geschaeftseigner.Benutzer.BenutzerID" ]
}
DuplicateCausesError
Standardmässig wird ein gefundenes Duplikat im Zielsystem als neues Referenzobjekt für die Migrationsdaten verwendet. Falls ein gefundenes Duplikat im Zielsystem jedoch nicht erwünscht ist (z.B. weil das Objekt aus den Migrationsdaten Priorität hat und unbedingt importiert werden muss), dann können gefundene Duplikate auch als Fehler ausgewiesen werden. Hierfür muss zusätzlich die Option "DuplicateCausesError" auf true gesetzt werden (diese ist standardmässig auf false gesetzt).
{
"TypeKey": "Person",
"ComparisonFields": [ "Vorname", "Name", "Geburtsdatum" ],
"DuplicateCausesError": true
}
Mapping für Felder und Assoziationen
Unter "FieldData" können Feldwerte oder Assoziationen in den Migrationsdaten überschrieben werden. - Unter "FieldKey" wird angegeben, welches Feld/Assoziation überschrieben werden soll. - Unter "Mapping" wird der neue Wert konfiguriert (fixer oder dynamisch zusammengesetzter Wert)
Syntax des FieldKey:
- Felder: \<TypdefinitionKey>.\
"FieldData":
{
"Mappings": [
{
"FieldKey": "Schuljahr.Gekobereich.Gekobereich.Kurzname",
"Mapping": "SADL"
},
{
"FieldKey": "Lernendedossier.CustomRegistraturplan.CustomRegistraturplan.Aktenzeichen",
"Mapping": "1"
},
{
"FieldKey": "Unterrichtspersonalanstellung.Bemerkung",
"Mapping": "{{Titel}}"
}
]
}
Referenz auf andere Felder
Zusätzlich zu fixen Werten können auch Werte aus anderen Feldern des gleichen Objekts verwendet werden. Dafür muss im Mapping der Feld-Key mit doppelten Curly-Braces angegeben werden.
{
"FieldKey": "Dokument.Titel",
"Mapping": "{{Laufnummer}} - {{Titel}} - Version SK-SG"
}
Conditions
Es können optional Conditions definiert werden. Diese definieren, dass ein Mapping (Überschreiben eines Feldwertes) nur unter gewissen Bedingungen gemacht werden soll.
Im folgenden Beispiel wird der Gekobereich der Dokumentkategorie nur dann mit einem fixen Wert überschrieben, wenn kein Gekobereich assoziiert ist.
{
"FieldKey": "Dokumentkategorie.Vater.Gekobereich.Kurzname",
"Mapping": {
"Value": "SR-SG",
"Conditions": [
{
"Field": "Vater.Gekobereich.Kurzname",
"Regex": "(?!\\s*$).+"
}
]
}
}
NewObj
Für jedes Mapping kann optional definiert werden, ob im selben Zuge direkt auch ein neues Objekt erstellt werden soll, welches mit dem aktuellen Objekt verknüpft werden kann.
Im folgenden Beispiel wird der Ordner von jedem Dokument, welches direkt an einem Geschäft hängt und sich nicht in einem Unterordner befindet (siehe Conditions) neu gesetzt. Dabei wird nicht auf den ParentKey eines bestehenden Ordners in den Migrationsdaten oder im Zielsystem verwiesen, sondern direkt ein neues "Ordner"-Objekt angelegt (falls noch nicht vorhanden).
{
"FieldKey": "Dokument.GeschaeftPosteingangExplorer.Ordner.ParentKey",
"Mapping": {
"Value": "MandantenOrdner-{{GeschaeftPosteingangExplorer.Geschaeft.ParentKey}}",
"Conditions": [
{
"Field": "GeschaeftPosteingangExplorer.Geschaeft.ParentKey",
"Regex": "(?!\\s*$).+"
}
],
"NewObj": {
"Titel": "Migration SK-SG",
"Parentkey": "{{Value}}",
"Parent.AbstraktesGeschaeft.ParentKey": "{{GeschaeftPosteingangExplorer.Geschaeft.ParentKey}}",
"ExpliziterZugriffSchreiben.Organisationseinheit.Kurzname": "{{GeschaeftPosteingangExplorer.Geschaeft.Geschaeftseigner.Organisationseinheit.Kurzname}}",
"ExpliziterZugriffSchreiben.Benutzer.BenutzerID": "{{GeschaeftPosteingangExplorer.Geschaeft.Geschaeftseigner.Benutzer.BenutzerID}}"
}
}
}
Im obigen Beispiel hat das neue "Ordner"-Objekt einen fixen Titel. Der ParentKey entspricht dem "Value" des Mappings (mittels doppelten Curly-Braces und dem Stichwort "Value" wird der Wert dieser Mapping-Definition verwendet), womit auch direkt die Verknüpfung zwischen Dokument und dem neuen "Ordner"-Objekt definiert ist. Das neue "Ordner"-Objekt wird unter dem gleichen Geschäft angesiedelt wie auch das aktuelle Dokument-Objekt.
Reihenfolge
Unter gewissen Umständen ist die Reihenfolge der Mapping-Definitionen relevant.
Im folgenden Beispiel werden alle Organisationseinheiten, welche direkt am Gekobereich hängen (siehe Condition) neu auf eine andere (neue) Vater-Organisationseinheit umgemappt. Erst danach wird der ursprüngliche (direkte) Verweis auf den Gekobereich gelöscht (null).
Die Reihenfolge ist hier sehr relevant. Zuerst wird die neue Vater-Organisationseinheit definiert (mittels NewObj) und erst danach wird der ursprüngliche Vater-Gekobereich gelöscht. Wenn zuerst der Vater-Gekobereich gelöscht werden würde und erst danach die neue Vater-Organisationseinheit gesetzt würde, dann würde die Condition des Mappings für die neue Vater-Organisationseinheit nicht greifen, weil der Gekobereich bereits leer wäre.
{
"FieldKey": "Organisationseinheit.Vater.Organisationseinheit.Kurzname",
"Mapping": {
"Value": "SK-SG",
"Conditions": [
{
"Field": "Vater.Gekobereich.Kurzname",
"Regex": "(?!\\s*$).+"
}
],
"NewObj": {
"Kurzname": "SK-SG",
"Name": "Bürgschaft und Behörden",
"Vater.Gekobereich.Kurzname": "SR-SG",
"Uebernehmen": true
}
}
},
{
"FieldKey": "Organisationseinheit.Vater.Gekobereich.Kurzname",
"Mapping": null
}
Feldtypen
RefNumField
Bei Refnum-Feldern mit nur einer Variante wird das passende Schema direkt aus dem Modell ausgelesen.
Falls bei einem gelieferten Refnum-Feld mehrere Varianten möglich sind, kann die passende Variante konfiguriert werden.
"RefNumField":
{
"SchemaValidations": [
{
"TypeKey": "Schuleinheit",
"FieldKey": "kurzname",
"VariantId": 374,
"LevelId": 373
},
{
"TypeKey": "Schulträger",
"FieldKey": "kurzname",
"VariantId": 374,
"LevelId": 373
}
]
}
AssociationField
In Assoc-Feldern mit einer 0/1..n Kardinalität können mehrere Felder mit einem Trennzeichen hinterlegt werden. Das verwendete Trennzeichen in den Migrationsdaten kann hier konfiguriert werden.
"AssociationField":
{
"ValueDelimiter": "•"
}
DocumentField
Pfad zum Ordner, in welchem Dokumente oder Bilder abgelegt sind.
"AssociationField":
{
"FilesPath": "C:\\CMI\\sadl\\Installation\\Input"
}
Typdefinitionen einschränken
Unter "MigrationTypeDataCache" kann die Verarbeitung und Validierung der Migrationsdaten kann auf bestimmte Typdefinitionen eingeschränkt werden. Dies kann sinnvoll sein, wenn die Daten eines Kunden schrittweise validiert werden sollen oder bei Datenkorrekturen nur noch die neu erstellten Typdefinitionen geprüft werden sollen.
"MigrationTypeDataCache":
{
"TypesToBeProcessed": [
"Absenzgrund"
]
}