Skip to content

Dynamics 365 CRM verstehen: Dataverse, C#-Plugins und Datenmigration

Praxiswissen für Einsteiger und Entwickler

Dynamics 365 CRM von Grund auf: Was ist Dataverse? Wie funktionieren Tabellen, Formulare, Sicherheit und C#-Plugins? Ein verständlicher Praxisleitfaden mit Migrationscheckliste.

Dynamics 365 CRM verstehen: Dataverse, C#-Plugins und Datenmigration
Architektur und Verarbeitungsschritte im Überblick.

1. Was ist Dynamics 365 CRM?

Dynamics 365 Sales, Customer Service und Field Service sind Anwendungen für Vertrieb, Service und Außendienst. Viele ihrer Daten werden in Microsoft Dataverse gespeichert. Dataverse ist mehr als eine SQL-Datenbank: Es bietet Geschäftsobjekte, Beziehungen, Berechtigungsmodelle, APIs, Ereignisse und Plattformfunktionen. Eine modellgesteuerte App stellt diese Daten über Formulare und Ansichten dar.

2. Was sind Tabellen, Spalten und Beziehungen?

Eine Tabelle account repräsentiert beispielsweise Unternehmen, contact Ansprechpartner und opportunity Verkaufschancen. Tabellen besitzen Spalten und Datensatzkennungen. Über Beziehungen verknüpfst du Ansprechpartner mit Unternehmen. Bevor du Tabellen neu anlegst, prüfe Standardtabellen und ihre Semantik. Eigene Spalten müssen in einer verwaltbaren Solution gepflegt werden.

3. Anpassungen ohne C# beginnen

Viele Anforderungen lassen sich mit Formularen, Ansichten, Business Rules und Power Automate umsetzen. Ein Pflichtfeld oder eine Sichtbarkeitsregel benötigt nicht automatisch ein Plugin. Definiere zunächst die fachliche Anforderung und überlege, ob sie nur die Oberfläche betrifft oder beim Speichern unabhängig vom Client verbindlich gelten muss.

4. Wann brauchst du ein C#-Plugin?

Ein Dataverse-Plugin reagiert auf Plattformereignisse wie Create oder Update. Es kann Daten validieren und Geschäftsregeln beim Speichern durchsetzen. Wichtig sind die Pipeline-Stufen PreValidation, PreOperation und PostOperation sowie synchroner oder asynchroner Betrieb. PreOperation kann geeignete Eigenschaften des Target verändern, bevor der Datensatz geschrieben wird; PostOperation ist für nachgelagerte Aufgaben gedacht.

5. Ein einfaches Plugin-Beispiel

Das folgende Plugin normalisiert eine beispielhafte eigene Textspalte beim Anlegen eines Accounts. Ersetze new_externalreference durch den echten logischen Namen deiner Lösung. Das Beispiel ist bewusst klein und implementiert keine Nummernvergabe.

using System;
using Microsoft.Xrm.Sdk;

public class NormalizeAccountReference : IPlugin
{
    public void Execute(IServiceProvider services)
    {
        var context = (IPluginExecutionContext)
            services.GetService(typeof(IPluginExecutionContext));
        if (context?.MessageName != "Create" ||
            !context.InputParameters.Contains("Target") ||
            context.InputParameters["Target"] is not Entity target ||
            target.LogicalName != "account")
            return;

        var value = target.GetAttributeValue<string>("new_externalreference");
        if (!string.IsNullOrWhiteSpace(value))
            target["new_externalreference"] = value.Trim().ToUpperInvariant();
    }
}

Registriere diesen Schritt für Create auf account in PreOperation. Installiere das passende Microsoft.CrmSdk.CoreAssemblies-Paket für dein Projekt und teste das Plugin in einer isolierten Umgebung.

6. Warum eindeutige Nummern nicht per Zeitstempel erzeugen?

Zwei Anfragen können in derselben Sekunde eintreffen; ein Zeitstempel allein garantiert daher keine eindeutige Kundennummer. Verwende stattdessen einen geeigneten Nummernkreis, einen atomaren Zähler oder eine zuverlässig erzwungene eindeutige Geschäftskennung. Behalte mögliche parallele Plugin-Ausführungen und die maximale Ausführungszeit im Blick.

7. Dataverse Web API und Integrationen

Dataverse stellt eine Web API bereit. Andere Dienste können damit unter Beachtung von OAuth, Sicherheitsrollen, Paging und Service-Schutzgrenzen Daten lesen oder schreiben. Für asynchrone Verbindungen zu Business Central oder SharePoint können Azure Functions, Service Bus oder Logic Apps sinnvoll sein. Ein synchrones Plugin sollte keine lang laufende, fehleranfällige Fremdsystem-Verarbeitung durchführen.

8. Datenmigration: die richtige Reihenfolge

Bestimme zuerst das Mapping für Accounts, Contacts, Opportunities und die benötigten Referenzen. Bereinige Dubletten und Option Sets, migriere Basisdaten vor abhängigen Datensätzen und verwende verlässliche externe Schlüssel. Danach folgen Aktivitäten und offene Vorgänge. Teste Zuweisungen zu Benutzern, Teams und Organisationseinheiten, bevor du einen Delta-Cutover planst.

9. Sicherheit und Berechtigungen

Dataverse-Sicherheitsrollen steuern unter anderem Lesen, Schreiben und Löschen auf verschiedenen Zugriffsebenen. Ein verborgenes Formularfeld ist keine Datensicherheitsregel. Für Integrationen nutze eine dedizierte Anwendung oder geeignete verwaltete Identitäten mit den benötigten Berechtigungen. Prüfe Feldsicherheit, Auditing und personenbezogene Daten.

10. Tests und Betrieb

Teste Plugin-Ausführungen mit leeren Feldern, konkurrierenden Aktualisierungen und ungültigen Eingaben. Prüfe, ob Plugins bei Massendatenimporten unerwartet viele Aufrufe erzeugen. Nutze nachvollziehbares Tracing ohne Secrets. Bei Migrationen zählen nicht nur importierte Datensatzmengen, sondern Beziehungen und fachliche Konsistenz.

11. Fazit

CRM-Entwicklung beginnt beim Verständnis der Dataverse-Datenstruktur. C# ist dann sinnvoll, wenn eine technische Geschäftsregel plattformseitig und unabhängig von der Benutzeroberfläche erzwungen werden muss.

Offizielle Referenzen

Kommentare (0)

Noch keine Kommentare. Schreibe den ersten Beitrag zur Diskussion.

Kommentar schreiben