Notfallwiederherstellung in Microsoft Dynamics 365 (online)

  • Artikel

 

Veröffentlicht: Januar 2017

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

Die Notfallwiederherstellung ist eine Funktion von Microsoft Dynamics 365 (online), mit der eine Wiederherstellung nach einer geplanten oder ungeplanten Serviceunterbrechung durchgeführt wird. Ein Beispiel für eine geplante Serviceunterbrechung ist die reguläre und regelmäßige Systemwartung in Rechenzentren. Ein Beispiel für eine ungeplante Serviceunterbrechung ist ein Fehler bei einer wichtigen Computersystem- oder Netzwerkkomponente in einem Rechenzentrum. In beiden Fällen haben Sie vorübergehend keinen Zugriff auf die Organisationsdaten und Microsoft Dynamics 365 (online)-Services.

Geplanten Serviceunterbrechungen geht eine öffentliche Bekanntmachung in der Webanwendung oder in Dynamics 365 für Outlook voraus, in der das Datum und die Uhrzeit der Servicewartung angegeben ist, damit Unternehmen sich auf eine Unterbrechung des Zugriffs auf die Organisationsdaten einstellen können. Bei ungeplanten Serviceunterbrechungen wird ein Hinweis angezeigt, dass die Organisation derzeit eine ungeplante Wartung durchführt.

Wenn ein Fehler oder ein Notfall auftritt, werden klar definierte Prozesse von den Administratoren des Microsoft Dynamics 365 (online)-Rechenzentrums angewendet, um eine Wiederherstellung nach einer Serviceunterbrechung durchzuführen. Die Prozesse und Software für die Wiederherstellung nach diesen Serviceunterbrechungen werden als Notfallwiederherstellungs-Failover bezeichnet. Im Microsoft Dynamics 365 (online)-Rechenzentrum werden ein Duplikat und eine synchronisierte (alternative) Kopie der Organisationsdaten auf einem anderen Server aufbewahrt. Sollte im Rechenzentrum ein Notfall auftreten, sodass Sie nicht mehr auf die Daten zugreifen können, können die Administratoren, die das Rechenzentrum überwachen, den Zugriff von der primären Organisation auf die alternative Organisation wechseln, wodurch die Serviceunterbrechung minimiert wird. Wenn der Fehler behoben wurde, kann der Zugriff auf Services der primären Organisation wieder freigegeben werden.

Diese Wiederherstellung wird im Rechenzentrum durchgeführt und für Sie und die verwalteten .NET-Anwendungen transparent gehandhabt. Es gibt jedoch ein Problem, dem Anwendungsentwickler gegenüberstehen: Datenverlust. Wenn in den Microsoft Dynamics 365 (online)-Diensten ein Fehler auftritt, werden Datenänderungsvorgänge, welche die Anwendung mithilfe von Webdienstaufrufen ausführt, möglicherweise nicht ordnungsgemäß abgeschlossen. Dies kann zu Datenverlust führen. In den folgenden Abschnitten in diesem Thema wird beschrieben, wie Sie die Anwendungen schreiben können, damit Datenverlustprobleme behandelt werden.

In diesem Thema

Entwickeln einer .NET-Anwendung mit verwaltetem Code für die Failoverwiederherstellung

Entwickeln einer Nicht-.NET-Anwendung für die Failoverwiederherstellung

Bewährte Methoden

Entwickeln einer .NET-Anwendung mit verwaltetem Code für die Failoverwiederherstellung

Entwickler können die Anwendungen so schreiben, dass sie auf Rechenzentrumsfehler und die Wiederherstellung eingehen, indem sie Code implementieren, der prüft, ob ein Failoverereignis vorliegt, und der dieses ordnungsgemäß handhabt. Eine Anwendung kann die Benachrichtigungsereignisse EndpointSwitched und EndpointSwitchRequired abonnieren. Diese Ereignisse sind auch in abgeleiteten Klassen wie OrganizationServiceProxy verfügbar. Weitere Informationen zu diesen Ereignissen finden Sie in der Dokumentation zur ServiceProxy<TService>-Klasse.

Die Anwendung kann die Eigenschaft EndpointAutoSwitchEnabled überprüfen, um festzustellen, ob automatisches Failoververhalten für eine Organisation aktiviert ist. Diese Eigenschaft wird für Organisationen, in denen ein alternativer Endpunkt für den Failover verfügbar ist, auf wahr festgelegt. In der Anwendung ist kein anderer spezieller Code erforderlich. Benachrichtigungsereignisse können optional abonniert werden, wenn EndpointAutoSwitchEnabled ist wahr.

Typischer Anwendungslogikfluss bei einem Notfallereignis und Fehler

  1. Ein Notfallereignis tritt im Microsoft Dynamics 365 (online)-Rechnungszentrum auf.

  2. Ihre Anwendung führt einen Serviceaufruf über ein Serviceproxyklassen-Objekt durch: OrganizationServiceProxy, DiscoveryServiceProxy.

  3. Das Serviceproxyklassen-Objekt erhält eine Ausnahme, nachdem der Serviceaufruf versucht wurde.

  4. Wenn für die Organisation, an die der Aufruf gerichtet ist, Failover nicht aktiviert ist, fahren Sie mit Schritt 9 fort.

  5. Das EndpointSwitchRequired-Ereignis wird ausgelöst.

  6. Das EndpointSwitched-Ereignis wird ausgelöst.

  7. Das Serviceproxyklassen-Objekt versucht automatisch, den Aufruf erneut durchzuführen.

  8. Wenn der zweite Aufruf erfolgreich war, wird die Anwendung normal fortgesetzt.

  9. Wenn der Aufruf nicht erfolgreich war, wird eine Ausnahme an die Anwendung zurückgegeben: EndpointNotFoundException, TimeoutException, FaultException<OrganizationServiceFault>, wobei fault.Detail.ErrorCode == -2147176347.

Es wird empfohlen, Code zu implementieren, der nach dem Empfang von Endpunktwechsel-Ereignissen eine Prüfung auf möglichen Datenverlust hin durchführt und diesen entsprechend handhabt.

Nachdem der Notfall, der Auswirkungen auf den Endpunkt der primären Organisation hat, im Rechenzentrum behoben wurde, wird ein Failback von der URL des alternativen Endpunkts zur URL des primären Endpunkts für die Organisation als Teil der geplanten Organisationswartung durchgeführt.

Entwickeln einer Nicht-.NET-Anwendung für die Failoverwiederherstellung

Anwendungen, die nicht mit Microsoft Dynamics 365 SDK-Assemblys verknüpft sind, zum Beispiel Java-Anwendungen, die auf Webdienste mithilfe von SOAP oder ODATA zugreifen, können versuchen, auf die Failover-URL für die Zielorganisation zuzugreifen. Die URL für eine alternative Failoverorganisation lautet wie die URL für die primäre Organisation, wobei “--S” zum Organisationsnamen hinzugefügt wird. Beispielsweise würden die primäre URL und die alternative URL für eine Organisation mit dem Namen Contoso wie in der folgenden Tabelle gezeigt lauten.

URL der primären Organisation

URL der alternativen Organisation

https://contoso.api.crm.dynamics.com

https://contoso--s.api.crm.dynamics.com

Für Anwendungen, die nicht mit .NET verbunden sind, gibt es kein Benachrichtigungsereignis, das eine Anwendung abonnieren kann, um über eine Serviceunterbrechung und einen Failover informiert zu werden. Die Anwendung erhält eine Vielzahl von Fehlerausnahmen, wie zuvor aufgeführt, während der Serviceunterbrechung. Zu diesem Zeitpunkt kann die Anwendung versuchen, eine Verbindung zur alternativen Failover-URL für die Zielorganisation herzustellen. Nachdem der Notfall behoben wurde, wird ein Failback zur primären URL für die Organisation als Teil der geplanten Organisationswartung durchgeführt.

Bewährte Methoden

Die folgende Liste enthält einige bewährte Methoden, die Sie in den Anwendungen implementieren können, um einen stabileren Umgang mit Serviceunterbrechungen und Fehlerwiederherstellungen zu ermöglichen.

  • Schreiben Sie einen Anwendungscode für die Prüfung des EndpointAutoSwitchEnabled-Eigenschaftswerts, um festzustellen, ob er auf wahr festgelegt ist. Wenn wahr, sollten Sie die EndpointSwitched und EndpointSwitchRequired Benachrichtigungsereignisse abonnieren.

  • Wenn die Anwendung für wichtige Daten verwendet wird und jeder Datenverlust ein großes Problem darstellt, schreiben Sie Ereignishandlercode, oder erfassen Sie die angegebenen Ausnahmen, um Notfallereignisse und Failover gemäß den Geschäftsanforderungen zu behandeln.

Siehe auch

Verwaltung der Bereitstellung mithilfe des Bereitstellungswebdiensts

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright