Melhores práticas para desenvolvimento com o Microsoft Dynamics CRM 2015
Publicado: novembro de 2016
Aplicável a: Dynamics CRM 2015
Este tópico descreve as práticas recomendadas para personalizar o Atualização do Microsoft Dynamics CRM 2015 e Microsoft Dynamics CRM Online 2015.
Neste tópico
Práticas recomendadas de desempenho
Práticas recomendadas de personalização
Práticas recomendadas de segurança
Práticas recomendadas de extensibilidade ISV
Práticas recomendadas de desempenho
As práticas recomendadas a seguir podem ajudar a escrever o código que funcionar melhor.
Usar vários threads
Adicione suporte de thread ao aplicativo para dividir o trabalho em vários processadores central. Esta sugestão pressupõe que você está executando seu código em um sistema de multiprocessador.Para obter mais informações:Artigo sobre o Guia de desenvolvimento avançado do NET Framework no encadeamento gerenciado.
Permitir que o sistema crie GUIDs
Permitir que o sistema atribui automaticamente o GUID (Id) para você em vez de criar manualmente você mesmo. Esta sugestão permite que o Microsoft Dynamics 365 tire proveito de GUIDs sequenciais, que proporcionam um melhor desempenho do SQL. O seguinte código de exemplo mostra como chamar o método Create para obter o GUID atribuído pelo sistema.
// 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);
Usar tipos de associação precoce
Use a classe Entity quando seu código deverá funcionar em entidades e atributos que não são conhecidos no momento em que o código é escrito. Além disso, se o código personalizado funciona com milhares de registros de entidade, o uso da classe Entity resulta em um desempenho um pouco melhor do que os tipos de entidade de vínculo adiantado. Entretanto, essa flexibilidade tem uma desvantagem porque não é possível verificar nomes de atributo e entidade no tempo de compilação. Se suas entidades já foram definidas na hora do código e a leve degradação de desempenho for aceitável, você deve usar os tipos de vínculo adiantado que podem ser gerados usando a ferramenta CrmSvcUtil.Para obter mais informações:Use classes de entidade de limite antecipado no código
Desabilitar plug-ins
Se possível, desabilite plug-ins registrados antes de executar o aplicativo.
Criar plug-ins que executam mais rápido
Escreva sempre um plug-in que leva o menor tempo para executar sua tarefa. Por exemplo, o método Execute é processado com frequência no Microsoft Dynamics 365. Se você registra um plug-in nessa mensagem, o plug-in pode ter um impacto de desempenho significativo no sistema porque executa sempre que o método Execute é processado, o que acontece com frequência.
Se você pretende registrar os plug-ins para a execução síncrona, é recomendável criá-los para concluir a operação em menos de 10 segundos. É melhor minimizar o tempo de processamento em plug-ins para manter a interatividade de aplicativos clientes que estejam conectados ao mesmo serviço da organização que executa o plug-in.
Limite os dados que você recupera
Quando você usa os métodos que recuperam dados do servidor, recupera a quantidade mínima de dados que seu aplicativo precisa. Você faz isso especificando o conjunto de colunas, que é o conjunto de atributos de entidade a recuperar. Por exemplo, raramente é uma boa ideia recuperar todos os metadados com a mensagem RetrieveAllEntitiesRequest, especificando o filtro de entidade EntityFilters.All para a propriedade EntityFilters. Em vez disso, você pode obter um melhor desempenho se restringir o filtro de entidade ou usar uma destas mensagens: RetrieveEntityRequest, RetrieveOptionSetRequest, RetrieveAttributeRequest ou RetrieveRelationshipRequest.
Limite as operações em cascata para entidades relacionadas
Quando você usa o método Update ou a mensagem UpdateRequest, não define o atributo OwnerId em um registro a menos que o proprietário seja alterado. Quando você define esse atributo, as alterações frequência ficam em cascata para entidades relacionadas, o que aumenta o tempo necessário para a operação de atualização.Para obter mais informações:Comportamento em cascata
Ajuste as configurações de proxy no cliente (somente local)
Um servidor de proxy está situado entre um aplicativo cliente, como um navegador, e o servidor de destino real. Quando um computador está em uma LAN, pode usar um servidor de proxy para se conectar à Internet. Nesse caso, o servidor do proxy é combinado com, ou é uma parte de, o servidor do gateway e servidor do firewall. O proxy pode armazenar solicitações da Web em cache e servir várias solicitações do cliente usando seus dados armazenados em cache. Se os dados solicitados não estiverem presentes no cache do servidor proxy, encaminha a solicitação para o servidor real usando seu próprio endereço IP. Aqui, o servidor proxy atua em nome do computador cliente.
Embora um servidor proxy possa atuar como um servidor cache e possa ajudar a carregar uma página da Web mais rapidamente, às vezes pode reduzir o desempenho se for usado incorretamente. Muitas vezes, as pessoas impedem a configuração de proxy manual e usar a configuração de proxy automática. Este atalho ajuda no balanceamento de carga dos servidores de proxy, mas dependendo da complexidade do script de configuração, um atraso significativo pode ser apresentado quando você usar a configuração de proxy automática.
Quando o servidor do Microsoft Dynamics 365 estiver instalado, você poderá ignorar o servidor do proxy para obter uma melhor produção. O servidor oferece um endereço da Web local que exija o acesso de um proxy. Você pode selecionar Ignorar servidor do proxy para endereços locais e fornecer o nome de domínio totalmente qualificado do servidor do Microsoft Dynamics 365 na lista de exceção. Isso oferece uma melhor produção quando os registros são criados com o SDK do Microsoft Dynamics CRM.
Melhorar o desempenho de alocação do canal de serviço
É possível estabelecer uma conexão com os serviços Web do Microsoft Dynamics 365 e autenticar usuários utilizando as classes do proxy de serviço OrganizationServiceProxy e DiscoveryServiceProxy. Entretanto, o uso impróprio das classes do proxy de serviço às vezes pode reduzir o desempenho do aplicativo. Portanto, se você entender quando e como usar as diferentes classes do cliente que estão disponíveis no SDK, você pode obter um melhor desempenho do aplicativo.
Quando você estabelece um canal de serviço do WCF (Windows Communication Foundation) usando um ponto de extremidade de serviço, por exemplo, usando o serviço Web da organização, seu aplicativo deve executar duas operações demoradas: baixar metadados do ponto de extremidade e autenticação do usuário. Você pode aprimorar o desempenho se o seu aplicativo executar essas operações um número mínimo de vezes para cada sessão do aplicativo. O construtor OrganizationServiceProxy ilustrado aqui realiza essas operações quando um objeto do proxy de serviço é criado.
OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, ClientCredentials deviceCredentials)
Você geralmente obtém melhor desempenho se o aplicativo usa este construtor para criar uma instância do proxy de serviço usando este construtor uma vez durante a sessão do aplicativo e em armazena em cache a referência retornada para uso em diferentes caminhos de código no seu aplicativo. Observe que a referência de serviço retornada não tem thread seguro, portanto aplicativos multi-threaded precisarão alocar uma instância por thread. Aplicativos também devem chamar o Dispose no objeto do proxy de serviço antes de terminarem para poderem liberar os recursos alocados ao canal de serviço.
A classe do proxy de serviço executa o download dos metadados e a autenticação do usuário com os seguintes métodos de classes.
IServiceManagement<IOrganizationService> orgServiceManagement = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(new Uri(organizationUrl))AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials)
O método CreateManagement<TService> executa o download de metadados enquanto o método Authenticate autentica o usuário. Os objetos retornados destes métodos são protegidos por thread e podem ser estaticamente armazenados em cache pelo aplicativo. Você pode usar esses objetos para criar um objeto do proxy de serviço que usa um dos disponíveis construtores.
OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)
Para armazenar em cache o gerenciamento de serviço e os objetos de credenciais autenticados, seu aplicativo pode criar com mais eficiência os objetos do proxy de serviço mais de uma vez por sessão do aplicativo. Se você habilitar tipos de vínculo adiantado no OrganizationServiceProxy com um dos métodos EnableProxyTypes, você deverá fazer o mesmo em todos os proxys de serviço criados do objeto IServiceManagement<TService> armazenado em cache. Se o aplicativo usa os metadados, recomendamos que armazena em cache os metadados que recupera e chama periodicamente a mensagem RetrieveTimestampRequest para determinar se deve atualizar o cache.
Além disso, monitore seu token de segurança do WCF (Token) e atualize antes de vencer para que não perca o token e precise começar de novo com a autenticação. Para verificar o token, crie uma classe personalizada que herde da classe OrganizationServiceProxy ou DiscoveryServiceProxy e que implemente a lógica comercial para verificar o token. Ou envolve as classes de proxy em uma nova classe. Outra técnica é verificar explicitamente o token antes de cada chamada para o serviço da Web. O código de exemplo que mostra essas técnicas pode ser encontrado nas classes ManagedTokenDiscoveryServiceProxy, ManagedTokenOrganizationServiceProxy e AutoRefreshSecurityToken no tópico Código auxiliar: Classe ServerConnection.
Práticas recomendadas de personalização
As seguintes práticas recomendadas podem ajudá-lo a personalizar e estender o Microsoft Dynamics 365.
Práticas recomendadas para o Microsoft Dynamics CRM Online
O download do white paper Padrões e princípios do Microsoft Dynamics CRM Online para construtores de soluções fornece orientações específicas sobre a criação de soluções usando o Microsoft Dynamics CRM Online.
Usando atributos e entidades personalizados
Economize espaço no servidor usando estas técnicas:
Criar atributos personalizados para entidades existentes em vez de criar uma nova entidade.
Renomeie entidades existentes para tornar as entidades mais significativas.
Quando você deverá personalizar uma entidade?
Personalizar uma entidade do sistema, como a entidade de oportunidade, em vez de substituir com uma nova entidade personalizada de modo que você possa usar vários recursos integrados em uma entidade existente. Por exemplo, as entidades de oportunidade e ocorrência têm campos de pesquisa para os clientes associados. Os clientes podem ser contas ou contatos. Não é possível criar uma entidade personalizada que tenha o mesmo tipo de pesquisa. Você pode alterar o nome de exibição de uma entidade do sistema para torná-lo mais significativo para sua empresa.
Quando usar plug-ins em vez do fluxo de trabalho?
Como um desenvolvedor que está interessado em aumentar ou personalizar o Microsoft Dynamics 365, você poderá escolher entre diversos métodos para executar as tarefas. Além de adicionar o código Javascript do cliente para um formulário ou adicionar páginas ASP.NET personalizadas, você pode gravar um plug-in ou criar um fluxo de trabalho personalizado usando a interface da Web que chama uma atividade do fluxo de trabalho personalizado. Como você decidir quando usar um plug-in e quando usar um fluxo de trabalho? A tecnologia que você usa depende da tarefa que você precisa realizar e que será o autor da personalização.
Por exemplo, você deverá usar um fluxo de trabalho em tempo real do plug-in síncrono se deseja executar o código personalizado imediatamente antes ou depois da operação da plataforma principal executar e antes do resultado da operação ser retornado para a plataforma. Você não pode usar um plug-in assíncrono ou fluxo de trabalho assíncrono nesta situação porque eles são enfileirados para executar após a conclusão da operação principal. Portanto, você não pode prever quando eles serão executados. Se quiser adicionar funcionalidade personalizada para o Microsoft Dynamics CRM Online, os fluxos de trabalho e plug-ins são suportados, mas as atividades do fluxo de trabalho personalizado não.
Avalie essas tecnologias e escolha qual a mais adequada para seus objetivos de negócios depois de considerar as dúvidas de implantação, o desempenho e a manutenção da sua solução de plug-in ou fluxo de trabalho.
A tabela a seguir resume os recursos de plug-ins e fluxos de trabalho.
Critérios |
Plug-in |
Fluxo de Trabalho |
|---|---|---|
A execução antes ou depois da operação de plataforma principal (criar, atualizar, excluir, etc.) |
Executa imediatamente antes ou depois da operação principal (síncrona). Também pode ser enfileirado para executar depois da operação principal (assíncrona). |
Os fluxos de trabalho assíncronos também podem ser enfileirados para executar a operação principal. Os fluxos de trabalho em tempo real têm características semelhantes aos plug-ins. |
Impacto de desempenho no servidor |
Os plug-ins síncronos pode aumentar o tempo de resposta da plataforma porque são parte do processamento da plataforma principal. Os plug-ins assíncronos tem menos impacto no tempo de resposta do servidor porque o código é executado em um processo diferente. |
Os fluxos de trabalho assíncronos tem menos impacto no tempo de resposta do servidor porque o código é executado em um processo diferente. Os fluxos de trabalho em tempo real têm características de desempenho semelhantes aos plug-ins de área restrita. |
Restrições de segurança |
Registrar um plug-in com a plataforma exige acesso do direito de acesso Administrador ou Personalizador do Sistema e associação no grupo Administradores de Implantação. |
Os usuários podem criar fluxos de trabalho interativamente no aplicativo Web. Entretanto, para registrar uma atividade de fluxo de trabalho personalizado, a implantação do usuário deve ter os mesmos direitos de acesso que os necessários para registrar plug-ins. |
Suporte da versão do Microsoft Dynamics 365 (SKU) |
Suportado no Microsoft Dynamics CRM Online conforme registrado na área restrita. Pode ser suporte em instalações hospedadas por parceiros sob critério do parceiro. |
Os fluxos de trabalho são suportados por todas as implantações do Dynamics 365. As atividades do fluxo de trabalho personalizado têm suporte na área restrita do Microsoft Dynamics CRM Online e dentro ou fora da área restrita para implantações local/IFD. |
Comprimento do tempo de processamento |
Um plug-in registrado para execução síncrona ou assíncrona é restringido para concluir sua execução em um limite de tempo de dois minutos. |
Funciona bem para processos longos ou curtos. Entretanto, cada atividade em um fluxo de trabalho não pode levar mais de dois minutos para ser concluída. |
Funciona quando o cliente Dynamics CRM para Outlook está offline |
Online e offline são suportados. |
Os fluxos de trabalho não são executados quando offline. |
Persistência de processo e dados |
Os plug-ins executam até serem concluídos. Os plug-ins devem ser gravados para sem monitoração de estado quando nenhum dado de memória é persistido. |
Os fluxos de trabalho assíncronos podem ser pausados, adiados, cancelados e retomados através de chamadas do SDK ou pelo usuário no aplicativo Web. O estado do fluxo de trabalho é salvo automaticamente antes de ser pausado ou adiado. Os fluxos de trabalho em tempo real não podem ter estágios de espera. Eles precisam executar até a conclusão assim como plug-ins. |
Representação |
Os plug-ins podem executar operações de dados em nome de outro usuário do sistema. |
Os fluxos de trabalho assíncronos não podem usar representação, mas os fluxos de trabalho em tempo real podem. Os fluxos de trabalho em tempo real podem executar como o proprietário do fluxo de trabalho ou usuário da chamada. |
Criação |
Os engenheiros de software ou programadores podem criar plug-ins. |
Qualquer pessoa, incluindo um usuário final, analista comercial ou administrador, pode criar fluxos de trabalho se tiverem as permissões apropriadas. |
Não há nenhum impacto de desempenho significativo no servidor entre um plug-in assíncrono e um fluxo de trabalho.
Qual tipo de fluxo de trabalho é melhor?
De uma perspectiva de desempenho, é melhor criar um fluxo de trabalho único longo ou é melhor ter vários fluxos de trabalho secundário e chamá-los em um fluxo de trabalho principal? A abordagem de fluxo de trabalho secundário tem a menor produção, mas é mais gerenciável se você altera com frequência sua definição de fluxo de trabalho. A sobrecarga de compilação não é uma grande preocupação porque o fluxo de trabalho é incorporado apenas durante a publicação. Entretanto, o Microsoft Dynamics 365 tem uma sobrecarga quando inicia cada instância de fluxo de trabalho. A sobrecarga ocorre quando todas as entidades que são usadas no fluxo de trabalho são recuperadas e o fluxo de trabalho secundário é iniciadas em um processo de duas etapas que inclui uma "Tarefa de Expansão do Fluxo de Trabalho” e na instância do fluxo de trabalho real. Portanto, para obter a produção máxima, use um único o fluxo de trabalho.
Como você deve marcar sua atividade do fluxo de trabalho personalizado como concluída?
O valor de retorno do método Execute é usado pelo tempo de execução do fluxo de trabalho para marcar a atividade como "concluída". Você deve usar return base.Execute(executionContext) a menos que a atividade ignore a funcionalidade de classe base. Evite retornar o ActivityExecutionStatus.Closed.Para obter mais informações:Enumeração ActivityExecutionStatus
Como você deve relatar exceções em atividades do fluxo de trabalho personalizado?
Você deve lançar um InvalidPlugInExecutionException no código. Este erro será exibido no formulário da instância do fluxo de trabalho.
Você pode definir as entidades personalizadas que são específicas para unidades de negócios?
As entidades personalizadas têm privilégios para cada direito de acesso, mas não para cada unidade de negócios. Para definir as entidades personalizadas visíveis somente para as unidades de negócios especificadas, você deve criar diferentes direitos de acesso para cada unidade de negócios e conceder privilégios para a entidade personalizada no direito adequado.
Práticas recomendadas de segurança
Siga estas diretrizes para ajudar a proteger seus dados corporativos.
Geral
Práticas recomendadas para proteger sua implementação do Microsoft Dynamics 365 incluem:
Estabelecer um plano de dados de segurança aprovado para a implementação do Microsoft Dynamics 365 da sua organização.
Atribua os privilégios mínimos necessários ao configurar o pool de aplicativos.
Exija que os usuários utilizam senhas fortes para contas. Para obter mais informações, pesquise por “senhas fortes” na Ajuda do Windows.
Para obter mais informações:TechNet: Considerações de segurança sobre o Microsoft Dynamics CRM
Funções, privilégios e direitos de acesso
Práticas recomendadas uso do modelo de segurança do Microsoft Dynamics 365 incluem:
Limite o número de pessoas atribuído à função Administrador do Sistema. Nunca remova essa função.
Crie funções de acordo com as práticas recomendadas de segurança de privilégios mínimos, fornecendo o acesso a quantidade mínima de dados comerciais exigidos para a tarefa. Atribuir usuários ao direito adequado para seu trabalho.
Crie um novo direito com os privilégios específicos e adicione o usuário na nova função se um usuário precisar de mais níveis ou direitos de acesso. Os direitos do usuário são a união de todos os direitos aos quais ele foi atribuído. Não conceda a função original dos privilégios necessários por apenas um ou vários membros.
Use o compartilhamento, quando apropriado, para dar aos usuários direitos específicos em objetos específicos individuais, em vez dos privilégios mais amplos em todos os objetos de um determinado tipo.
Use equipes para criar grupos entre funções de forma que os objetos específicos possam ser compartilhados com a equipe.
Treine os usuários com direitos de acesso de compartilhamento para compartilhar informações mínimas necessárias.
Evite a elevação de privilégio
Os ataques de elevação de ataques de privilégio ocorrem quando um usuário pode assumir os privilégios de uma conta confiável, como um proprietário ou administrador. Sempre execute em contas de usuário com privilégios mínimos e atribua somente as permissões necessárias. Evite usar contas administrativas ou de proprietário para o código de execução. Isso limita a quantidade de dano que pode ocorrer se um ataque tiver êxito. Ao executar tarefas que exigem permissões adicionais, use o procedimento de assinatura ou representação somente pela duração da tarefa.
Implementação do servidor
Práticas recomendadas para desenvolver código do servidor para o Microsoft Dynamics 365 incluem o seguinte:
Não modifique o banco de dados do Microsoft Dynamics 365 por qualquer forma diferente do uso do SDK porque esse procedimento ignora o modelo de segurança do Microsoft Dynamics 365.
Os plug-ins estão em execução no contexto do administrador – você deve saber que esse código pode acessar as informações que o usuário conectado não tem acesso.
Para assemblies de fluxo de trabalho e plug-ins, evite gravar código que leva muito tempo para executar. É importante que o código de plug-in que está registrado para executar sincronizadamente retorna o mais rapidamente possível.
Se estiver replicando dados do Microsoft Dynamics 365 em seu próprio armazenamento de dados, você é responsável pela segurança dos dados. Se você usar um plug-in para transmitir os dados, certifique-se de registrar o plug-in para executar após a operação da plataforma principal. As verificações de privilégio de segurança para o usuário conectado ocorrem durante a operação da plataforma principal.
Os dados que saem do Microsoft Dynamics 365 podem não estar seguros para renderizar. Os dados podem ter sido injetados com marcas HTML que não estão seguras.
Cumpra os requisitos para não acessar os bancos de dados do Microsoft Dynamics 365 diretamente pelo SQL Server Enterprise Manager. Ignorar o SDK pode abrir até ameaças de injeção SQL.
Para implantações voltadas à Internet, lembre-se de que a solução é apenas tão segura quanto o link mais fraco. Depois que o aplicativo for exposto na Internet, é aberto para ameaças de segurança.
Use somente os idiomas que produzem o código gerenciado pela melhor segurança de excesso de armazenamento, exceções, etc.
Para obter mais informações sobre a segurança, consulte os seguintes tópicos:
Desenvolvimento do cliente
Práticas recomendadas para desenvolver personalizações para o aplicativo Web Dynamics 365 e Microsoft Dynamics CRM para Outlook incluem:
Use os recursos da Web em vez de páginas que exijam o processamento do servidor sempre que possível. Se os requisitos podem ser obtidos apenas com o uso do processamento do servidor, cumpra os requisitos que suas páginas da Web personalizadas estão instaladas em um site diferente do Microsoft Dynamics 365. Defina o nível de confiança para o site adequadamente, dependendo do seu nível de confiança na segurança do seu código. Isso reduzirá uma ameaça do script entre sites e outras ameaças.
Para melhor acesso, certifique-se de que seu site separado execute em uma conta diferente do Microsoft Dynamics 365. Essa conta deve ter acesso mínimo possível e não tem acesso direto para os bancos de dados da Microsoft. Você pode usar uma senha complexa que não expire para que ninguém entre nessa conta – somente no seu aplicativo.
Evite o uso dos controles do ActiveX porque eles conheceram problemas de segurança.
Saiba das limitações do script do cliente.Para obter mais informações:Criar códigos para os formulários do Microsoft Dynamics CRM 2015
Use plug-ins para aplicar a lógica comercial independentemente de como as alterações dos dados são feitas.
Sempre use uma caixa de diálogo de confirmação quando excluir registros ou aplicar mudanças privadas, como adicionar um novo usuário a um direito de acesso. Você pode usar o Xrm.Utility.confirmDialog para isso. Isso ajuda a evitar técnicas como o captura de clique ou redirecionamento de IU onde um desenvolvedor malicioso pode inserir sua página em uma página inócua convenientemente para enganar um usuário e executar ações que podem comprometer a segurança ou executar ações indesejadas em dados.
Práticas recomendadas de segurança do seu site incluem:
Não use o acesso anônimo.
Use a autenticação integrada do Windows, NTLM ou autenticação básica no Protocolo SSL.
Use o SSL para evitar o envio de dados não criptografado pela rede se seu site está em um computador diferente do Microsoft Dynamics 365.
Para obter mais informações, consulte:
Práticas recomendadas de extensibilidade ISV
Um dos aspectos fundamentais da extensibilidade ISV é que não é necessário assumir que sua solução ISV é a única instalada. Os itens a seguir são uma lista das práticas recomendadas para acompanhar.
Melhores práticas para o uso dos serviços da web do Microsoft Dynamics CRM
Você deve colocar as URLs de serviço Web do Microsoft Dynamics 365 em um arquivo de configuração, por exemplo, em um arquivo app.config, para que seu código seja isolado das alterações na URL. Por exemplo, há URLs diferentes para os três centros de dados do Microsoft Dynamics CRM Online em todo mundo.
Onde você deve colocar plug-ins e atividades do fluxo de trabalho personalizado?
Para plug-ins no disco ou atividades de fluxo de trabalho personalizado, coloque os assemblies na pasta <installdir>\Server\bin\assembly.
Onde você deve colocar os aplicativos da Web ou páginas da Web personalizados?
Consulte o tópico Implementar o logon único de uma página da Web ASPX ou IFRAME.
Como você executa um plug-in quando a exibição de grade do aplicativo Web é atualizada?
Registre o plug-in na solicitação de mensagens do RetrieveMultipleRequest e não especifique um tipo de entidade durante o registro.
Quando você deverá criar um novo site?
Crie um novo site para o código o seguinte se aplicar:
O aplicativo deve estar associado a um domínio, protocolo ou porta que é diferente do aplicativo Microsoft Dynamics 365; ou deve ser executado em um pool de aplicativos diferente.
O aplicativo pode existir e ser acessado isoladamente. Por exemplo, um portal que interage com o Microsoft Dynamics 365 como servidor (usando serviços Web) deve ser hospedado como um novo site.
Seu aplicativo sempre usa o Active Directory ou a autenticação integrada do Windows (não IFD) e o script entre domínio não é um problema. Por exemplo, seu aplicativo interage com um backend usando serviços Web e interage com os formulários do Microsoft Dynamics 365. Uma página hospedada em um IFRAME que está incluída no aplicativo Microsoft Dynamics 365 que não interage com o formulário do Microsoft Dynamics 365 está nessa categoria.
Confira Também
Crie aplicativos e extensões do servidor
Definir sinalizadores de bit
Criar códigos para os formulários do Microsoft Dynamics CRM 2015
Crie plug-ins para ampliar os processos empresariais
Atividades personalizadas de fluxo de trabalho (assemblies de fluxo de trabalho)
© 2017 Microsoft. Todos os direitos reservados. Direitos autorais