Abordagens de migração para o BizTalk Server para Aplicativos Lógicos do Azure
Este guia aborda estratégias e recursos de migração, acompanhado de considerações de planejamento e melhores práticas para ajudar você a fornecer soluções de migração bem-sucedidas.
Observação
Para obter uma visão geral da migração e um guia para escolher serviços no Azure para sua migração, confira a seguinte documentação:
Opções de estratégia
As seções a seguir descrevem várias estratégias de migração, juntamente com seus benefícios e desvantagens:
Big bang
Uma abordagem "big bang" ou "alteração direta" é uma abordagem que exige muito planejamento e não é recomendada para as organizações que não estão familiarizadas com os Aplicativos Lógicos do Azure ou que têm grandes sistemas ou soluções para migrar. Quando uma organização implementa uma nova pilha de tecnologia, como resultado, costumam ocorrer novos aprendizados. Ao investir muito cedo ou em excesso, você não terá a oportunidade de se beneficiar das lições aprendidas e ajustá-las sem arriscar um retrabalho significativo.
Essa abordagem também pode levar mais tempo para gerar ou acumular valor. Se você já concluiu algumas atividades de migração, mas ainda não as liberou para produção devido a outros trabalhos pendentes ou em andamento, seus artefatos migrados não estão gerando valor para sua organização.
Recomendamos que você considere essa abordagem somente se tiver cargas de trabalho BizTalk pequenas e de baixa complexidade, SMEs (especialistas em assunto) que conheçam seu ambiente BizTalk e mapeamentos diretos entre os recursos do BizTalk que você usa atualmente e os Aplicativos Lógicos do Azure. A experiência com os Aplicativos Lógicos do Azure também reduz consideravelmente os riscos ao seguir essa abordagem.
Iterativo ou baseado em onda (recomendado)
Essa abordagem oferece a oportunidade para que a sua organização obtenha valor de maneira incremental, porém, mais antecipadamente do que de outras formas. Sua equipe de projeto pode aprender sobre a pilha de tecnologia antecipadamente usando retrospectivas. Por exemplo, você pode implantar uma interface ou um projeto do BizTalk existente em produção e aprender sobre as necessidades da solução, que incluem gerenciamento, escalabilidade, operações e monitoramento. Depois de obter esse conhecimento, você pode planejar sprints para otimizar as funcionalidades existentes ou introduzir novos padrões que podem ser usados posteriormente em trabalhos futuros.
Independentemente da abordagem, se você pretende migrar para os Aplicativos Lógicos do Azure ou o Azure em geral, considere a possibilidade de refatorar suas soluções do BizTalk Server em soluções nativas de nuvem ou sem servidor antes de desativar a infraestrutura de servidor. Essa opção é uma excelente estratégia se a sua organização deseja transformar os negócios completamente na nuvem.
O BizTalk Server e os Aplicativos Lógicos do Azure têm arquiteturas diferentes. Para modernizar ainda mais suas soluções, você pode usar os Serviços de integração do Azure para estender os recursos dos Aplicativos Lógicos do Azure que atendem às principais necessidades de integração do cliente.
Para obter um ROI (retorno sobre o investimento) mais alto, recomendamos que qualquer migração BizTalk use os principais recursos nativos nos Aplicativos Lógicos do Azure (Standard) o máximo possível e estendido com outros Serviços de Integração do Azure, conforme necessário. Essa combinação possibilita cenários adicionais, por exemplo:
- Recursos híbridos nativos de nuvem com Aplicativos Lógicos do Azure (Standard) com implantação híbrida
- Recursos de fluxo de trabalho com estado ou sem estado nos Aplicativos Lógicos do Azure (Standard)
- Integração de mainframe e intervalos nativos (no aplicativo) com conectores nos Aplicativos Lógicos do Azure (Standard)
- Mensagens pub-sub usando o Barramento de Serviço do Azure
- Funcionalidades avançadas de SOAP no Gerenciamento de API do Azure
Entregar um projeto de migração do BizTalk
Para concluir esse projeto, recomendamos que você siga a abordagem iterativa ou baseada em ondas e use o processo de Scrum. Embora o Scrum não inclua um conceito Sprint Zero (Sprint 0) para atividades pré-sprint, recomendamos que você concentre seu primeiro sprint no alinhamento da equipe e na descoberta técnica. Após o Sprint 0, siga a execução de vários sprints de migração e concentre-se em liberar recursos para um MVP (produto mínimo viável).
Sprint 0
Durante esse sprint, recomendamos que você execute a Descoberta de Ambientes do BizTalk Server com o Planejamento de Ondas. Entender a amplitude e a profundidade do projeto é fundamental para o sucesso. A lista a seguir inclui as áreas específicas a serem abordadas durante o Sprint 0:
| Área | Descrição |
|---|---|
| Descoberta | Capture dados sobre todas as interfaces e os aplicativos para que você possa saber o número de interfaces e aplicativos necessários para migração. Você também precisa atribuir complexidade a cada interface ou processo. Durante esse processo de catalogação, colete as seguintes informações para priorizar o trabalho: – Adaptadores em uso – Recursos do BizTalk Server em uso, como Monitoramento de Atividades Comerciais, Mecanismo de regras de negócio, EDI etc. – Código personalizado, como expressões, mapas e componentes de pipeline – Taxa de transferência das mensagens – Tamanhos das mensagens – Dependências – Dependências do aplicativo e do sistema |
| Projeto de arquitetura | Crie a arquitetura de alto nível a ser usada como o ponto focal para a migração. Esse design inclui elementos que abordam necessidades funcionais e não funcionais de alto nível. |
| Definição mínima de produto viável (MVP) | Defina os recursos da primeira onda. Em outras palavras, os processos que precisam de suporte após a conclusão da primeira onda. |
| Lista de pendências de migração inicial | Defina os recursos da primeira onda e seus itens de trabalho com a elaboração técnica. |
Ferramentas de descoberta
Para ajudá-lo com a descoberta da migração, você pode usar a ferramenta de linha de comando do Migrador de Integração do Azure, também chamada de ferramenta BizTalk Migration, que é um projeto de software livre da Microsoft. Essa ferramenta usa uma abordagem em fases para ajudá-lo a descobrir insights e estratégias úteis para migrar suas soluções para a nuvem. É recomendável usar a ferramenta migradora somente para descoberta e geração de relatórios. Talvez você também queira considerar o uso de outros produtos para descoberta de parceiros que fornecem soluções nesse espaço.
Para outra maneira de gerar um inventário com elementos do BizTalk Server, você pode usar o BizTalk Documenter, que é desenvolvido por Mark Brimble. Essa ferramenta funciona com o BizTalk Server 2020, apesar de afirmar que apenas o BizTalk Server 2016 tem suporte.
Projeto de arquitetura
Embora os Aplicativos Lógicos do Azure forneçam recursos que permitem reutilizar ativos do BizTalk Server, você deve ter um design de arquitetura moderna para adotar os benefícios de recursos mais modernos. Do ponto de vista funcional, use a lógica de negócios o máximo possível. Do ponto de vista da modernização do produto, use os Serviços de integração do Azure o máximo possível. Para questões de qualidade e de corte cruzado, recomendamos que você use o Azure Well-Architected Framework.
Nessa estrutura, as migrações BizTalk são cargas de trabalho críticas. Este termo descreve coleções de recursos de aplicativo que exigem alta disponibilidade na plataforma, o que significa que eles devem estar sempre disponíveis, operacionais e resilientes a falhas.
Para concluir o design de arquitetura para a migração do BizTalk, siga Criar metodologia para cargas de trabalho críticas no Azure. Para obter uma arquitetura e topologia iniciais, examine e use a arquitetura de referência descrita na integração corporativa básica no Azure no Centro de Arquitetura do Azure.
Para configurar seu ambiente inicial, use o Acelerador de Zona de Destino dos Serviços de Integração do Azure, destinado à criação e implantação de uma plataforma de integração usando um design de zona de destino empresarial típico.
Definição mínima de MVP (projeto viável)
Um MVP é uma versão do produto que tem recursos suficientes para utilizadas pelo cliente. Esta versão mostra as possibilidades e o potencial do produto para coletar comentários do cliente e continuar o trabalho. Para uma migração BizTalk, sua definição de MVP reflete as iterações, ondas ou grupos de sprints que você precisa para progredir para recursos de trabalho e atender às cargas de trabalho de integração iniciais.
Recomendamos que sua definição de MVP inclua os seguintes resultados de negócios, que são expressos como Epics na terminologia do Scrum:
Resultados de negócios (Epics)
- Qual é o objetivo principal que você deseja alcançar?
- Quais recursos ou recursos você deve abordar para este MVP?
- Quais são os fluxos de processo de negócios? Essa pergunta oferece a oportunidade de otimizar os processos existentes compatíveis com o BizTalk Server.
- Quais são as decisões de negócios, por exemplo, resultados de negócios que afetam o MVP ou qual é a disponibilidade de recursos?
Recomendamos que seu MVP inclua os seguintes processos no escopo, que são expressos como Recursos na terminologia do Scrum:
Processos no escopo (recursos)
| Recurso | Descrição |
|---|---|
| Funcionalidade de sistema de alto nível | Você pode extrair essas informações usando as ferramentas de descoberta e expressar as descrições em termos de recursos. |
| Atores ou personas | Use essas informações para determinar os indivíduos afetados pelos cenários com suporte do MVP. |
| Orquestrações | Você pode extrair essas informações usando as ferramentas de descoberta. |
| Entidades de dados e mensagens | Esses elementos oferecem uma oportunidade de saber se você pode incluir melhorias adicionais nos dados trocados pelo ambiente do BizTalk Server. |
| Mapeamentos de dados | O mundo de hoje depende do JSON. No entanto, o BizTalk Server usa XML. Este momento é uma ótima oportunidade para decidir o formato de dados e as necessidades de conversão para a nova plataforma. |
| Regras de negócios | Essas regras centradas em dados abrem uma oportunidade para você repensar sua abordagem ou reutilizá-las empregando recursos dos Aplicativos Lógicos do Azure. |
| Considerações sobre privacidade de dados | Você deve tornar a privacidade uma prioridade máxima. A menos que seu cliente escolha o modelo de implantação híbrida nos Aplicativos Lógicos do Azure (Standard), você deve abordar essa área em cada onda devido a possíveis alterações no ambiente de implantação. |
| Considerações regulatórias | Esse aspecto será mais relevante se os clientes não tiverem cargas de trabalho baseadas em nuvem. |
| Proteger por design | Você deve projetar cada recurso com segurança em mente. |
| Recursos propostos para coexistência | Quando você entrega cada onda, tem um certo grau de coexistência. Você deve alinhar essa arquitetura híbrida com SLIs (Indicadores de Nível de Serviço) e SLOs (Objetivos de Nível de Serviço) existentes. |
| Considerações não funcionais | Os processos empresariais podem ter requisitos não funcionais diferentes. Nem tudo deve acontecer em tempo real. Por outro lado, nem tudo é um processo em lote. |
| Métricas de negócios | Uma oportunidade opcional para mostrar o progresso do trabalho de migração. |
Você também desejará identificar e listar as muitas variáveis fora do escopo que moldam o escopo do seu trabalho de MVP, por exemplo:
- Disponibilidade do recurso
- Riscos
- Documentação
- Tempo para comercialização
Pendências iniciais
O backlog inicial é um conjunto de Histórias de Usuário, que você agrupa em Recursos para criar os processos no escopo para seu MVP. Em outras palavras, um MVP é representado por itens do Scrum conhecidos como Epics, Recursos e Histórias de Usuário. O ideal é que cada Epic englobe um grupo de aplicativos BizTalk ou projetos BizTalk. Você pode usar a regra simples que associa um aplicativo BizTalk ou projeto BizTalk a um recurso.
Por exemplo, suponha que você tenha um projeto do BizTalk Server com uma orquestração chamada "LoanRequests" que os clientes usam para solicitar empréstimos bancários. Portanto, você tem o seguinte recurso proposto e a história de usuário:
Recursos: Processamento de empréstimo
História de Usuário: "Como cliente, quero enviar um aplicativo de empréstimo para que o banco possa adicionar fundos à minha conta segura."
Esta história de usuário, que atualmente pode existir como uma implementação no BizTalk Server, tem as seguintes tarefas a serem implementadas usando os Aplicativos Lógicos do Azure e os Serviços de integração do Azure:
- Colete artefatos reutilizáveis do BizTalk.
- Crie um fluxo de trabalho de solicitação de empréstimo usando os Aplicativos Lógicos do Azure.
- Configure mensagens assíncronas usando o Barramento de Serviço do Azure ou o IBM MQ.
- Mapear dados JSON para XML usando um fluxo de trabalho dos Aplicativos Lógicos do Azure.
- Personalize os Serviços de Integração do Azure conforme necessário para padrões de mensagens.
O diagrama a seguir mostra as durações sugeridas para Epics, Recursos, Histórias de Usuário e Tarefas, que subdividem histórias de usuário. Embora as decisões de implementação afetem essas durações, elas pressupõem que você esteja usando artefatos BizTalk existentes nos Aplicativos Lógicos do Azure. Crie seus fluxos de trabalho Standard usando os modelos de fluxo de trabalho predefinidos o máximo possível.
Ondas de migração (Sprints)
Depois que sua equipe concluir o Sprint 0, você deverá ter uma visão clara do MVP a ser criado. Uma onda é um conjunto de sprints. Sua lista de pendências inicial deve incluir itens de trabalho que seguem o próximo diagrama o máximo possível:
Durante uma onda, sua equipe conclui as atividades para migrar, testar e liberar para produção. Vamos examinar mais de perto o que acontece em cada onda.
Migrações
Durante cada onda, a migração se concentra nas Histórias de Usuário acordadas. Para a primeira onda, sua equipe se concentra no backlog inicial. As decisões de tecnologia devem usar as informações no mapeamento de recursos do BizTalk Server, descrito pelo Confronto de recursos – Por que migrar do BizTalk Server para os Aplicativos Lógicos do Azure?
O diagrama a seguir mostra os eventos que devem ocorrer durante as ondas de migração:
| Etapa | Descrição |
|---|---|
| 1 | Descubra aplicativos e interfaces BizTalk existentes. Embora introduzida no Sprint 0, essa atividade deve acontecer quando cada onda é iniciada. Os clientes podem continuar fazendo alterações em seu ambiente BizTalk. Recursos: - Ferramenta BizTalk Migration - Ferramenta BizTalk Documenter |
| 2 | Configure seu ambiente de migração inicial. Você pode usar o Acelerador de Zona de Destino dos Serviços de Integração do Azure, que é uma estrutura de adoção de nuvem para criar e implantar uma plataforma de integração com um design típico de zona de destino empresarial. Como proprietário da carga de trabalho, você pode alcançar com confiança seu estado técnico de destino usando as diretrizes de arquitetura fornecidas e os recursos de migração do BizTalk. Para obter uma arquitetura de exemplo, consulte Exemplo de ambiente de migração. |
| 3 | Crie e teste fluxos de trabalho do aplicativo lógico Standard que são executados em Aplicativos Lógicos do Azure de locatário único usando o portal do Azure ou o Visual Studio Code com a extensão dos Aplicativos Lógicos do Azure (Standard). Com o Visual Studio Code, você pode desenvolver, testar e armazenar localmente seu projeto de aplicativo lógico usando qualquer sistema de controle do código-fonte. Para saber mais, confira a seguinte documentação: - Criar um exemplo de fluxo de trabalho de aplicativo lógico Standard usando o portal do Azure - Criar um exemplo de fluxo de trabalho do aplicativo lógico Standard usando o Visual Studio Code Para obter um diagrama que mostra um exemplo de aplicativo lógico e conexões, consulte o Ambiente de migração de exemplo. |
| 4 | Para obter todos os benefícios da implantação fácil e consistente de seus fluxos de trabalho do aplicativo lógico Standard em diferentes ambientes e plataformas, você também deve automatizar seu processo de compilação e implantação. A extensão Aplicativos Lógicos do Azure (Standard) para Visual Studio Code fornece ferramentas para você criar e manter processos automatizados de build e implantação usando o Azure DevOps. Para mais informações, consulte Automatizar a compilação e implantação para fluxos de trabalho do aplicativo lógico Standard com o Azure DevOps. |
| 5 | Para implantar aplicativos lógicos críticos Standard que estão sempre disponíveis e responsivos, mesmo durante atualizações ou manutenção, habilite a implantação de tempo de inatividade zero criando e usando slots de implantação. O tempo de inatividade zero significa que, quando você implanta novas versões do seu aplicativo, os usuários finais não devem experimentar interrupção ou tempo de inatividade. Para mais informações, consulte Configurar slots de implantação para habilitar a implantação de tempo de inatividade zero nos Aplicativos Lógicos do Azure. |
O diagrama a seguir mostra um ambiente de migração inicial de exemplo com um aplicativo lógico Standard que orquestra fluxos de trabalho que se comunicam com APIs, serviços, soluções híbridas e recursos locais:
Teste
Cada onda tem suas próprias atividades de teste, que são inseridas em cada História de Usuário. Se você quiser usar o teste shift-left, certifique-se de concluir as seguintes tarefas:
Automatize seus testes.
Os Aplicativos Lógicos do Azure (Standard) incluem a capacidade de executar testes automatizados. A seguinte lista inclui mais informações e recursos disponíveis gratuitamente no GitHub:
Teste automatizado com os Aplicativos Lógicos do Azure (Standard) da equipe dos Aplicativos Lógicos do Azure
Com os Aplicativos Lógicos do Azure (Standard), o teste automatizado deixou de ser difícil de executar devido à arquitetura subjacente, que se baseia no runtime do Azure Functions e pode ser executado em qualquer lugar que o Azure Functions possa ser executado. Você pode escrever testes para fluxos de trabalho executados localmente ou em um pipeline de CI/CD. Para obter mais informações, confira o projeto de exemplo para a Estrutura de teste dos Aplicativos Lógicos do Azure.
Esta estrutura de teste inclui as seguintes funcionalidades:
- Escreva testes automatizados para a funcionalidade de ponta a ponta nos Aplicativos Lógicos do Azure.
- Execute a validação refinada nos níveis de execução e ação do fluxo de trabalho.
- Verifique os testes em um repositório Git e execute-os localmente ou em pipelines de CI/CD.
- Simule funcionalidades de teste para ações HTTP e conectores do Azure.
- Configure testes para usar valores de configuração diferentes da produção.
Guia Estratégico de Integração: Teste padrão dos Aplicativos Lógicos de Michael Stephenson, Microsoft MVP
A estrutura de teste do Guia Estratégico de Integração baseia-se na estrutura de teste fornecida pela Microsoft e dá suporte a cenários adicionais:
- Conecte-se a um fluxo de trabalho em um aplicativo lógico Standard.
- Obtenha a URL de retorno de chamada para que você possa disparar o fluxo de trabalho de um teste.
- Verifique os resultados da execução do fluxo de trabalho.
- Verifique as entradas e as saídas da operação do histórico de execuções do fluxo de trabalho.
- Conecte-se a estruturas de teste automatizado que podem ser usadas pelos desenvolvedores de aplicativos lógicos.
- Conecte-se ao SpecFlow para dar suporte ao BDD (desenvolvimento controlado por comportamento) de aplicativos lógicos.
Independentemente das abordagens de automação ou dos recursos usados, você está prestes a obter testes de integração automatizados, repetíveis e consistentes.
Configure testes de resposta fictícios usando resultados estáticos.
Independentemente da configuração de testes automatizados, você pode usar a funcionalidade de resultados estáticos dos Aplicativos Lógicos do Azure para definir temporariamente respostas simuladas na ação. Essa funcionalidade permite emular o comportamento de um sistema específico que você deseja chamar. Em seguida, você pode executar alguns testes iniciais isoladamente e reduzir o volume de dados que criará em sistemas de linha de negócios.
Execute testes lado a lado.
O ideal é que você já tenha testes de integração de linha de base para seu ambiente do BizTalk Server e testes automatizados estabelecidos para os Aplicativos Lógicos do Azure. Em seguida, você pode executar testes lado a lado de uma forma que ajude a verificar as interfaces usando os mesmos conjuntos de dados e aprimore a precisão geral do teste.
Versão para produção
Depois que sua equipe terminar e atender à "definição de concluído" para as Histórias de Usuário, considere as seguintes tarefas:
Crie um plano de comunicação para sua versão para produção.
Crie um plano de "substituição".
Um plano de substituição aborda os detalhes sobre as tarefas e as atividades necessárias para mudar da plataforma atual para a nova plataforma, incluindo as etapas que a equipe planeja executar. Inclua as seguintes considerações no plano de substituição:
- Etapas de pré-requisito
- Ensaio geral
- Pessoas
- Agendar as estimativas
- Como desabilitar as interfaces na plataforma antiga
- Como habilitar as interfaces na nova plataforma
- Teste de validação
Determine um plano de reversão.
Execute testes de validação.
Planeje operações ou suporte de produção.
Escolha critérios de "aprovar ou não aprovar" para liberar para produção.
Comemore o sucesso da sua equipe.
Faça uma retrospectiva.
Práticas recomendadas para uma migração BizTalk
Embora as melhores práticas possam variar entre as organizações, considere um esforço consciente para promover a consistência, o que ajuda a reduzir os esforços desnecessários que "reinventam a roda" e a redundância de componentes comuns semelhantes. Quando você ajuda a habilitar a reutilização, sua organização pode criar interfaces mais rapidamente que se tornam mais fáceis de dar suporte. O tempo de comercialização é um dos principais habilitadores para a transformação digital. Portanto, uma prioridade máxima é reduzir o atrito desnecessário entre os desenvolvedores e as equipes de suporte.
Ao estabelecer suas melhores práticas, considere a possibilidade de alinhá-las com as seguintes diretrizes:
Convenções de nomenclatura gerais para recursos do Azure
Configure e aplique de maneira consistente boas convenções de nomenclatura em todos os recursos do Azure de grupos de recursos para cada tipo de recurso. Para estabelecer uma base sólida para a capacidade de descoberta e suporte, uma boa convenção de nomenclatura comunica a finalidade. O ponto mais importante das convenções de nomenclatura é que você as tem e que a sua organização as entende. Cada organização tem nuances que talvez precisem ser levados em conta.
Para obter diretrizes sobre essa prática, confira as seguintes recomendações e recursos da Microsoft:
- Exemplos de abreviação para recursos do Azure
- A Ferramenta de Nomenclatura do Azure, que gera nomes em conformidade com o Azure, ajuda a padronizar os nomes e automatiza o processo de nomenclatura.
Convenções de nomenclatura para recursos dos Aplicativos Lógicos do Azure
O design do seu aplicativo lógico e do fluxo de trabalho fornece um ponto de partida importante porque essa área fornece flexibilidade para os desenvolvedores criarem nomes exclusivos.
Nomes de recursos de aplicativo lógico
Para diferenciar os recursos de aplicativo lógico de Consumo e Standard, você pode usar abreviações diferentes, por exemplo:
- Consumo: LACon
- Standard: LAStd
Do ponto de vista organizacional, você pode criar um padrão de nomenclatura que inclua a unidade de negócios, o departamento, o aplicativo e, opcionalmente, o ambiente de implantação, como DEV, UAT, PROD etc., por exemplo:
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Suponha que você tenha um aplicativo lógico Standard em desenvolvimento que implemente fluxos de trabalho para o departamento de RH da unidade de negócios de Serviços Corporativos. Você pode dar ao recurso de aplicativo lógico o nome LAStd-CorporateServices-HR-DEV e usar a notação Pascal Case quando apropriado para manter a consistência.
Nomes de fluxos de trabalho de aplicativo lógico
Um recurso de aplicativo lógico de Consumo sempre é mapeado para apenas um fluxo de trabalho, ou seja, você só precisa de um nome. Um recurso de aplicativo lógico Standard pode incluir vários fluxos de trabalho. Portanto, crie uma convenção de nomenclatura que você também possa aplicar aos fluxos de trabalho membros. Para esses fluxos de trabalho, considere o uso de uma convenção de nomenclatura baseada no nome do processo, por exemplo:
Process-<*process-name*>
Portanto, se você tiver um fluxo de trabalho que implemente tarefas de integração de funcionários, como a criação de um registro de funcionário, poderá dar ao fluxo de trabalho o nome Process-EmployeeOnboarding.
Veja outras considerações sobre a criação da convenção de nomenclatura de fluxo de trabalho:
- Siga o padrão Pai-Filho para fluxos de trabalho em que você deseja destacar alguma relação entre um ou mais fluxos de trabalho.
- Leve em conta se um fluxo de trabalho publica ou consome uma mensagem.
Nomes de operações de fluxo de trabalho
Quando você adiciona um gatilho ou uma ação ao fluxo de trabalho, o designer atribui automaticamente o nome genérico padrão a essa operação. No entanto, os nomes das operações precisam ser exclusivos no fluxo de trabalho, ou seja, o designer acrescenta sufixos numéricos sequenciais nas instâncias de operação seguintes, o que dificulta a legibilidade e a decifração da intenção original do desenvolvedor.
Para tornar os nomes das operações mais significativos e fáceis de entender, você pode adicionar um breve descritor de tarefa após o texto padrão e usar a notação Pascal Case para manter a consistência. Por exemplo, para a ação Analisar JSON, você pode usar um nome como Analisar JSON-ChangeEmployeeRecord. Com essa abordagem ou outras abordagens semelhantes, você continuará se lembrando de que a ação é Analisar JSON e a finalidade específica da ação. Portanto, caso você precise usar as saídas dessa ação posteriormente nas ações de fluxo de trabalho downstream, pode identificar e encontrar essas saídas com mais facilidade.
Observação
Para as organizações que usam expressões de modo extensivo, considere o uso de uma convenção de nomenclatura que não promova o uso do espaço em branco (' '). A linguagem de expressão nos Aplicativos Lógicos do Azure substitui o espaço em branco por sublinhados ('_'), o que pode complicar a criação. Ao evitar espaços antecipadamente, você ajuda a reduzir o atrito ao criar expressões. Em vez disso, use um traço ou um hífen ('-'), que fornece legibilidade e não afeta a criação de expressões.
Para evitar possíveis retrabalhos mais tarde e problemas relacionados a dependências downstream, que são criadas quando você usa saídas de operação, renomeie as operações imediatamente quando as adicionar ao fluxo de trabalho. Normalmente, as ações downstream são atualizadas automaticamente quando você renomeia uma operação. No entanto, os Aplicativos Lógicos do Azure não renomeiam automaticamente as expressões personalizadas que você criou antes de executar a renomeação.
Nomes de conexões
Quando você cria uma conexão no fluxo de trabalho, o recurso de conexão subjacente obtém automaticamente um nome genérico, como sql ou office365. Assim como os nomes das operações, os nomes das conexões também precisam ser exclusivos. As conexões seguintes com o mesmo tipo obtêm um sufixo numérico sequencial, por exemplo, sql-1, sql-2 etc. Esses nomes não fornecem nenhum contexto, o que torna a diferenciação e o mapeamento de conexões para seus fluxos de trabalho extremamente desafiadores, especialmente para desenvolvedores que não conhecem o espaço de solução e precisam manter esses fluxos de trabalho.
Portanto, nomes de conexões significativos e consistentes são importantes pelos seguintes motivos:
- Legibilidade
- Transferência de conhecimento e capacidade de suporte mais fáceis
- Governança
Novamente, ter uma convenção de nomenclatura é fundamental, embora o formato não seja excessivamente importante. Por exemplo, você pode usar o seguinte padrão como uma diretriz:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
Como exemplo concreto, você pode renomear uma conexão do Barramento de Serviço em um aplicativo lógico em um fluxo de trabalho OrderQueue com CN-ServiceBus-OrderQueue como o novo nome. Para obter mais informações, consulte a postagem no blog Turbo360 (anteriormente Serverless360) práticas recomendadas do aplicativo lógico, dicas e truques: convenção de nomenclatura de conectores nº 11.
Tratar as exceções com escopos e opções "Executar após"
Os escopos fornecem a capacidade de agrupar várias ações, de modo que você possa implementar o comportamento Try-Catch-Finally. No designer, você pode recolher e expandir o conteúdo de um escopo para aprimorar a produtividade do desenvolvedor.
Ao implementar esse padrão, você também pode especificar quando executar a ação Escopo e as ações internas, de acordo com o status de execução da ação anterior, que pode ser Succeeded, Failed, Skipped ou TimedOut. Para configurar esse comportamento, use as opções Executar após da ação Escopo (runAfter):
- Obteve sucesso
- Falhou
- Foi ignorado
- Atingiu o tempo limite
Consolidar os serviços compartilhados
Ao criar soluções de integração, considere a criação e o uso de serviços compartilhados para tarefas comuns. Você pode pedir à sua equipe para criar e expor uma coleção de serviços compartilhados que a equipe de projeto e outras pessoas possam usar. Todos ganham maior produtividade, uniformidade e capacidade de impor a governança nas soluções da sua organização. As seguintes seções descrevem algumas áreas nas quais você pode considerar a introdução de serviços compartilhados:
| Serviço compartilhado | Motivos |
|---|---|
| Registro em log centralizado | Forneça padrões comuns de como os desenvolvedores instrumentam o código com o log apropriado. Em seguida, você pode configurar exibições de diagnóstico que ajudam a determinar a integridade e a capacidade de suporte da interface. |
| Acompanhamento de negócios e monitoramento das atividades de negócios | Capture e exponha dados para que os especialistas no assunto de negócios possam entender melhor o estado das transações comerciais e executar consultas analíticas de autoatendimento. |
| Dados de configuração | Separe os dados de configuração do aplicativo do código para que você possa mover seu aplicativo com mais facilidade entre os ambientes. Lembre-se de fornecer uma abordagem unificada consistente e que possa ser facilmente replicável para acessar dados de configuração, de modo que as equipes de projeto possam se concentrar em resolver o problema de negócios em vez de gastar tempo em configurações de aplicativo para implantação. Caso contrário, se cada projeto abordar essa separação de maneira única, você não poderá se beneficiar da economia de escala. |
| Conectores personalizados | Crie conectores personalizados para sistemas internos que não tenham conectores predefinidos nos Aplicativos Lógicos do Azure, a fim de simplificar o processo para a equipe de projeto e outras pessoas. |
| Conjuntos de dados ou feeds de dados comuns | Exponha conjuntos de dados e feeds comuns como APIs ou conectores para uso das equipes de projeto e evite "reinventar a roda". Cada organização tem conjuntos de dados comuns de que precisam para integrar sistemas em um ambiente corporativo. |
Próximas etapas
Agora você aprendeu mais sobre as abordagens de migração disponíveis e as práticas recomendadas para mover cargas de trabalho do BizTalk Server para os Aplicativos Lógicos do Azure. Para fornecer comentários detalhados sobre este guia, use o seguinte formulário: