Share via

Bewährte Methoden für die Entwicklung mit Dynamics 365 Customer Engagement

  • Artikel

Dieses Thema beschreibt bewährte Verfahren für die Anpassung von Dynamics 365 for Customer Engagement.

Wichtig

Überprüfen von Unterstützten Erweiterungen für Dynamics 365 Customer Engagement (on-premises), um über die unterstützten und nicht unterstützten Techniken für Anpassung zu erfahren.

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: NET Framework Anleitung für fortgeschrittene Entwicklung Artikel über Managed Threading.

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 Dynamics 365 Customer Engagement (on-premises), 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. Wenn Ihre Entitäten bereits zur Codezeit definiert sind und eine leichte Leistungsverschlechterung akzeptabel ist, sollten Sie die früh gebundenen Typen verwenden, die Sie mit dem Tool CrmSvcUtil generieren können. Weitere Informationen: Verwenden Sie die Early Bound Entity Classes im Code

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 Dynamics 365 Customer Engagement (on-premises) 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 2 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 RetrieveAllEntities mithilfe der RetrieveAllEntitiesRequest-Klasse abzurufen, den All`-Entitätsfilter für die Eigenschaft EntityFilters anzugeben. Stattdessen wird möglicherweise eine bessere Leistung erzielt, wenn Sie den Entitätsfilter einschränken oder eine der folgenden Meldungsanfrageklassen 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.

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: Kaskadierendes Verhalten

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 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 Dynamics 365 Server in der Ausnahmeliste bereitstellen. Dies ergibt einen besseren Durchsatz, wenn Datensätze mithilfe der SDK-Assembys erstellt werden.

Verbessern der Servicekanal-Zuteilungsleistung

Sie können eine Verbindung mit den Dynamics 365 Customer Engagement (on-premises)-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 über einen Service-Endpunkt einrichten, z.B. über den Organization Web Service, muss Ihre Anwendung zwei zeitaufwändige Vorgänge durchführen: den Download von Metadaten vom Endpunkt und die 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 ServiceConfigurationFactory.CreateManagement führt den Download der Metadaten durch, während die Methode Authenticate(AuthenticationCredentials) 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 außerdem Ihr WCF-Sicherheitstoken (Token) und aktualisieren Sie es, bevor es abläuft, damit Sie das Token nicht verlieren und mit der Authentifizierung von vorne 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: ServerConnection-Klasse gefunden werden.

Bewährte Methoden für Anpassungen

Die folgenden bewährten Methoden können hilfreich sein, um Dynamics 365 Customer Engagement (on-premises) anzupassen und zu erweitern.

Bewährte Methoden für Dynamics 365 Customer Engagement (on-premises)

Das Whitepaper Microsoft Dynamics 365 Customer Engagement (on-premises)-Muster und -Prinzipien für Lösungsentwickelnde, das Sie hier herunterladen können, bietet eine Anleitung speziell für die Erstellung von Lösungen mit Dynamics 365 for Customer Engagement.

Verwenden von benutzerdefinierten Entitäten und Attributen

Verwenden Sie immer den Entitätsnamen, um in Abfragen und Code auf Entitäten zu verweisen. Verwenden Sie nicht den Objekttypencode (auch Entitätstyp genannt), da der 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 alle integrierten Funktionen in einer vorhandenen Entität verwenden können.

Verwenden von Plug-Ins oder Workflow?

Als Entwickler, der interessiert ist, Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 for Customer Engagement angepasste Funktionen hinzufügen möchten, werden Workflows, angepasste Workflow-Aktivitäten und Plug-ins unterstützt, angepasste XAML-Workflows jedoch nicht.

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.
Dynamics 365 Customer Engagement (on-premises)-Version Support (SKU) Unterstützt in Dynamics 365 for Customer Engagement, wenn in der Sandbox registriert. Kann in Partner-gehosteten Installationen nach Ermessen des Partners unterstützt werden. Workflows werden von allen Customer Engagement Bereitstellungen unterstützt. Angepasste Workflow-Aktivitäten werden in der Sandbox von Dynamics 365 for Customer Engagement und in oder außerhalb der Sandbox für lokale/IFD-Bereitstellungen 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 for 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 Dynamics 365 Customer Engagement (on-premises) 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 Aufzählung

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 Dynamics 365 Customer Engagement (on-premises) enthalten Folgendes:

  • Richten Sie einen genehmigten Sicherheitsdatenplan für die Dynamics 365 Customer Engagement (on-premises)-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: Sicherheitskonzepte für Dynamics 365 Customer Engagement (on-premises)

Rollen, Rechte und Zugriffsrechte

Bewährte Methoden zum Verwenden des Dynamics 365 Customer Engagement (on-premises)-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 Benutzenden 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 Dynamics 365 Customer Engagement (on-premises) enthalten Folgendes:

  • Ändern Sie niemals die Dynamics 365 Customer Engagement (on-premises)-Datenbank für einen anderen Zweck als die Anwendung des SDK, da dadurch das Dynamics 365 Customer Engagement (on-premises)-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 Dynamics 365 Customer Engagement (on-premises)-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 Dynamics 365 Customer Engagement (on-premises) stammen, sind möglicherweise nicht sicher zum Rendern. Möglicherweise wurden in Daten HTML-Tags eingefügt, die nicht sicher sind.
  • Halten Sie sich an die Vorschrift, nicht direkt über den SQL Server Enterprise Manager auf Dynamics 365 Customer Engagement (on-premises) Datenbanken 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 Verfahren für die Entwicklung von Anpassungen für die Webanwendung Customer Engagement und Dynamics 365 for Outlook umfassen 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 Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 Customer Engagement (on-premises) 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 diese bekannte Sicherheitsprobleme haben.
  • Berücksichtigen Sie die Einschränkungen von Client-Skripting. Weitere Informationen: Bewährte Verfahren: Client Scripting in Customer Engagement
  • 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 openConfirmDialog 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 sintegrierte Windows-Authentifizierung, NTLM oder Basisauthentifizierung zur Transport Layer Security (TLS) oder Secure Sockets Layer (SSL).

  • Verwenden Sie TLS/SSL, um zu vermeiden, dass unverschlüsselte Daten über das Netzwerk gesendet werden, wenn sich Ihre Website auf einem anderen Computer als Dynamics 365 Customer Engagement (on-premises) befindet.

    Weitere Informationen erhalten Sie im folgenden Artikel:

  • [Übersicht über Webanwendungs-Sicherheitsbedrohungen](/previous-versions/f13d73y6(v=vs.140)

  • ASP.NET Sicherheit von Webanwendungen

  • Einführung zur Sicherheit von Webanwendungen

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 Dynamics 365 Customer Engagement-Webdienste

Sie sollten die Dynamics 365 Customer Engagement (on-premises)-Webdienst-URLs in eine Konfigurationsdatei stellen, zum Beispiel in eine app.config-Datei, sodass Ihr Code von Änderungen an der URL isoliert ist. Es gibt zum Beispiel verschiedene URLs für die Rechenzentren von Dynamics 365 for Customer Engagement auf der ganzen Welt.

Wo sollten benutzerdefinierte Webanwendungen oder Webseiten untergebracht werden?

Hinweis zum Thema Implementieren des einmaligen Anmeldens aus 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 Dynamics 365 Customer Engagement (on-premises)-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 Dynamics 365 Customer Engagement (on-premises) als Server (mithilfe von Webdiensten) interagiert, als eine neue Website gehostet werden.
  • Ihre Anwendung verwendet immer Active Directory oder die integrierte Windows-Authentifizierung (nicht IFD) und domänenübergreifendes Scripting ist kein Problem. Beispielsweise interagiert Ihre Anwendung mit einem Back-End mithilfe von Webdiensten und interagiert mit Dynamics 365 Customer Engagement (on-premises) Formularen. Eine Seite, die in einem IFRAME gehostet wird, der in der Dynamics 365 Customer Engagement (on-premises)-Anwendung enthalten ist, die nicht mit dem Dynamics 365 Customer Engagement (on-premises)-Formular interagiert, fällt in diese Kategorie.

Siehe auch

Schreiben von Code für Dynamics 365 Customer Engagement (Webdienste)
Schreiben von Code für Dynamics 365 Customer Engagement (on-premises)-Formulare
Plug-Ins zum Erweitern von Dynamics 365 Customer Engagement (on-premises)
Benutzerdefinierte Workflowaktivitäten (Workflowassemblys)