Compartilhar via

Recuperação de desastres no Microsoft Dynamics 365 (online)

  • Artigo

 

Publicado: janeiro de 2017

Aplicável a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

A recuperação de desastres é um recurso do Microsoft Dynamics 365 (online)para se recuperar de uma interrupção de serviço planejada ou não. Um exemplo de interrupção de serviço planejada é a manutenção do sistema do data center regular e periódica. Um exemplo de interrupção de serviço planejada é uma falha no sistema principal do computador ou no componente de rede de um data center. Em qualquer caso, você perde temporariamente o acesso aos dados da organização e aos serviços do Microsoft Dynamics 365 (online).

As interrupções de serviço planejadas são precedidas por um aviso público no aplicativo Web ou no Dynamics 365 para Outlook, identificando a data e a hora da manutenção de serviço para que as empresas possam se planejar para a interrupção no acesso aos dados da organização. Interrupções de serviço não planejadas resultam em um aviso de que a organização está atualmente passando por manutenção não planejada.

Quando ocorre uma falha ou desastre, processos bem definidos são aplicadas pelos administradores do data center do Microsoft Dynamics 365 (online)para se recuperar de uma interrupção de serviço. Os processos e o software para se recuperar dessas interrupções de serviço são conhecidos como failover de recuperação de desastres. O data center do Microsoft Dynamics 365 (online)mantém uma cópia duplicata e sincronizada (alternativa) dos dados da organização em um servidor diferente. Se ocorrer um desastre no data center em que você não tenha mais acesso aos dados, os administradores que monitoram o data center poderão alternar o acesso da organização principal para essa organização alternativa, minimizando assim a interrupção de serviço. Quando a falha tiver sido corrigida, o acesso de serviço à organização principal poderá ser restaurado.

Essa recuperação ocorre no data center e é tratada de forma transparente para você e para os aplicativos gerenciados .NET. No entanto, há um problema com o qual os desenvolvedores do aplicativo devem lidar: perda de dados. Quando os serviços do Microsoft Dynamics 365 (online)encontram uma falha, as operações de alteração de dados que o aplicativo executa usando chamadas de serviço Web podem não ser concluídas com êxito. Isso pode resultar em perda de dados. As seções a seguir neste tópico descrevem como você pode criar seus aplicativos para lidar com questões de perda de dados.

Neste tópico

Desenvolva um aplicativo de código gerenciado .NET para recuperações de failover

Desenvolva um aplicativo não .NET para recuperações de failover

Melhores práticas

Desenvolva um aplicativo de código gerenciado .NET para recuperações de failover

Os desenvolvedores podem criar aplicativos que lidem com falhas e com a recuperação do data center, implementando o código para verificar e lidar com evento de failover com harmonia. Um aplicativo pode se inscrever em eventos de notificação de EndpointSwitchede de EndpointSwitchRequired. Esses eventos também estão disponíveis em classes derivadas, como OrganizationServiceProxy. Para obter mais informações sobre esses eventos, consulte a documentação de classe do ServiceProxy<TService>.

O aplicativo pode verificar a propriedade EndpointAutoSwitchEnabledpara determinar se o comportamento de failover automático está habilitado para uma organização. Essa propriedade é definida como verdadeirapara organizações em que um ponto de extremidade alternativo de failover esteja disponível. Nenhum outro código especial é necessário no aplicativo além da inscrição opcional nos eventos de notificação quando o EndpointAutoSwitchEnabledfor verdadeiro.

O fluxo de lógica comum do aplicativo é um evento de desastre e failover

  1. Um evento de desastre ocorre no data center do Microsoft Dynamics 365 (online).

  2. O aplicativo faz uma chamada de serviço por meio de um objeto de classe do proxy de serviço: OrganizationServiceProxy, DiscoveryServiceProxy.

  3. O objeto de classe do proxy de serviço recebe uma exceção depois de tentar a chamada de serviço.

  4. Se a organização de destino da chamada não estiver habilitada para failover, vá para a etapa 9.

  5. O evento EndpointSwitchRequiredé emitido.

  6. O evento EndpointSwitchedé emitido.

  7. O objeto de classe do proxy de serviço tenta a chamada automaticamente de novo.

  8. Se a segunda chamada for bem-sucedida, o aplicativo continua normalmente.

  9. Se a chamada não foi bem-sucedida, uma exceção será retornada ao aplicativo: EndpointNotFoundException, TimeoutException, FaultException<OrganizationServiceFault> em que fault.Detail.ErrorCode== -2147176347.

Você pode implementar o código que verifica uma possível perda de dados depois que eventos de alternância do ponto de extremidade são recebidos e tratá-lo adequadamente.

Depois que o desastre que afeta o ponto de extremidade da organização principal tiver sido corrigido, uma falha retornada da URL do ponto de extremidade alternativo para a URL do ponto de extremidade principal da organização ocorre como parte da manutenção da organização planejada.

Desenvolva um aplicativo não .NET para recuperações de failover

Aplicativos que não se vincula aos assemblies SDK do Microsoft Dynamics 365, por exemplo, aplicativos Java que acessam os serviços Web usando SOAP ou ODATA, podem tentar acessar a URL de failover para a organização de destino. A URL para uma organização alternativa de failover é igual à URL da organização principal com “--s” acrescentado ao nome da organização. Por exemplo, uma organização chamada Contoso teria as URLs principal e alternativa mostradas na tabela a seguir.

URL da organização principal

URL da organização alternativa

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

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

Para aplicativos conectados não.NET, não há um evento de notificação em que o aplicativo possa se inscrever para receber aviso de uma interrupção de serviço e de failover. O aplicativo começará a receber diversas exceções de falha, como listadas anteriormente, durante a interrupção de serviço. Nesse ponto, o aplicativo pode tentar se conectar à URL alternativa de failover da organização de destino. Depois que o desastre tiver sido corrigido, uma falha retornada da URL principal da organização ocorre como parte da manutenção da organização planejada.

Melhores práticas

A lista a seguir descreve algumas práticas recomendadas que você pode implementar nos aplicativos para torná-los mais robustos ao lidarem com interrupções de serviço e recuperação de falhas.

  • Crie o código do aplicativo para verificar se o valor de propriedade do EndpointAutoSwitchEnabledestá definido como verdadeiro. Se for verdadeiro, considere se inscrever nos eventos de notificação EndpointSwitchede EndpointSwitchRequired.

  • Se o aplicativo funcionar com dados críticos em que qualquer perda de dados seja desastrosa, crie o código do manipulador de eventos ou capture as exceções indicadas para lidar com o evento de desastre e com o failover, conforme apropriado, para necessidades de negócios.

Confira Também

Administre a implantação usando o serviço Web de implantação

Microsoft Dynamics 365

© 2017 Microsoft. Todos os direitos reservados. Direitos autorais