Freigeben über

Bewährte Methoden für das Entwickeln mit Microsoft Dynamics 365

  • Artikel

 

Veröffentlicht: Januar 2017

Gilt für: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

In diesem Thema werden bewährte Methoden zum Anpassen von Microsoft Dynamics 365 (online und lokal) beschrieben.

Wichtig

Lesen Sie Unterstützte Erweiterungen für Microsoft Dynamics 365, um Informationen über unterstützte und nicht unterstützten Techniken für Anpassungen zu erhalten.

In diesem Thema

Bewährte Methoden für die Leistung

Bewährte Methoden für Anpassungen

Bewährte Methoden für Sicherheit

Bewährte Methoden zur ISV-Erweiterbarkeit

Bewährte Methoden für die Leistung

Die folgenden bewährten Methoden können hilfreich sein, um leistungsstärkeren Code zu schreiben.

Verwenden von Multi-Threads

Fügen Sie der Anwendung Threading-Unterstützung hinzu, um die Arbeit über mehrere CPUs zu verteilen. Bei diesem Vorschlag wird davon ausgegangen, dass Sie Ihren Code auf einem Multiprozessorsystem ausführen.Weitere Informationen:Artikel über verwaltetes Threading im Handbuch für erweiterte Entwicklung mit NET Framewor.

Zulassen der Erstellung von GUIDs durch das System

Erlauben Sie dem System, die GUID (ID) automatisch zuzuweisen, anstatt sie manuell selbst zu erstellen. Dieser Vorschlag ermöglicht es Microsoft Dynamics 365, sequenzielle GUIDs zu nutzen, die bessere SQL Leistung bieten. Der folgende Beispielcode zeigt, wie die Methode Create aufgerufen wird, um eine vom System zugewiesene GUID zu erhalten.

// Instantiate an account object.Account account = new Account { Name = "Fourth Coffee" };
// Create an account record named Fourth Coffee and retrieve the GUID.accountId = serviceProxy.Create(account);

Verwenden von Typen mit früher Bindung

Verwenden Sie die Klasse Entity, wenn Ihr Code mit Entitäten und Attributen arbeiten muss, die zu dem Zeitpunkt, an dem der Code geschrieben wird, nicht bekannt sind. Zudem, wenn Ihr Code mit tausenden benutzerdefinierten Entitäten arbeitet, kann durch die Verwendung der Entity-Klasse eine etwas bessere Leistung erzielt werden als mit früh gebundenen Entitätstypen. Diese Flexibilität hat jedoch einen Nachteil, weil Sie Entitäts- und Attributnamen zur Kompilierzeit nicht überprüfen können. Sind die Entitäten zur Codezeit bereits definiert und ist ein geringfügiger Leistungsabfall akzeptabel, sollten Sie die Typen mit früher Bildung verwenden, die Sie erstellen können, indem Sie das Tool CrmSvcUtil verwenden.Weitere Informationen:Verwenden Sie im Code die Entitätsklassen mit früher Bindung

Deaktivieren von Plug-Ins

Sofern möglich, deaktivieren Sie registrierte Plug-Ins, bevor Sie die Anwendung ausführen.

Schreiben von Plug-Ins, die sich schneller ausführen lassen

Schreiben Sie immer ein Plug-In, das die wenigste Zeit beansprucht, um seine beabsichtigte Aufgabe auszuführen. Beispielsweise wird die Methode Execute häufig in Microsoft Dynamics 365 verarbeitet. Wenn Sie ein Plug-In auf diese Meldung registrieren, kann das Plug-In eine signifikante Auswirkung auf die Systemleistung haben, da es jedes Mal ausgeführt wird, wenn die Execute-Methode verarbeitet wird, was häufig vorkommt.

Wenn Sie Ihre Plug-Ins für synchrone Ausführung registrieren möchten, wird empfohlen, sie so zu entwerfen, dass sie ihre Ausführung in weniger als 10 Sekunden abschließen. Es empfiehlt sich, die Verarbeitungszeit in Plug-Ins zu minimieren, um die Interaktivität der Client-Anwendungen beizubehalten, die mit dem gleichen Organisationsservice verbunden sind, der das Plug-In ausführt.

Begrenzen der abgerufenen Daten

Wenn Sie die Methoden verwenden, mit denen Daten vom Server abgerufen werden, rufen Sie die Mindestmenge von Daten ab, die für Ihre Anwendung erforderlich ist. Dazu geben Sie den Spaltensatz an, der der Satz der abzurufenden Entitätsattribute ist.

Beispielsweise ist es selten sinnvoll, alle Metadaten mit der Meldung RetrieveAllEntitiesRequest abzurufen und EntityFilters anzugeben.All-Entitätsfilter für die Eigenschaft EntityFilters. Stattdessen wird möglicherweise eine bessere Leistung erzielt, wenn Sie den Entitätsfilter einschränken oder eine der folgenden Meldungen verwenden: RetrieveEntityRequest, RetrieveOptionSetRequest, RetrieveAttributeRequest, RetrieveRelationshipRequest oder RetrieveMetadataChangesRequest. Die RetrieveMetadataChanges-Meldung ermöglicht das Erstellen einer Abfrage, um nur die Metadaten zurückzugeben, die Sie benötigen, oder die Metadaten, die geändert wurden.Weitere Informationen:Abrufen und Erkennen von Änderungen bei Metadaten.

Beschränken der Anzahl der Entitäten, die für den Offlinemodus aktiviert sind

bedenken Sie sorgfältig, ob eine Entität für Personen im Offlinemodus verfügbar sein muss. Jede Entität, die Sie für die Offlinefunktion aktivieren, wirkt sich auf die Zeit für die Synchronisierung der Daten aus, wenn wieder online gegangen wird. Dies gilt besonders für Personen mit weniger leistungsfähigen Computern.

Begrenzen von Vorgängen, die zu verknüpften Entitäten kaskadieren

Wenn Sie die Methode Update oder die Meldung UpdateRequest verwenden, legen Sie das Attribut OwnerId nicht für einen Datensatz fest, es sei denn, der Besitzer hat sich tatsächlich geändert. Wenn dieses Attribut festgelegt wird, kaskadieren die Änderungen häufig zu verbundenen Entitäten, wodurch sich die Zeit verlängert, die für das Update erforderlich ist.Weitere Informationen:Kaskadierende Verhaltensweise

Anpassen von Proxyeinstellungen auf dem Client (nur lokal)

Ein Proxyserver befindet sich zwischen einer Client-Anwendung, beispielsweise einem Webbrowser, und dem tatsächlichen Zielserver. Wenn sich ein Computer in einem lokalen Netzwerk befindet, kann er einen Proxyserver verwenden, um die Verbindung mit dem Internet herstellen. In diesem Fall ist der Proxy entweder mit dem Gatewayserver und Firewallserver kombiniert oder Teil davon. Der Proxy kann Internet-Anforderungen zwischenspeichern und mehrere Clientanforderungen verarbeiten, indem er ihre zwischengespeicherten Daten verwendet. Wenn die angeforderten Daten nicht im Cache des Proxyservers vorhanden sind, leitet er die Anforderung an den eigentlichen Server weiter, indem er seine eigene IP-Adresse verwendet. Hier führt der Proxyserver Vorgänge im Namen des Clientcomputers aus.

Obwohl ein Proxyserver als Cacheserver fungieren kann und helfen kann, eine Webseite schneller zu laden, kann sich manchmal seine Leistung verringern, wenn er nicht ordnungsgemäß verwendet wird. Häufig vermeiden Benutzer die manuelle Proxykonfiguration und verwenden die automatische Proxykonfiguration. Diese Verknüpfung unterstützt den Lastenausgleich bei Proxyservern, aber abhängig von der Komplexität des Konfigurationsskripts, kann eine bedeutende Verzögerung auftreten, wenn Sie die automatische Proxykonfiguration verwenden.

Wenn der Microsoft Dynamics 365-Server installiert ist, können Sie den Proxyserver umgehen, um einen besseren Durchsatz zu erreichen. Der Server bietet eine lokale Internetadresse, die nicht erfordert, dass ein Proxy erreicht wird. Sie können Bypass-Proxyserver für lokale Adressen auswählen und den vollqualifizierten Domänennamen des Microsoft Dynamics 365-Servers in der Ausnahmeliste bereitstellen. Dies ergibt einen besseren Durchsatz, wenn Datensätze mithilfe von Microsoft Dynamics 365 SDK erstellt werden.

Verbessern der Servicekanal-Zuteilungsleistung

Sie können eine Verbindung mit den Microsoft Dynamics 365-Webdiensten herstellen und Benutzer authentifizieren, indem Sie die Serviceproxyklassen OrganizationServiceProxy und DiscoveryServiceProxy verwenden. Allerdings kann die unsachgemäße Verwendung dieser Serviceproxyklassen manchmal die Anwendungsleistung verringern. Wenn Sie daher wissen, wann und wie die verschiedenen Client-Klassen verwendet werden, die im SDK verfügbar sind, können Sie häufig eine bessere Anwendungsleistung erhalten.

Wenn Sie einen Windows Communication Foundation (WCF)-Servicekanal einrichten, indem Sie einen Dienstendpunkt verwenden, beispielsweise indem Sie den Organisationswebdienst verwenden, muss die Anwendung zwei zeitaufwändige Vorgänge ausführen: Metadaten vom Endpunkt herunterladen und Benutzerauthentifizierung. Sie können die Leistung verbessern, wenn die Anwendung diese Vorgänge mit einer Mindestanzahl von Wiederholungen für jede Anwendungssitzung ausführt. Der OrganizationServiceProxy-Konstruktor, der hier dargestellt wird, führt diese beiden Vorgänge immer aus, wenn ein Serviceproxyobjekt erstellt wird.

OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, ClientCredentials deviceCredentials)

Sie erzielen in der Regel eine bessere Leistung, wenn die Anwendung diesen Konstruktor verwendet, um eine Instanz des Serviceproxys zu erstellen, indem sie diesen Konstruktor einmal während der Anwendungssitzung verwendet und den zurückgegebenen Verweis für die Verwendung in verschiedenen Codepfaden innerhalb der Anwendung zwischenspeichert. Beachten Sie, dass der zurückgegebene Serviceverweis nicht thread-sicher ist, sodass Multi-Thread-Anwendungen eine Instanz pro Thread zuordnen müssen. Anwendungen müssen auf dem Serviceproxyobjekt auch Dispose aufrufen, bevor sie enden, damit dem Servicekanal zugeordnete Ressourcen freigegeben werden.

Die Serviceproxyklasse führt den Metadatendownload und die Benutzerauthentifizierung aus, indem sie die folgenden Klassenmethoden anwendet.

IServiceManagement<IOrganizationService> orgServiceManagement = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(new Uri(organizationUrl))AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials)

Die Methode CreateManagement<TService> führt den Metadatendownload aus, während die Methode Authenticate den Benutzer authentifiziert. Die von diesen Methoden zurückgegebenen Objekte sind thread-sicher und können von Ihrer Anwendung statisch zwischengespeichert werden. Sie können dann diese Objekte verwenden, um ein Serviceproxyobjekt zu erstellen, das einen der anderen verfügbaren Konstruktoren verwendet.

OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)

Durch Zwischenspeichern der Serviceverwaltung und authentifizierten Anmeldeinformationsobjekte kann die Anwendung die Serviceproxyobjekte mehr als einmal pro Anwendungssitzung effizienter erstellen. Bei Aktivierung von Typen mit früher Bildung auf OrganizationServiceProxy durch eine der EnableProxyTypes-Methoden müssen Sie das gleiche bei allen Serviceproxies ausführen, die mit dem zwischengespeicherten IServiceManagement<TService>-Objekt erstellt werden. Wenn die Anwendung die Metadaten verwendet, wird empfohlen, dass sie die abgerufenen Metadaten zwischenspeichert und in regelmäßigen Abständen die Meldung RetrieveTimestampRequest aufruft, um zu bestimmen, ob sie den Cache aktualisieren muss.

Überwachen Sie zudem das WCF Sicherheitstoken (Token) und aktualisieren Sie es vor dessen Ablauf, damit Sie das Token nicht verlieren und mit der Authentifizierung wieder von vorn beginnen müssen. Um das Token zu überprüfen, erstellen Sie eine benutzerdefinierte Klasse, die vom OrganizationServiceProxy oder der DiscoveryServiceProxy-Klasse erbt und die Geschäftslogik implementiert, um das Token zu überprüfen. Oder packen Sie die Proxyklassen in eine neue Klasse. Eine weitere Technik besteht darin, das Token vor jedem Aufrufen des Webdiensts explizit zu überprüfen. Beispielcode, der diese Techniken veranschaulicht, kann in den Klassen ManagedTokenDiscoveryServiceProxy, ManagedTokenOrganizationServiceProxy und AutoRefreshSecurityToken im Thema Hilfscode: Klasse "ServerConnection" gefunden werden.

Bewährte Methoden für Anpassungen

Die folgenden bewährten Methoden können hilfreich sein, um Microsoft Dynamics 365 anzupassen und zu erweitern.

Bewährte Methoden für Microsoft Dynamics 365 (online)

Der Microsoft Dynamics CRM Online-Muster und -Prinzipien für Lösungsentwickler-Whitepaper-Download enthält Anweisungen speziell zur Erstellung von Lösungen mithilfe von Microsoft Dynamics 365 (online).

Verwenden von benutzerdefinierten Entitäten und Attributen

Verwenden Sie immer den Entitätsschemanamen, um in Abfragen und Code auf eine benutzerdefinierte Entität zu verweisen. Verwenden Sie nicht den Objekttypencode (auch Entitätstyp genannt), da dieser ganzzahlige Wert für benutzerdefinierte Entitäten in verschiedenen Organisationen variiert.

Sparen Sie Speicherplatz auf Ihrem Server mithilfe dieser Techniken:

  • Erstellen Sie benutzerdefinierte Attribute für bestehende Entitäten, anstatt eine neue Entität zu erstellen.

  • Benennen Sie vorhandene Entitäten um, um die Namen aussagekräftiger zu machen.

Wann sollte eine Entität angepasst werden?

Passen Sie eine Systementität an, wie beispielsweise die Verkaufschancenentität, anstatt sie durch eine neue benutzerdefinierte Entität zu ersetzen, sodass Sie die vielen integrierter Funktionen in einer vorhandenen Entität verwenden können. Beispielsweise verfügen die Verkaufschancen- und Fallentitäten über Suchfelder, um Kunden zuzuordnen. Bei Kunden kann es sich um Firmen oder Kontakte handeln. Sie können eine benutzerdefinierte Entität erstellen, die den gleichen Typ der Suche hat. Sie können den Anzeigenamen einer Systementität ändern, um ihn für Ihr Unternehmen aussagekräftiger zu machen.

Verwenden von Plug-Ins oder Workflow?

Als Entwickler, der interessiert ist, Microsoft Dynamics 365 zu erweitern oder anzupassen, können Sie unter mehreren Methoden wählen, um Ihre Aufgaben auszuführen. Zusätzlich zum Hinzufügen von clientseitigem JavaScript-Code zu einem Formular oder Hinzufügen von benutzerdefinierten ASP.NET-Seiten können Sie ein Plug-In schreiben oder einen benutzerdefinierten Workflow erstellen, indem Sie die Weboberfläche verwenden, die eine benutzerdefinierte Workflowaktivität aufruft. Wie wird entschieden, wann ein Plug-In und wann ein Workflow verwendet wird? Die Technologie, die Sie verwenden, hängt von der Aufgabe ab, die Sie ausführen müssen, und wer die Anpassung durchführt.

Beispielsweise müssen Sie einen synchronen Plug-In-Echtzeitworkflow verwenden, wenn Sie benutzerdefinierten Code sofort oder nach Ausführung des Kernplattformvorgangs und bevor das Ergebnis des Vorgangs von der Plattform zurückgegeben wird, ausführen möchten. Sie können einen asynchronen Workflow oder ein asynchrones Plug-In in dieser Situation nicht verwenden, da diese in die Warteschlange verschoben werden, um nach Ausführungsende des Kernvorgangs ausgeführt zu werden. Daher können Sie nicht voraussagen, wann sie ausgeführt werden. Wenn Sie zu Microsoft Dynamics 365 (online) benutzerdefinierte Funktionen hinzufügen möchten, werden Workflows und Plug-Ins unterstützt, jedoch keine benutzerdefinierten Workflowaktivitäten.

Bewerten Sie diese Technologien und wählen Sie diejenige aus, die Ihren Geschäftszielen am besten entspricht, nachdem Sie die Bereitstellung, Leistung und Wartungsaspekte Ihrer Plug-In- oder Workflowlösung berücksichtigt haben.

In der folgenden Tabelle werden die Eigenschaften von Plug-Ins und Workflows zusammengefasst.

Kriterien

Plug-In

Workflow

Ausführung vor oder nach dem Kernplattformvorgang (Erstellen, Aktualisieren, Löschen usw.).

Wird unmittelbar vor oder nach dem Kernvorgang ausgeführt (synchron).

Kann auch in die Warteschlange verschoben werden, um nach dem Kernvorgang ausgeführt zu werden (asynchron).

Asynchrone Workflows werden in die Warteschlange verschoben, um nach dem Kernvorgang ausgeführt zu werden.

Echtzeitworkflows haben ähnliche Eigenschaften wie Plug-Ins.

Leistungsauswirkung auf den Server

Synchrone Plug-Ins können die Plattformreaktionszeit erhöhen, da sie Teil der Hauptplattformverarbeitung sind.

Asynchrone Plug-Ins haben weniger Einfluss auf die Serverreaktionszeit, da der Code in einem anderen Prozess ausgeführt wird.

Asynchrone Workflows haben weniger Einfluss auf die Serverreaktionszeit, da der Code in einem anderen Prozess ausgeführt wird.

Echtzeitworkflows haben ähnliche Leistungsmerkmale wie Sandkasten-Plug-Ins.

Sicherheitsbeschränkungen

Um ein Plug-In mit der Plattform zu registrieren, ist die Sicherheitsrolle Systemadministrator oder Systemanpasser sowie eine Mitgliedschaft in der Bereitstellungsadministratorgruppe erforderlich.

Benutzer können in der Webanwendung interaktiv Workflows erstellen.

Um jedoch eine benutzerdefinierte Workflowaktivität zu registrieren, muss der bereitstellende Benutzer über die gleichen Sicherheitsrollen verfügen, die für das Registrieren von Plug-Ins erforderlich sind.

Microsoft Dynamics 365-Version Support (SKU)

Unterstützt in Microsoft Dynamics 365 (online), wenn im Sandkasten registriert. Kann in Partner-gehosteten Installationen nach Ermessen des Partners unterstützt werden.

Workflows werden von allen Dynamics 365 Bereitstellungen unterstützt. Benutzerdefinierte Workflowaktivitäten werden im Sandkasten von Microsoft Dynamics 365 (online) und innerhalb oder außerhalb des Sandkastens für lokale Bereitstellungen oder Bereitstellungen mit Internetzugriff (IFD) unterstützt.

Dauer der Verarbeitungszeit

Ein Plug-In, das für synchrone oder asynchrone Ausführung registriert ist, ist für die Durchführung seiner Ausführung auf ein Zwei-Minuten-Zeitlimit beschränkt.

Geeignet für kurze oder lange Prozesse. Allerdings kann jede Aktivität in einem Workflow nicht länger als zwei Minuten bis zum Abschluss dauern.

Geeignet, wenn der Dynamics 365 für Outlook-Client im Offlinemodus ist

Online- und Offlinemodus werden unterstützt.

Workflows sind im Offlinemodus nicht ausführbar.

Prozess- und Datenpersistenz

Plug-Ins werden ausgeführt, bis sie abgeschlossen sind. Plug-Ins müssen so geschrieben werden, dass sie statuslos sind, wobei im Arbeitsspeicher keine Daten beibehalten werden.

Asynchrone Workflows können durch SDK-Aufrufe oder vom Benutzer durch die Webanwendung angehalten, zurückgestellt, abgebrochen und fortgesetzt werden. Der Status des Workflows wird automatisch gespeichert, bevor er angehalten oder zurückgestellt wird.

Echtzeitworkflows können keine Wartezustände haben. Sie müssen bis zum Abschluss ausgeführt werden, genau wie Plug-Ins.

Identitätswechsel

Plug-Ins können im Auftrag eines anderen Systembenutzers Datenvorgänge ausführen.

Asynchrone Workflows können keinen Identitätswechsel verwenden, während Echtzeitworkflows dies können. Echtzeitworkflows können entweder als Besitzer des Workflows oder als der aufrufende Benutzer ausgeführt werden.

Authoring (Erstellung)

Software-Engineers oder Programmierer können Plug-Ins erstellen.

Jeder Benutzer, auch ein Endbenutzer, Business Analyst oder Administrator, kann Workflows erstellen, wenn er die erforderlichen Berechtigungen besitzt.

Die Leistungsauswirkungen auf den Server zwischen einem asynchronen Plug-In und einem Workflow sind nicht signifikant.

Welcher Workflowtyp ist besser?

Ist es unter der Leistungsperspektive besser, einen einzelnen langen Workflow zu erstellen, oder ist es besser, mehrere untergeordnete Workflows zu haben und diese in einem übergeordneten Workflow aufzurufen? Beim Ansatz mit untergeordneten Workflows wird ein niedrigerer Durchsatz erreicht, er ist jedoch leichter zu verwalten, wenn Sie die Workflowdefinition häufig ändern. Der Kompilierungsaufwand ist kein Hauptanliegen, da der Workflow nur während der Veröffentlichung kompiliert wird. Allerdings kann der Aufwand steigen, wenn Microsoft Dynamics 365 jede Workflowinstanz startet. Der Aufwand tritt auf, wenn alle Entitäten, die in dem Workflow verwendet werden, abgerufen werden und der untergeordnete Workflow in einem Zwei-Schritte-Prozess, der eine "Workflow-Erweiterungs-Aufgabe" und die eigentliche Workflowinstanz enthält, gestartet wird. Verwenden Sie daher für maximalen Durchsatz einen einzelnen langen Workflow.

Wie ist die benutzerdefinierte Workflowaktivität als "Abgeschlossen" zu markieren?

Der Rückgabewert von der Execute-Methode wird von der Workflowlaufzeit verwendet, um die Aktivität als "abgeschlossen" zu markieren. Sie sollten return base.Execute(executionContext) verwenden, es sei denn, die Aktivität umgeht die Basisklassenfunktionen. Vermeiden Sie, ActivityExecutionStatus.Closed zurückzugeben.Weitere Informationen:ActivityExecutionStatus-Enumeration

Wie sollten Ausnahmen in benutzerdefinierten Workflowaktivitäten gemeldet werden?

Sie sollten eine InvalidPlugInExecutionException-Ausnahme in Ihrem Code auslösen. Dieser Fehler wird im Workflowinstanzformular angezeigt.

Können Sie benutzerdefinierte Entitäten speziell für Unternehmenseinheiten definieren?

Benutzerdefinierte Entitäten besitzen Rechte für jede Sicherheitsrolle, aber nicht für jede Unternehmenseinheit. Um benutzerdefinierte Entitäten zu definieren, die nur für angegebene Unternehmenseinheiten sichtbar sind, müssen Sie unterschiedliche Sicherheitsrollen für jede Unternehmenseinheit erstellen und der benutzerdefinierten Entität in der entsprechenden Rolle Rechte gewähren.

Bewährte Methoden für Sicherheit

Folgen Sie diesen Richtlinien, um Ihre Geschäftsdaten zu schützen.

Allgemein

Bewährte Methoden zum Sichern Ihrer Implementierung von Microsoft Dynamics 365 enthalten Folgendes:

  • Richten Sie einen genehmigten Sicherheitsdatenplan für die Microsoft Dynamics 365-Implementierung Ihrer Organisation ein.

  • Weisen Sie die erforderlichen Mindestrechte zu, wenn Sie den Anwendungspool einrichten.

  • Verlangen Sie, dass alle Benutzer sichere Kennwörter für ihre Konten verwenden. Weitere Informationen finden Sie in der Windows-Hilfe, indem Sie nach "Sichere Kennwörter" suchen.

Weitere Informationen:TechNet: Sicherheitsüberlegungen zu Microsoft Dynamics CRM

Rollen, Rechte und Zugriffsrechte

Bewährte Methoden zum Verwenden des Microsoft Dynamics 365-Sicherheitsmodells beinhalten Folgendes:

  • Begrenzen Sie streng die Anzahl der Personen, denen die Systemadministratorrolle zugewiesen wird. Entfernen Sie niemals diese Rolle.

  • Erstellen Sie Rollen gemäß der bewährten Sicherheitsmethode basierend auf Mindestrechten, die Zugriff auf die Mindestmenge von Geschäftsdaten bieten, die für die Aufgabe erforderlich ist. Weisen Sie Benutzern die entsprechende Rolle für ihren Auftrag zu.

  • Erstellen Sie eine neue Rolle mit den jeweiligen Rechten und fügen Sie den Benutzer der neuen Rolle hinzu, wenn er zusätzliche Zugriffsebenen oder -rechte benötigt. Die Rechte eines Benutzers umfassen die Gesamtheit aller Rollen, die ihm zugewiesen wurden. Gewähren Sie nicht die ursprünglichen Rollenrechte, die nur für ein oder einige Mitglieder erforderlich sind.

  • Verwenden Sie bei Bedarf die Freigabe, um bestimmten Benutzern bestimmte Berechtigungen für einzelne Objekte zu erteilen, anstatt breitere Rechte für alle Objekte eines gegebenen Typs zu erteilen.

  • Verwenden Sie Teams, um funktionsübergreifende Gruppen zu erstellen, sodass spezifische Objekte für das Team freigegeben werden können.

  • Schulen Sie Benutzer, die Freigabezugriffsrechte haben, zur Vermittlung der erforderlichen Mindestinformationen.

Vermeiden von Rechteerweiterung

Rechteerweiterungsangriffe treten auf, wenn ein Benutzer die Rechte eines vertrauenswürdigen Kontos, wie Besitzer oder Administrator, annehmen kann. Statten Sie Benutzerkonten immer mit so wenig Rechten wie möglich aus und weisen Sie nur die erforderliche Berechtigungen zu. Vermeiden Sie mit Administrator- oder Besitzerkonten für die Ausführung von Code. Dadurch wird der Schaden begrenzt, der bei einem erfolgreichen Angriff auftreten kann. Wenn Aufgaben ausgeführt werden, für die zusätzliche Berechtigungen erforderlich sind, verwenden Sie Prozedur-Signatur oder Identitätswechsel nur während der Dauer der Aufgabe.

Serverseitige Entwicklung

Bewährte Methoden zum Entwickeln von serverseitigem Code für Microsoft Dynamics 365 enthalten Folgendes:

  • Ändern Sie niemals die Microsoft Dynamics 365-Datenbank für einen anderen Zweck als die Anwendung des SDK, da dadurch das Microsoft Dynamics 365-Sicherheitsmodell umgangen wird.

  • Plug-Ins werden in einem Administratorkontext ausgeführt – Sie sollten wissen, dass dieser Code auf Informationen zugreifen kann, für die der angemeldete Benutzer keinen Zugriff besitzt.

  • Vermeiden Sie es bei Workflowassemblys und Plug-Ins, Code zu schreiben, dessen Ausführung lange dauert. Es ist wichtig, dass Plug-In-Code, der für synchrone Ausführung registriert ist, so schnell wie möglich zurückkehrt.

  • Wenn Sie Microsoft Dynamics 365-Daten in Ihrem eigenen Datenspeicher replizieren, sind Sie für die Sicherheit dieser Daten zuständig. Wenn Sie ein Plug-In zum Senden der Daten verwenden, stellen Sie sicher, dass Sie das Plug-In für die Ausführung nach dem Kernplattformvorgang registrieren. Sicherheitsrechtsüberprüfungen für den angemeldeten Benutzer werden während des Kernplattformvorgangs durchgeführt.

  • Daten, die aus Microsoft Dynamics 365 stammen, sind möglicherweise nicht sicher zum Rendern. Möglicherweise wurden in Daten HTML-Tags eingefügt, die nicht sicher sind.

  • Befolgen Sie die Anforderung, auf Microsoft Dynamics 365-Datenbanken nicht direkt über SQL Server Enterprise Manager zuzugreifen. Das Umgehen des SDK kann zur Gefährdung durch Einschleusen von SQL-Befehlen führen.

  • Bedenken Sie bei Bereitstellungen mit Internetzugriff, dass Ihre Lösung nur so sicher ist wie bei das schwächste Glied. Wenn die Anwendung mit dem Internet verbunden ist, ist sie Sicherheitsrisiken ausgesetzt.

  • Verwenden Sie nur Sprachen, die verwalteten Code generieren, für optimale Sicherheit gegen Pufferüberläufe, Ausnahmen usw.

Weitere Informationen zur Sicherheit finden Sie in folgenden Themen:

Clientseitige Entwicklung

Bewährte Methoden zum Entwickeln von Anpassungen für die Dynamics 365-Webanwendung und Microsoft Dynamics 365 für Outlook enthalten Folgendes:

  • Verwenden Sie Webressourcen anstelle der Seiten, die serverseitige Verarbeitung erfordern, wenn immer möglich. Wenn Ihre Anforderungen nur durch serverseitige Verarbeitung erzielt werden können, befolgen Sie die Anforderung, die benutzerdefinierten Webseiten in einer separaten Website von Microsoft Dynamics 365 zu installieren. Legen Sie die Vertrauensstufe für Ihren Standort entsprechend fest, abhängig von Ihrer Vertrauensstufe in der Sicherheit Ihres Codes. Dadurch wird die Gefährdung durch siteübergreifendes Skripting und weitere Bedrohungen reduziert.

  • Für verbesserte Sicherheit sollten Sie sicherstellen, dass die separate Website unter einem anderen Konto von Microsoft Dynamics 365 ausgeführt wird. Dieses Konto sollte nur über Mindestzugriffsrechte verfügen und keinen Direktzugriff auf die Microsoft-Datenbanken bieten. Sie können ein komplexes Kennwort verwenden, das nicht abläuft, da sich niemand bei diesem Konto anmeldet – nur bei der Anwendung.

  • Vermeiden Sie die Verwendung von ActiveX-Steuerelementen, da sie bekannte Sicherheitsprobleme haben.

  • Berücksichtigen Sie die Einschränkungen von Client-Skripting.Weitere Informationen:Schreiben von Code für Microsoft Dynamics 365-Formulare

  • Verwenden Sie Plug-Ins, um Geschäftslogik zu übernehmen, unabhängig davon, wie die Datenänderungen vorgenommen werden.

  • Verwenden Sie immer ein Bestätigungsdialogfeld, wenn Sie Datensätze löschen oder sensible Änderungen anwenden, wie beispielsweise einer Sicherheitsrolle einen neuen Benutzer hinzuzufügen. Sie können confirmDialog verwenden, um einen Dialog anzuzeigen Dadurch können Techniken vermieden werden, wie beispielsweise Clickjacking oder UI-Redressing, bei denen ein böswilliger Entwickler Ihre Seite in eine scheinbar harmlose Seite einbetten kann, um den Benutzer zum Ausführen von Aktionen zu verleiten, die die Sicherheit beeinträchtigen können, oder zum Ausführen von unerwünschten Aktionen an Daten.

Bewährte Sicherheitsmethoden für Ihre Website beinhalten Folgendes:

  • Verwenden Sie keinen anonymen Zugriff.

  • Verwenden Sie die integrierte Windows-Authentifizierung, NTLM oder Basisauthentifizierung über Transport Layer Security (TLS) oder Secure Sockets Layer (SSL).

  • Verwenden Sie TLS/SSL, um das Senden von unverschlüsselten Daten über das Netzwerk zu vermeiden, wenn sich Ihre Website auf einem anderen Computer als Microsoft Dynamics 365 befindet.

Weitere Informationen finden Sie hier:

Bewährte Methoden zur ISV-Erweiterbarkeit

Einer der Schlüsselgrundsätze der ISV-Erweiterbarkeit ist, dass Sie nicht davon ausgehen sollten, dass Ihre ISV-Lösung die einzige installierte ist. Im Folgenden werden bewährte Methoden zur Befolgung aufgeführt.

Bewährte Methoden für die Verwendung der Microsoft Dynamics 365-Webdienste

Sie sollten die Microsoft Dynamics 365-Webdienst-URLs in eine Konfigurationsdatei stellen, zum Beispiel in eine app.config-Datei, sodass Ihr Code von Änderungen an der URL isoliert ist. Beispielsweise gibt es verschiedene URLs für die drei Microsoft Dynamics 365 (online)-Rechenzentren weltweit.

Wo sollten Plug-Ins und benutzerdefinierte Workflowaktivitäten festgelegt werden?

Für Plug-Ins oder benutzerdefinierte Workflowaktivitäten stellen Sie die Assemblys in den Ordner <installdir>\Server\bin\assembly.

Wo sollten benutzerdefinierte Webanwendungen oder Webseiten untergebracht werden?

Weitere Informationen finden Sie in dem Thema Implementieren Sie einmaliges Anmelden von einer ASPX-Webseite oder IFRAME.

Wie führen Sie ein Plug-In aus, wenn die Rasteransicht der Webanwendung aktualisiert wird?

Registrieren Sie das Plug-In in der Meldungsanforderung RetrieveMultipleRequest und geben Sie keinen Entitätstyp während der Registrierung an.

Wann sollten Sie eine neue Website erstellen?

Erstellen Sie eine neue Website für Ihren Code, wenn einer der folgenden Punkte zutrifft:

  • Die Anwendung muss an eine Domäne, ein Protokoll oder einen Port gebunden sein, die sich von der Microsoft Dynamics 365-Anwendung unterscheiden; oder sie muss in einem anderen Anwendungspool ausgeführt werden.

  • Ihre Anwendung kann eigenständig bestehen und erlaubt eigenständigen Zugriff. Beispielsweise sollte ein Portal, das mit Microsoft Dynamics 365 als Server (mithilfe von Webdiensten) interagiert, als eine neue Website gehostet werden.

  • Ihre Anwendung verwendet immer Active Directory oder die integrierte Windows-Authentifizierung (nicht Bereitstellung mit Internetzugriff (IFD)) und domänenübergreifendes Skripting ist kein Problem. Beispielsweise interagiert Ihre Anwendung mit einem Back-End mithilfe von Webdiensten und interagiert mit Microsoft Dynamics 365-Formularen. Eine Seite, die in einem IFRAME gehostet wird, der in der Microsoft Dynamics 365-Anwendung enthalten ist, die nicht mit dem Microsoft Dynamics 365-Formular interagiert, fällt in diese Kategorie.

Siehe auch

Microsoft Dynamics 365 auf dem Server erweitern
Legt Bitflags fest
Schreiben von Code für Microsoft Dynamics 365-Formulare
Schreiben von Plug-Ins, um Geschäftsprozesse zu erweitern
Benutzerdefinierte Workflowaktivitäten (Workflowassemblys)

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright