Dynamics 365 – Agende o upgrade para a versão 9.0 (Online)

Olá pessoal,

Repassando e traduzindo um pouco do que o time da Microsoft publicou há dois atrás (15/01/2018). Desde este dia, podemos agendar quando nossas organizações Online do Dynamics 365 serão atualizadas para a versão 9.0!

A primeira data disponível para que o upgrade ser ativado é dia 20/02/2018, além disso, podemos configurar uma data alternativa, como já era possível nos últimos releases.

Apesar da versão 9.0 trazer várias novidades, poucas coisas devem impactar para aqueles que já está utilizando a versão 8.2, mesmo assim, recomendo a leitura do What’s New. Assim como, atualize primeiramente sua organização em Sandbox, faça os testes e depois agende a atualização em Produção.

Aqui vai o passo a passo para agendar, lembrando que quem for fazer isso, precisa ter perfil de administrador no Administration Center.

Ao abrir a área administrativa do Dynamics no Portal Office, navegue até a aba “Atualizações” (Updates), veja se sua organização está apta para a atualização através da coluna “Status”, se sim, clique em “Agendar sua atualização” (Schedule your update):

Selecione a data preferencial e alternativa para a atualização entrar em vigor:

Verifique o resumo e clique em “Aprovar Atualização” (Approve Update):

Pronto! Atualização agendada!

Bom, é isso, faça seu agendamento, fique preparado e bom Dynamics 365 versão 9.0 para você!

#GoDynamics!

[]’s,

Tiago

Anúncios
Publicado em Dynamics 365 | Marcado com , , , , | Deixe um comentário

Dynamics 365 – Dicas para utilizar Entidades Virtuais

Olá pessoal,

Dando sequência ao post anterior, sobre Entidades Virtuais… Neste post irei colocar algumas dicas e tricks para não termos dores de cabeça!

Para escrever os posts que coloco no blog, sempre procuro criar alguns exemplos para testar alguns cenários e verificar se o que estou escrevendo irá fazer sentido/funcionar. Quando estava fazendo isso acabei encontrando algumas dificuldades. Sendo assim, vou usar este post para dize-las e quem sabe ajudar quem for se aventurar! :)

Antes de irmos as minhas dicas, uma lida no artigo oficial da Microsoft sobre boas práticas para utilizar entidades virtuais, deve ajudar!

Indo aos detalhes e minhas experiências…

  • Chave Primária tem ser do tipo GUID

Infelizmente temos que ter como chave primária um atributo do tipo GUID. Assim é requerido, pois temos que seguir o modelo de dados do Dynamics, onde, toda entidade possui como chave primária um atributo do tipo GUID. Deste modo, a entidade externa deve seguir o modelo, vale lembrar que não adianta tentarmos formatar atributos de diferente tipos de dados ou criamos outras chaves de dados. O que importa é um GUID como chave primária!

  • Atributos não nulos (Nullable = false)

Tome cuidado com atributos que foram declarados no OData como não nulos, quando o atributo é requerido, isso nos obriga a criar o atributo no Dynamics como “Requisitos Comerciais” (business required)

  • Cuidado ao usar grandes conjuntos de dados (datasets)

Use filtros e recupere apenas as colunas que pretende utilizar, isso ajuda quando estamos trabalhando com grande volumes de dados, assim, evitamos que a performance das consultas seja degradada.

Um dica para filtrar os conjunto de dados externos. podemos fazer de duas formas, uma pelo próprio registro da fonte de dados (data source record), mas o que não encontrei nos materiais oficiais seria que podemos filtrar o conjunto de dados na própria view do Dynamics. Deste modo, podemos fazer assim:

Ou simplesmente assim:

Um ponto importante que não pode deixar de ser mencionado é a ordenação, ao contrário dos filtros a única forma de ordernamos os dados é através do registro da fonte de dados, não se esqueça de usar “$” antes da palavra “orderby“:

  • Confirme isso após criar sua entidade virtual

Após criarmos a nossa nova entidade virtual no Dynamics, precisamos realizar algumas checagens, para garantir que os dados externos sejam exibidos no Dynamics.

– Veja o nome externo (external name) e nome da coleção externa (external collection name) são os mesmos quando acessamos o metadata do serviço externo (http://SEU_SERVICO/$metadata):

– Apenas dois atributos serão criados automaticamente quando criamos uma entidade virtual: a chave primária (GUID) e o campo primário (texto). Assim devemos abri-los para informar qual propriedade do OData irá representá-los, através do campo nome externo (external name):

*Muito cuidado com a ortografia, os nomes respeitam letras minúsculas e maiúsculas, assim temos que digitar corretamente!

  • E com vocês, nosso melhor amigo… Plug-in Tracing (rastreamento de plug-in)

Devido o provedor de serviços externos fazer a consulta através de um plugin registrado no Retrieve e RetrieveMultiple, todas consultas que fazemos usando um serviço externo pode ser visualizada nos logs! Caso não tenha isso já habilitado, utilize este link.

Como eu disse no post anterior, as entidades virtuais estão ainda em sua versão 1.0, assim, ainda é difícil de depurar alguns erros que podem ocorrer ao fazermos uso das fonte de dados externas. Com isso, os logs de plugin são a melhor ferramenta para troubleshooting até o momento!

Os erros costumam aparecer da seguinte forma:

Entity could not be retrieved from data source. Please try again or contact your system administrator.

This query is not supported. Please update the query and try again. If the problem persists, contact your Microsoft Dynamics 365 administrator.

Indo no log dos plugins, podemos visualizar com em maior detalhes o que está acontecendo:


Bom, estas foram as dicas que meus testes proporcionaram, espero que ajude você!

[]’s,

Tiago

 

 

Publicado em Dynamics 365 | Marcado com , , , , | Deixe um comentário

Dynamics 365 – Entidades Virtuais

Olá pessoal,

Talvez uma das mais comentadas das novas funcionalidades da versão 9.0 do Dynamics 365 seja as Entidades Virtuais (virtual entities). Irei escrever sobre elas neste post!

As entidades virtuais foram um ótimo achado da Microsoft para lidar em cenários onde precisamos consultar informações de outras fontes de dados (externas ao Dynamics).

Na figura abaixo, embora o Dynamics não possua nenhum dado de fontes externas, ele armazena as fontes de dados e metadados dos serviços que queremos consumir. Com isso, a interface do Dynamics se encarrega de acessar o serviço externo e disponibiliza como algo nativo!  E o melhor… Sem nenhuma linha de código!

 

É claro que ainda temos algumas limitações, mas é o tradicional jeito da Microsoft de fazer as coisas. Introduzem uma funcionalidade, verificam se ela está atendendo o propósito e depois investem pesado na versão 2.0. Mesmo assim, as entidades virtuais já podem nos ajudar bastante!

Não irei entrar no passo a passo de como criar um entidade virtual, pois a Microsoft já fez isso aqui. Porém, vale ressaltar que precisamos de três componentes para utilizar as entidades virtuais:

  • Provedor de dados (data provider) – é o conector (middleware) que possibilita a comunicação entre o Dynamics e a fonte externa. Para não complicar muito, a MS já disponibiliza um provedor para OData v4, com isso, não precisamos nos preocupar se nosso serviço externo já utiliza este protocolo. Caso este não seja o caso, desenvolvedores podem usar o SDK para criar novos provedores;
  • Registro da Fonte de Dados (data source record) – aqui é o onde informamos qual o provedor de dados estamos utilizando, depois dizemos onde estamos requisitando os dados externos, bem como a consulta (query) que queremos fazer;
  • Entidade Virtual (virtual entity) – com o conector e fonte de dados já informados, precisamos definir como visualmente os dados externos serão apresentados no Dynamics, assim, devemos criar um entidade do tipo “Virtual” para criar o modelo de dados da fonte externa (metadados);

Como eu disse anteriormente, ainda temos algumas limitações, aqui vão elas:

  • Os dados externos estão no Dynamics são apenas para consulta (read), assim não podemos criar, editar ou excluir (aqui, temos um grande potencial para a Microsoft investir, se as entidades virtuais já possuem suporte para o OData, não está tão difícil para viabilizar as operações de “push”)
  • Apenas entidades com o perfil de segurança do tipo “Organização” podem ser entidades virtuais
  • O modelo de dados externo tem que ser compatível com o do Dynamics, assim:
    • Entidades externas precisam ter um atributo GUID como chave primária;
    • Atributos devem ter o tipo de dados que o Dynamics possui;
    • Nenhum atributos pode ser campos calculados ou acumulados (rollup);
  • Auditoria e controle de mudanças não são suportados
  • Entidades virtuais não podem ser utilizadas em filas, base de conhecimento, SLAs, detecção de duplicatas, segurança de campos, pequisa relevante (relevant search), portais do Dynamics e relacionamentos Muitos para Muitos (N:N)
  • Cache no modo offiline não é suportado
  • Uma entidade virtual não pode representar uma atividade e não suporta processos de negócio empresariais (business process flows)
  • Uma vez criada uma entidade virtual não podemos altera-la para uma entidade padrão, o mesmo se aplica para uma entidade padrão, uma vez criada, não pode ser alterada para uma virtual

Bom este post termina aqui, vejam que não me aprofundei muito, porém já estou escrevendo outro post para falar um pouco dos resultados de minhas experiências com as entidade virtuais, assim se gosta de conteúdo mais técnico ele será melhor para você! ;)

Para maiores informações:

Get started with virtual entities
Criar e editar entidades virtuais que contenham dados de uma fonte de dados externa
Custom virtual entity data providers
Configuração, requisitos e práticas recomendadas do Provedor de Dados OData v4

 

Publicado em Dynamics 365 | Marcado com , | Deixe um comentário

Dynamics 365 – Gerenciamento de Sessão dos Usuários

Olá pessoal,

Outro curto post. Este será sobre as melhorias na área de segurança contidos na versão 9 do Dynamics 365!

Basicamente, temos duas novas funcionalidades relacionadas as sessões dos usuários, podemos controlar quando as sessões devem ser expiradas (timeout) e também expirar sessões quando não existe atividade por um certo período. Além dos tempos das sessões, podemos emitir um aviso para alertar que logo a sessão irá expirar!

Atenção aos valores máximos e mínimos de cada componente:

  • Tempo máximo de um sessão
    • Min 60 minutos (1 hora)
    • Max 1440 minutos (1 dia)
  • Por quanto tempo antes da sessão expirar por tempo você quer exibir a mensagem de alerta
    • Min 20 minutos
    • Max 1440 minutos (1 dia)
  • Duração da sessão antes de expirar por inatividade
    • Min 5 minutos
    • Max 1440 minutos (1 dia)
  • Por quanto tempo antes da sessão expirar por inatividade você quer exibir a mensagem de alerta
    • Min 1 minuto
    • Max 1440 minutos (1 dia)

Um exemplo de como as mensagens são exibidas:

 

Além destes controles nos quais podemos alterar, o gerenciamento de acesso foi aprimorado, quando a sessão expirar devemos informar novamente as credenciais para uma nova sessão. Cada sessão possui um token para garantir que o mesmo usuário que fez o login é o mesmo que está acessando.

Mais informações em:

Security enhancements: User session and access management

[]’s,

Tiago Cardoso

Publicado em Dynamics 365 | Marcado com , , | 2 Comentários

Dynamics 365 – Consultar entidades relacionadas que não possuem dados entre si (Does Not Contain Data)

00Olá pessoal,

Aqui vai um pequeno post para dizer que na versão 9 do Dynamic 365 ganhamos outra tão aguardada funcionalidade: Consultar registros de entidades relacionadas que não possuem dados entre si, chamado de “Não Contém Dados” (Does Not Contain Data).

Bom, a funcionalidade possibilita algo trivial quando estamos trabalhando com bancos de dados, recuperar dados de entidade relacionadas quando não as chaves do relacionamento não possuem dados. Para ficar um pouco mais claro veja a imagem abaixo, onde temos Contas (accounts) e Contatos (contacts) relacionados através do Contato Primário (Primary Contact):

A nova funcionalidade da localização avançada possibilita, recuperarmos todas Contas que não possuem um Contato Primário! Para isso basta, adicionar o relacionamento e depois selecionar “Não Contém Dados”. Se observar a primeira imagem deste post pode ver na prática como isso é feito!

[]’s,

Tiago Cardoso

Publicado em Dynamics 365 | Marcado com , | Deixe um comentário

Migrações de Dynamics CRM/365 On-premises para Online e vice-versa

Olá pessoal,

Neste post, irei escrever sobre algumas formas e estratégias para planejarmos migrações do Dynamics CRM/365 On-premises para o Online e vice-versa (Online para On-premises).

Um ponto importante para ressaltar antes de começarmos, seria que a ideia do post é de descrever formas de migrar diferentes tipos de implantações (on-premises e online) do Dynamics. Assim, não irei discutir como trabalhar com atualizações do Dynamics, como por exemplo da versão 2013 para 2015.

Vamos ao que interessa…

Dynamics On-premises para Online

Acredito que migração de um Dynamics On-premises para um Online seja a que mais está ocorrendo nos últimos tempos. Muitos mitos foram quebrados e empresas de todos os portes já estão operando com diversos serviços na cloud, o Dynamics não fica de fora dessa e particularmente no Brasil, teve o mercado bem aquecido nós últimos anos, após a Microsoft ter criado o primeiro datacenter dela na América Latina em São Paulo.

Com menos latência e mitos exorcizados, Dynamics On-premises estão indo aos montes para o Online.

Recomendo como leitura o paper oficial da Microsoft (mesmo que ainda não atualizado para as últimas versões, ele possui as etapas fundamentais para a migração).

Basicamente, temos que dividir em duas etapas de migração: Metadata e Dados. Precisamos de ambas etapas para concluir o trabalho, devido ao fato de não podermos exportar o banco de dados e importá-lo no Dynamics Online. Assim, é requerido exportar o Metadata (uma ou mais soluções do Dynamics) e depois carregar os Dados. Vamos aos detalhes:

Metadata

Geralmente precisamos exportar por completo, digo todas as customizações e extensões do Dynamics On-premises para o Online, neste caso, a solução “Padrão” contém o precisamos. Agora, para cenários onde queremos apenas parte das funcionalidades, devemos criar uma ou mais soluções para armazenar as entidades, atributos, formulários, dashboards e etc.

Vale lembrar que todos os plugins precisam ser alterados para funcionar apenas no modo Sandbox, isso é obrigatório no Dynamics Online. Além disso, relatórios precisam ser escritos usando apenas FetchXML. Por fim, alguns workflows talvez precisem de pequenas alterações para continuarem operando Online.

Após termos finalizado o processo acima, é hora de importar a solução no Dynamics Online!

Dados 

Aqui vai a parte complicada, irei detalhá-la da melhor forma possível.

Os dados podem ser uma grande dor de cabeça para serem migrados, principalmente em cenários onde existe um grande volume de dados e a janela para a migração é curta. No paper da Microsoft acima, eles utilizaram o Scribe para acelerar a migração. Porém temos outras ferramentas para nos ajudar, irei falar um pouco sobre cada uma inclusive um pouco mais sobre o Scribe:

  • Assistente de Importação de Dados (importação nativa) – podemos exportar todos dados utilizando a ferramenta nativa do Dynamics e depois reimportá-lo no ambiente Online. A grande vantagem certamente é a facilidade na exportação, pois não é preciso nenhum conhecimento prévio para realizar esta etapa, porém como pontos negativos temos baixa performance no carga de dados e erros de importação se não inserirmos todas as entidades requeridas no conjuntos de dados;
  • Data Migration Tool esta ferramenta está contida dentro do SDK do Dynamics, é bem semelhante ao assistente de importação de dados. Conseguimos criar schemas, exportar e importar dados. Tantos os pontos positivos como negativos são também bem parecidos com o da importação nativa do Dynamics. Assim devemos evitar usá-la quando existe grandes volumes de dados ou alta quantidade de entidades/relacionamentos. Existe um ponto que acredito que faz com que a Data Migration Tool seja melhor do que a importação nativa do Dynamics, a interface exibe mais indicadores do que esta acontecendo durante a importação do que a importação nativa, com isso temos mais recursos para verificar o que já foi carregado, o que está sendo, e quais os problemas encontrados;
  • SQL Integration Services (SSIS) – ferramenta contida no pacote de BI do SQL, podemos criar pacotes para extrair e importar dados. A performance do carregamento de dados é muito melhor do que as duas opções anteriores, conseguimos adicionar componentes de paralelismo e multi-threads. Outro ponto positivo seria que atualmente não existe custo para utilizarmos o SSIS. Com ponto negativo, temos a grande complexidade para criarmos os pacotes, pois não existe um framework para conectar com o Dynamics, tornando o trabalho complexo e por muitas vezes é necessário contar um DBA para facilitar o desenvolvimento;
  • Scribeé uma ferramenta que possui uma série de conectores com diversos tipos de sistemas, com isso podemos trabalhar com dados de diversas fontes dentre elas o Dynamics em uma única plataforma de forma genérica. Em termos de performance no carregamento de dados está no mesmo nível do SSIS, conseguimos importar grandes volumes em pouquíssimo tempo, porém, com o Scribe a complexidade para utilização é bem menor do que o SSIS, muitas funções já estão implementadas, basta apenas usufruir delas e realizar o trabalho. Acredito que o único problema, que nem é bem um problema é o fato do Scribe ser um serviço pago;
  • Kingswaysofto Kingswaysoft é sem dúvida algo o preferido pelos desenvolvedores de Dynamics para a migração de projetos. A curva de aprendizado é ainda menor do que o Scribe, pois utilizamos o SSIS com o framework da Kingswaysoft em forma de add-on. Esta combinação garante um grande conjunto de funções já preparadas para o uso, como por exemplo as conexões com as base de dados, assim a necessidade de codificação é praticamente nula. A performance também pode ser comparada com o Scribe e SSIS, bem como o custo, que é algo de deve ser considerado em sua escolha;

A seguir uma tabela para facilitar o entendimento dos pontos chave de cada ferramenta:

Performance Dificuldade de utilização Custo
Assistente de Importação de Dados Baixa Baixa Gratuito
Data Migration Tool Baixa Baixa Gratuito
SQL Integration Services (SSIS) Alta Alta Gratuito
Scribe Alta Média Pago
Kingswaysoft Alta Média Pago

Existe uma luz no fim do túnel…

A Microsoft vem trabalhando em uma nova ferramenta chamada Customer Engagement Migration Tool para automatizar a migração de Dynamics On-premises para Online, a ideia é seguir algumas etapas de um ajudante de migração, onde vamos informando a base de dados que será utilizada, usuários, o Dynamics Online de destino, entre outros. Além disso, existe uma função que verifica se existe algum problema com as customizações/extensões que irão impactar o novo ambiente. E por fim, a migração se inicia.

Vale lembrar que esta ferramenta por utilizar serviços do Azure, precisa de que o usuário que esteja operando a migração tenha uma licença para isso.

A única parte ruim do Customer Engagement Migration Tool é que infelizmente ainda está em FastTrack, isso significa que não está disponível globalmente e que apenas algumas organizações selecionadas ou que se inscreveram no começo do programa estão tendo acesso a funcionalidade…

Bom ai fica a dica do que irá acontecer em breve. Acredito que empresas parceiras consigam através de seus contatos com o Microsoft algum engajamento para realizar um teste usando o FastTrack se não agora, mas muito em breve.

Dynamics Online para On-premises

Na contramão do que muitos estão fazendo, ir para o modo Online, existem outros que estão voltando para o On-premises. Este fato não é tão ocorrente, mas por algumas vezes se faz necessário. Os motivos para a mudança costumam ser relacionados a nova política de segurança que não permite serviço na nuvem pública, redução de custos e cenários onde a performance ou característica do negócio exigem uma infraestrutura dedicada..

Assim como a migração do On-premises para o Online, também temos um paper da Microsoft (um pouco desatualizado também, mas ajuda bem no que temos que saber).

A migração do modo Online para o On-premises tende a ser bem menos complexa do que a anterior. Apenas precisamos seguir alguns steps, mas não temos problemas para o carregamento de dados.

Seguem os passos:

  • Primeiramente precisamos ter em mente que a versão de Dynamics precisa ser exatamente igual em ambos ambientes (como disse anteriormente, este post não abordará cenários de upgrade de Dynamics). Em alguns casos como no paper acima, quando estamos na versão 2015 Update 1 no modo Online e 2015 no On-premises, a migração pode ser feita, porém funcionalidades da versão mais atual não serão migradas, bem como algumas funcionalidades podem ser impactadas e precisamos realizar alguns procedimentos manuais pré ou pós migração.
  • A chave de criptografia do Dynamics deve ser copiada, precisamos dela para restaurar o banco de dados no novo ambiente.
  • Temos que criar um chamado para a Microsoft, solicitando uma cópia do banco de dados. Quando obtivermos, podemos restaurá-lo em nosso SQL On-premises. Com a restauração concluída, devemos iniciar a importação do Dynamics utilizando o Deployment Manager.
  • Por fim, precisamos ativar a chave de criptografia, com isso nosso Dynamics está pronto para o uso!

Bom, aqui chega o fim deste post, espero que ajuda a tomar algumas decisões para o processo de migração do Dynamics.

[]’s,

Tiago

Publicado em Dynamics 365, Dynamics CRM | Marcado com , , , , | 4 Comentários

Estratégias para projetos de Dynamics CRM/365

Olá pessoal,

Há alguns dias atrás, perguntaram sobre estratégias para trabalhar com projetos de Dynamics.

Bem longe de ser uma pergunta que tenha uma resposta certa ou apenas que tenha uma única resposta. Aqui vai este post com algumas ideias/dicas para cada tipo de projeto (pequeno, intermediário/médio e grande), baseado nas minhas experiências ao longo desses 10 anos de Dynamics que podem ser úteis à VOCÊ!

Como eu disse anteriormente, a forma de categorização de cada tipo de projeto é algo que pode variar bem de organização para organização, além de não ser uma “receita de bolo” que sempre seja possível aplicá-la em todos os cenários, minha ideia neste post é dizer o que já fizemos por onde trabalhei/trabalho.

Antes de aprofundar em cada modelo de trabalho, é necessário de alguma forma padronizar os tipos de projeto. Embora muitas pessoas acreditem que a quantidade de membros da equipe é o fator decisório para aplicarmos o modelo de projeto ideal, por experiência pessoal, descobri que não pode ser o único fator. Assim, o tamanho das equipes devem unir-se a outros dois fatores: concorrência de recursos do Dynamics e grau de complexidade.

Costumamos considerar como equipes pequenas, times de 2 à 5 pessoas, equipes intermediárias/médias de 5 à 10 pessoas e grandes equipes, acima de 10 pessoas. Não usem os números acima como uma regra máxima, e sim como uma base para iniciar a estruturar suas ideias.

A necessidade de utilização dos mesmos recursos do Dynamics por mais do que uma pessoa, é algo em que o Dynamics possibilita nativamente, mas por não bloquear a edição simultânea, acaba abrindo a possibilidade de que uma pessoa interfira no trabalhado da outra.

Um de muitos exemplos sobre isso, seria quando uma pessoa precisa adicionar novos campos na entidade Conta e outra pessoa está criando outros campos no mesmo período, com isso existe uma boa chance de um “atrapalhar o outro”. Por exemplo:

A pessoa A, abre o formulário primeiro, a pessoa B abre o mesmo formulário segundos depois. A pessoa A cria alguns novos campos e adiciona no formulário, salvando e publicando, quando a pessoa B concluir sua tarefa irá acidentalmente remover todos os campos que a pessoa A adicionou no formulário.

Assim, a chances de um projeto de pequeno porte presenciar o exemplo acima é de certa forma baixa, já que é mais fácil evitar a ocorrência – mas não é impossível de ocorrer. Por outro lado, em projetos maiores existe a tendência de presenciar este cenário com mais frequencia.

Para determinarmos o grau de complexidade, é importante notarmos a necessidade de múltiplas fases/módulos de projeto ao mesmo tempo. Por exemplo: um projeto simples é aquele onde temos a equipe inteira trabalhando na mesma fase; um intermediário/médio, 2 pessoas podem estar trabalhando na versão 2.0 e outras 6 dando uma manutenção na versão 1.0; já em um complexo, temos a mesma situação de uma equipe média e ainda dentro da mesma versão temos duas ou mais equipes trabalhando em módulos diferentes.

Bom com a base no raciocínio acima, vamos ao que interessa…

Projetos de pequeno porte

Projetos de pequeno porte podem ser descritos como aqueles onde a equipe é pequena, não existe a necessidade de múltiplas pessoas estarem trabalhando com o mesmo recurso do Dynamics simultaneamente e quando o projeto possui uma única versão e fase/módulo em andamento ao mesmo tempo.

Na minha opinião, existem duas maneiras de trabalhar em projetos de pequeno porte:

  • Única organização de Dynamics com múltiplas pessoas customizando/extendendo ao mesmo tempo, centralização do código fonte para a distribuição (deploy) nos demais ambientes (teste, homologação, produção)

No procedimento acima, em um único ambiente de desenvolvimento é possível ter múltiplas pessoas customizando e extendendo o Dynamics ao mesmo tempo. Já as customizações/extensões são utilizados de forma compartilhada, assim, temos as mudanças em um repositório central para que as distribuições (deploys) no demais ambientes (teste, homologação, produção) sejam extraídas.

Acredito que este seja a opção mais utilizada pela maioria dos projetos, porém ela possui uma série de problemas, quando o projeto não é de pequeno porte, tais como:

  • Os funcionais/desenvolvedores, podem sobrescrever o trabalho um do outro;
  • Entidades e atributos comummente são criados com nomes diferentes, tipo de dados diferentes, alterados e excluídos erroneamente;
  • Quando desenvolvedores estão criando/depurando seus códigos, geralmente impedem de que os demais possam utilizar o mesmo recurso, em alguns casos um ou mais processos de negócio pode ficar indisponíveis neste período ou pararem de funcionar devido a um bug introduzido no desenvolvimento;
  • Se estamos criando a documentação em tempo de projeto, será uma tarefa muito árdua de mante-la atualizada devido ao descontrole das mudanças;

Uma observação importante é que muitas pessoas pensam que apenas as extensões (web resource, plugins, workflows customizados) devem ser mantidas pelo repositório de código, assim, costumam adicionar apenas as soluções do Dynamics no repositório. Porém as customizações (entidades, atributos, processos, etc) podem e devem ser mantidas também no repositório, ferramentas com o Package Deployer e Solution Package ajudam nessa tarefa.

  • Única organização de Dynamics com múltiplas pessoas extendendo ao mesmo tempo, porém apenas uma única pessoa (gatekeeper) irá customizar (entidades, atributos, relacionamentos, processos, direitos de acesso, dashboards, views e etc). Centralização do código fonte para a deploy nos demais ambientes

Acima temos um único ambiente de desenvolvimento com múltiplas pessoas extendendo o Dynamics ao mesmo, porém apenas uma única, o gatekeeper que customiza, deste modo, não temos alguns dos problemas citados na opção anterior. As demais etapas são as mesmas da opção anterior, com o código fonte compartilhado e centralizado, sendo utilizado para a distribuições nos demais ambientes.

Assim o gatekeeper resolve o problema de múltiplas pessoas estarem customizando o Dynamics ao mesmo tempo, porém a concorrência de recursos de extensão continua sendo um problema.

Projetos de médio porte

Projetos de médio porte são aqueles em que a equipe possui mais do que cinco membros, ou equipes pequenas mas que necessitam de múltiplas pessoas trabalhando com o mesmo recurso do Dynamics simultaneamente ou ainda quando o projeto possui mais do que uma única versão ou fase/módulo em andamento ao mesmo tempo.

Assim como os projetos de pequeno porte, acredito que existam duas formas de trabalho:

  • Múltiplas organizações de Dynamics, onde cada membro da equipe possui a sua individual organização ou máquina virtual, podendo customizar/extender. O código fonte é centralizado para o deploy, porém, um gatekeeper irá consolidar todo o trabalho dos membros da equipe em um CRM central (master), realizando uma sequencia de testes para avaliar se nenhuma customizações ou extensão impede que as demais funcionem.

Quando o resultado dos testes é atendido, todas as organizações devem receber a última versão do CRM Central. Esta atividade pode ser executada de diversas formas, manualmente ou automaticamente, mas neste post não irei aprofundar neste assunto. Nesta opção é essencial o uso de Solution Packages!

Todos os problemas que não são resolvidos com o modelo para projetos de pequeno porte são solucionados com este modelo, devido a cada membro da equipe possuir seu ambiente individual. Não existe mais o problema de sobrescrever algo que outra pessoa fez ou ainda quando múltiplas pessoas precisam editar o mesmo componente.

O único ponto negativo neste cenário é a chance das customizações publicadas no repositório não funcionarem adequadamente quando promovidas para o CRM central, principalmente quando precisamos alterar o tipo de dado de um atributo, onde excluímos e recriamos com o novo tipo de dados. Se o CRM central já possuir este atributo com o tipo de dado anterior, a solução não poderá ser importada.

Deste modo, alguns tipos de controle de deploy precisam ser adicionados para garantir a qualidade das soluções, assim, quanto mais controles são adicionados, maior é tempo requerido para manter o modelo operando.

  • Múltiplas organizações de Dynamics, onde cada membro da equipe possui sua organização ou máquina virtual individual, podendo apenas extender o Dynamics. O gatekeeper é o responsável pelas atividades de customização. As demais etapas são as mesmas da opção anterior, como o código centralizado para o deploy, consolidação do trabalho pelo gatekeeper no CRM central e propagação do CRM central para todos os membros da equipe

O modelo acima é o mais preparado para alto índice de customizações e extensões, e que possui um forte sistema de consolidação e distribuição. Além disso, por termos o gatekeeper como o único responsável por realizar as customizações, as chances de problemas com a solução no repositório diminuem drasticamente, reduzindo o tempo para manter o modelo de projeto.

Projetos de grande porte

Projetos de grande porte são aqueles em que a equipe possui muitos membros (mais do que dez membros), ou equipes pequenas e intermediárias mas que necessitam de múltiplas pessoas trabalhando com o mesmo recurso do Dynamics simultaneamente ou ainda, quando o projeto possui mais do que uma versão e fase/módulo em andamento ao mesmo tempo.

Para projetos de grande porte a boa novidade é que podemos implementar o mesmo modelo de projetos de médio porte, porém para cada versão, fase ou módulo do projeto devemos criar um processo adicional.

Por exemplo, o projeto XYZ, esta com uma equipe trabalhando na versão 1.0, outra na versão 2.0 no módulo de vendas e outra equipe também na versão 2.0, mas no módulo de serviços. Assim, cada equipe terá que utilizar o mesmo modelo dos projetos de médio porte. Os projetos irão caminhar de forma independente, assim temos ramificações do projeto (branches). Devido a isso, se faz necessário múltiplos ambientes de desenvolvimento, testes, homologação.

Porém, em algum momento as diferentes frentes de projeto terão que ser consolidadas para termos uma solução final em produção, neste momento, os branches devem ser consolidados, testados em um novo CRM central e por fim aplicados nos demais ambientes e em produção.

Bom, longo post, mais muita coisa tinha que ser mencionada, espero que isso ajude nos seus projetos!

[]’s,

Tiago Cardoso

Publicado em Dynamics 365, Dynamics CRM | Marcado com , | Deixe um comentário

Conjunto de Opções com Multi-opções (Multi-Select Option Set)

Olá pessoal,

Um boa novidade da versão 9.0 (July Release) do Dynamics 365 é a tão esperada possibilidade de termos um conjunto de opções com mais do que uma única opção, ou seja, que permita multi-valores:

Muitos clientes aguardavam ansiosamente por isso, muitas vezes tivemos que extender o Dynamics para proporcionar a mesma funcionalidade ou algo parecido. Mas agora é algo possível. Um novo tipo de atributo chamado “Multi-Select Option Set” (assim que possível, volto com o nome oficial em português) pode ser criado nativamente, da mesma forma que criamos os conjuntos de opções (option set) anteriormente:

A visualização das opções selecionadas também foi desenvolvida, assim fica fácil para sabermos as opções utilizadas, no formulário:


Nas listas/grides:

E nos filtros:

Também podemos fazer consultas avançadas utilizando os multi-valores!

Bom é isso, uma rápida dica!

[]’s,

Tiago

Publicado em Dynamics 365 | Marcado com , , , | Deixe um comentário

Dynamics para Outlook (Outlook add-in/plug-in) não será mais suportado

Olá pessoal,

Uma das notícias mais faladas com a divulgação das funcionalidades da próxima versão do Dynamics (9.0) é o fim ao suporte ao cliente do Dynamics para Outlook (add-in ou plug-in do Dynamics para o Outlook).

Apenas para deixar claro o que estou falando. Atualmente o Dynamics conta com duas ferramentas que podemos utilizar com o Outlook:

  • Dynamics para o Outlook (add-in) – aplicativo cliente do Dynamics que instalamos para integrar o Microsoft Office Outlook com o Dynamics. Temos este aplicativo pelo menos desde a versão 4 do Dynamics (é o primeiro que vem na nossa cabeça quando falamos de Dynamics e Outlook);
  • Dynamics App para o Outlook – é uma app que adicionamos no Outlook para integrarmos ele com o Dynamics. Foi introduzida na versão 2015 do Dynamics e vem ao longo do tempo sendo incrementada com novas funcionalidades;

Vou usar o termo “add-in” para falar do Dynamics para o Outlook e “app” para o Dynamics App para o Outlook.

Após o esclarecimento acima, voltemos a notícia tema do post…

Apesar do “barulho desta notícia ser grande”, vamos a alguns fatos importantes e para esclarecer o que está por vir…

Bom, como já aconteceu anteriormente o fator de depreciar o add-in não significa que ai instalar/atualizar a nova versão do Dynamics automaticamente impedirá o funcionamento do Dynamics no Outlook (UFA!).

Podemos encarar o anuncio como uma “bandeira amarela” que acaba de ser erguida! Pois, quando uma nova atualização majoritária* ocorrer o add-in não funcionará mais.

* Entenda-se como majoritária, a atualização que costuma acontecer uma vez por ano e que realmente altera a versão do Dynamics, como por exemplo da versão 8.1.1 para 9.0.0

Agora temos uma boa notícia para quem não pretende utilizar as versões mais novas do Dynamics. Quem utilizar qualquer versão igual ou inferior a 9.0 (July 2017 Release) continuará utilizando o add-in sem problemas. Em contra partida, nenhuma nova funcionalidade será adicionada, justo não?!

Depois do que já foi dito, vamos ao porque da Microsoft está fazendo isso agora…

Três motivos impulsionaram a decisão:

  • Manutenção/Confiabilidade: Com o grande volume de novas versões e melhorias é bem mais complicado o conceito de um add-in em relação a uma App. O Outlook introduziu este conceito de apps e o Dynamics acompanhou isso criando o Dynamics App para o Outlook. Assim a manutenção dá um grande passo para a nossa atual realidade em TI;
  • Cross plataforma: O add-in apenas funciona em algumas versões do Outlook e apenas para computadores com Windows. Já a app além de funcionar no Outlook (desktop) também funciona na versão Web (Outlook Web App), Outlook para o Mac e Outlook Mobile!
  • Experiência do Usuário (UX): O add-in não apresenta as melhores formas de usabilidade, com isso a experiência do usuário é impactada. Já a app, possui um maior apelo visual e continuará incrementando isso;

Então após tudo o que eu disse, chegamos a conclusão que a app é muito melhor do que o add-in, certo? Bem… quase isso…

A app é ótima, fácil para ser atualizada e mantida, moderna, funciona em várias plataformas diferentes e etc… Porém… Existem ainda algumas funcionalidades que ainda não foram implementadas (este link está se referindo a versão 8.1 do Dynamics, ainda sem as novas funcionalidades da versão 9.0).

Sem entrar muito em detalhes, e indo direto ao ponto. A grande e única desvantagem que vejo como o “calcanhar de Aquiles” da app, é o fato de que ela não funciona OFFLINE! Sim, sabe as 99,99% das vezes que recomendamos o add-in para nossos clientes que por alguns momentos não possui acesso à internet?! A app ainda não pode ser utilizada. O argumento da Microsoft é que conseguimos o acesso offline quando utilizamos o Dynamics 365 para telefones e tablets. Sim, isso é verdade também. Porém, ainda existe uma grande quantidade de pessoas que utilizam o Dynamics apenas em seu modo desktop, com isso a opção cai novamente para o add-in. Por fim, podemos ter ainda outra maneira de manter o modo offline em um desktop/notebook, caso a versão do Windows seja superior a 8, podemos instalar a app do Dynamics e utilizá-la como como se fosse um tablet.

Enfim, por mais que exista um saída para o modo offline, ainda não temos a mesma coisa na app. É um ponto para ser pensado pelos implementadores de Dynamics…

Bom, aqui termina este post. Espero ter ajudado a esclarecer algumas dúvidas!

[]’s,

Tiago

 

Publicado em Dynamics 365, Dynamics CRM | Marcado com , | Deixe um comentário

Dynamics 365 – Documentação

Olá pessoal,

Há alguns dias atrás a Microsoft criou um novo portal para acessarmos a documentação do Dynamics 365.

A ideia foi de agrupar categorias e funcionalidades para facilitar a consulta. O conteúdo dentro de cada link não é novo, mas sim melhor organizado, otimizando nosso tempo quando estamos procurando algo!

Não se esqueça que temos todas as aplicações do Dynamics lá, assim, nosso CRM e AX estão lá com seus novos nomes, bem como todas as novas aplicações.

Para acessar é simples, clique AQUI!

[]’s,

Tiago

Publicado em Dynamics 365, Microsoft | Marcado com , | 2 Comentários