Recuperación de desastres en Microsoft Dynamics 365 (online)
Publicado: enero de 2017
Se aplica a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
La recuperación de desastres es una característica de Microsoft Dynamics 365 (online) para recuperarse de una interrupción de servicio planeada o imprevista. Un ejemplo de una interrupción de servicio planeada es el mantenimiento regular y periódico del sistema de centro de datos. Un ejemplo de una interrupción de servicio imprevista es un error en un sistema del equipo o un componente de red clave en un centro de datos. En cualquiera de los dos casos, se pierde temporalmente el acceso a los datos de la organización y los servicios de Microsoft Dynamics 365 (online).
Las interrupción de servicio planeadas van precedidas de un aviso público en la aplicación web o Dynamics 365 para Outlook que identifica la fecha y la hora del mantenimiento del servicio para que las empresas puedan planificar la interrupción del acceso a los datos de su organización. Las interrupciones de servicio imprevistas se traducen en un aviso que indica que se están realizando labores de mantenimiento imprevistas en la organización.
Cuando se produce un error o un desastre, los administradores del centro de datos de Microsoft Dynamics 365 (online) aplican procesos bien definidos para recuperarse de una interrupción de servicio. Los procesos y el software para recuperarse de estas interrupciones de servicio se denominan conmutación por error de recuperación de desastres. El centro de datos de Microsoft Dynamics 365 (online) mantiene un duplicado y una copia sincronizada (alternativa) de los datos de la organización a un servidor diferente. Si ocurriera un desastre en el centro de datos que impidiera el acceso a los datos, los administradores que controlan el centro de datos pueden cambiar el acceso de la organización primaria a esta organización alternativa, minimizando así la interrupción del servicio. Una vez corregido el error, el acceso del servicio a la organización primaria se puede restaurar.
Esta recuperación sucede en el centro de datos y se administra de forma transparente para usted y sus aplicaciones administradas de .NET. Sin embargo, hay un problema del que deben ocuparse los desarrolladores de aplicaciones: la pérdida de datos. Cuando los servicios de Microsoft Dynamics 365 (online) encuentran un error, es posible que las operaciones de cambio de datos realizadas por la aplicación mediante llamadas a servicios web no se completen correctamente. Esto puede tener como resultado la pérdida de datos. Las siguientes secciones de este tema describen cómo escribir aplicaciones que se ocupen de los problemas de pérdida de datos.
En este tema
Desarrollar una aplicación de código administrado de .NET de recuperación de conmutación por error
Desarrollar una aplicación de código administrado que no sea de .NET de recuperación de conmutación por error
Prácticas recomendadas
Desarrollar una aplicación de código administrado de .NET de recuperación de conmutación por error
Los desarrolladores pueden diseñar sus aplicaciones para que gestionen los errores y la recuperación del centro de datos implementando código que controle un evento de conmutación por error correctamente. Una aplicación puede suscribirse a los eventos de notificación EndpointSwitched y EndpointSwitchRequired. Estos eventos también están disponibles en clases derivadas como OrganizationServiceProxy. Para obtener más información sobre estos eventos, vea la documentación de la clase ServiceProxy<TService>.
La aplicación puede comprobar la propiedad EndpointAutoSwitchEnabled para determinar si se ha habilitado el comportamiento de conmutación por error automática para una organización. Esta propiedad se establece en truepara las organizaciones donde está disponible un extremo alternativo de conmutación por error. No se requiere ningún otro código especial en la aplicación distinto del que permite suscribirse opcionalmente a los eventos de notificación cuando EndpointAutoSwitchEnabled es true.
Típico flujo de la lógica de aplicación de un evento de desastre y una conmutación por error
Un evento de desastre se produce en el centro de datos de Microsoft Dynamics 365 (online).
La aplicación hace una llamada de servicio mediante un objeto de clase de proxy de servicio: OrganizationServiceProxy, DiscoveryServiceProxy.
El objeto de clase de proxy de servicio recibe una excepción después de intentar la llamada de servicio.
Si la organización de destino de la llamada no se ha habilitado para la conmutación por error, vaya al paso 9.
Se genera el evento EndpointSwitchRequired.
Se genera el evento EndpointSwitched.
El objeto de clase de proxy de servicio vuelve a intentar la llamada automáticamente.
Si la segunda llamada se realiza correctamente, la aplicación sigue normalmente.
En caso contrario, se devuelve una excepción a la aplicación: EndpointNotFoundException, TimeoutException, FaultException<OrganizationServiceFault> donde fault.Detail.ErrorCode == -2147176347.
Es posible que desee aplicar código que compruebe la pérdida potencial de datos después de recibir eventos de modificador de extremo y la controle adecuadamente.
Después de corregir el desastre que afecta al extremo de la organización primario en el centro de datos, se produce una conmutación por recuperación desde la dirección URL del extremo alternativo a la dirección URL del extremo primario para la organización como parte del mantenimiento previsto de esta.
Desarrollar una aplicación de código administrado que no sea de .NET de recuperación de conmutación por error
Las aplicaciones que no se vinculan a los ensamblados SDK de Microsoft Dynamics 365, como las aplicaciones Java que tienen acceso a los servicios web mediante SOAP u ODATA, pueden intentar el acceso a la dirección URL de conmutación por error de la organización de destino. La dirección URL de una organización alternativa de conmutación por error es la misma que la dirección URL de la organización principal con la cadena "--s" agregada al nombre de la organización. Por ejemplo, una organización denominada Contoso tendría las direcciones URL principales y alternativas que aparecen en la tabla siguiente.
URL primaria de la organización |
URL secundaria de la organización |
|---|---|
https://contoso.api.crm.dynamics.com |
https://contoso--s.api.crm.dynamics.com |
Para las aplicaciones que no están conectadas con .NET, no hay ningún evento de notificación al que la aplicación puede suscribirse para recibir el aviso de una interrupción en el servicio y una conmutación por error. La aplicación empezará a recibir una variedad de excepciones de error, indicadas anteriormente, durante la interrupción del servicio. En ese momento, la aplicación puede intentar conectarse a la dirección URL alternativa de conmutación por error de la organización de destino. Una vez que se ha corregido el desastre, se produce una conmutación por recuperación a la dirección URL primaria de la organización como parte del mantenimiento previsto de la organización.
Prácticas recomendadas
La siguiente lista describe algunas prácticas recomendadas que puede implementar en las aplicaciones para que estas sean más eficaces al tratar las interrupciones de servicio y la recuperación de errores.
Escriba código de aplicación que compruebe el valor de la propiedad EndpointAutoSwitchEnabled para determinar si se ha establecido en true. Si es true, considere la posibilidad de suscribirse a los eventos de notificación EndpointSwitched y EndpointSwitchRequired.
Si la aplicación trabaja con datos críticos donde cualquier pérdida de datos es desastrosa, escriba código de controlador de eventos o recupere las excepciones indicadas para controlar el evento de desastre y la conmutación por error según corresponda a las necesidades empresariales.
Ver también
Administrar la implementación mediante el servicio web de implementación
Microsoft Dynamics 365
© 2017 Microsoft. Todos los derechos reservados. Copyright