Abordagens de migração do BizTalk Server para Aplicativos Lógicos do Azure
Este guia aborda estratégias e recursos de migração, juntamente com considerações de planejamento e práticas recomendadas para ajudá-lo a fornecer soluções de migração bem-sucedidas.
Nota
Para obter uma visão geral da migração e um guia para escolher serviços no Azure para sua migração, revise a seguinte documentação:
Opções estratégicas
As seções a seguir descrevem várias estratégias de migração, juntamente com seus benefícios e desvantagens:
Grande estrondo
Um "big bang" ou "mudança direta" é uma abordagem que requer muito planejamento e não é recomendada para 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, novos aprendizados geralmente resultam. Ao investir muito cedo ou muito, você não terá a oportunidade de se beneficiar das lições aprendidas e se ajustar sem arriscar um retrabalho significativo.
Essa abordagem também pode levar mais tempo para colher ou acumular valor. Se você já concluiu algumas atividades de migração, mas ainda não as lançou em 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 do BizTalk pequenas e de baixa complexidade, especialistas no assunto (PMEs) que conheçam seu ambiente do 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 de seguir essa abordagem.
Iterativo ou baseado em onda (Recomendado)
Essa abordagem oferece a oportunidade para que sua organização alcance valor de forma incremental, mas mais cedo do que de outra forma. Sua equipe de projeto pode aprender sobre a pilha de tecnologia antecipadamente usando retrospetivas. Por exemplo, você pode implantar uma interface ou projeto existente do BizTalk em produção e, em seguida, 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 os recursos existentes ou introduzir novos padrões que você pode usar posteriormente em trabalhos futuros.
Independentemente da sua abordagem, se planeia mudar para as Aplicações Lógicas do Azure ou para o Azure em geral, considere fortemente a refatoração das suas soluções do BizTalk Server em soluções sem servidor ou nativas da nuvem antes de encerrar a infraestrutura do servidor. Esta escolha é uma excelente estratégia se a sua organização quer transformar o negócio completamente para a 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 o Azure Integration Services para estender os recursos nos Aplicativos Lógicos do Azure que atendem às principais necessidades de integração do cliente.
Para obter um maior retorno sobre o investimento (ROI), recomendamos que qualquer migração do BizTalk use os principais recursos nativos nos Aplicativos Lógicos do Azure (Padrão) tanto quanto possível e estendido com outros Serviços de Integração do Azure, conforme necessário. Esta combinação possibilita cenários adicionais, por exemplo:
- Recursos híbridos nativos da nuvem com Aplicativos Lógicos do Azure (Padrão) com implantação híbrida
- Recursos de fluxo de trabalho com ou sem monitoração de estado nos Aplicativos Lógicos do Azure (Padrão)
- Integração nativa, interna (no aplicativo) de mainframe e midranges com conectores nos Aplicativos Lógicos do Azure (Padrão)
- Mensagens pub-sub usando o Barramento de Serviço do Azure
- Recursos avançados de SOAP no Gerenciamento de API do Azure
Entregar um projeto de migração do BizTalk
Para concluir tal projeto, recomendamos que você siga a abordagem iterativa ou baseada em ondas e use o processo Scrum. Embora o Scrum não inclua um conceito Sprint Zero (Sprint 0) para atividades pré-sprint, recomendamos que você concentre sua primeira 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 produto mínimo viável (MVP).
Sprint 0
Durante esse sprint, recomendamos que você execute a descoberta de ambientes do BizTalk Server com planejamento de ondas. Compreender a amplitude e profundidade do projeto é fundamental para o sucesso. A lista a seguir inclui as áreas específicas a serem abordadas durante o Sprint 0:
| Área | Description |
|---|---|
| Deteção | Capture dados sobre todas as suas interfaces e aplicativos para que você possa aprender o número de interfaces e aplicativos que você precisa migrar. 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 Business Activity Monitoring, Business Rules Engine, EDI e assim por diante - Código personalizado, como expressões, mapas e componentes de pipeline - Taxa de transferência de mensagens - Tamanhos das mensagens - Dependências - Dependências de aplicações e sistemas |
| Conceção de arquiteturas | Crie a arquitetura de alto nível para usar como ponto focal para a migração. Este design inclui elementos que atendem a necessidades funcionais e não funcionais de alto nível. |
| Definição de produto mínimo viável (MVP) | Defina os recursos da primeira onda. Em outras palavras, os processos que precisam de apoio depois de concluir a primeira onda. |
| Backlog inicial de migração | Definir as características da primeira onda e seus itens de trabalho com elaboração técnica. |
Ferramentas de descoberta
Para ajudá-lo com a descoberta de migração, você pode usar a ferramenta de linha de comando do Azure Integration Migrator, também chamada de ferramenta de migração do BizTalk, que é um projeto de código aberto da Microsoft. Essa ferramenta usa uma abordagem em fases para ajudá-lo a descobrir informações e estratégias úteis para migrar suas soluções para a nuvem. Recomendamos usar a ferramenta migrador apenas para descoberta e geração de relatórios. Você também pode considerar o uso de outros produtos para descoberta de parceiros que fornecem soluções neste 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. Esta ferramenta funciona com o BizTalk Server 2020, apesar de afirmar que apenas o BizTalk Server 2016 é suportado.
Conceção de arquiteturas
Embora os Aplicativos Lógicos do Azure forneçam recursos que permitem reutilizar ativos do BizTalk Server, você deve ter um design de arquitetura moderno para aproveitar os benefícios de recursos mais modernos. De uma perspetiva funcional, use sua lógica de negócios o máximo possível. Do ponto de vista da modernização do produto, use o Azure Integration Services o máximo que puder. Para questões de qualidade e transversais, recomendamos que você use o Azure Well-Architected Framework.
Nessa estrutura, as migrações do BizTalk são cargas de trabalho de missão crítica. Este termo descreve coleções de recursos de aplicativos 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 sua migração do BizTalk, siga a metodologia Design para cargas de trabalho de missão crítica no Azure. Para obter uma arquitetura e topologia iniciais, revise e use a arquitetura de referência descrita em Integração corporativa básica no Azure no Centro de Arquitetura do Azure.
Para configurar seu ambiente inicial, use o Azure Integration Services Landing Zone Accelerator, que é direcionado para criar e implantar uma plataforma de integração usando um design típico de zona de aterrissagem empresarial.
Definição de projeto mínimo viável (MVP)
Um MVP é uma versão do produto que tem recursos suficientes utilizáveis pelo cliente. Esta versão mostra as possibilidades e o potencial do produto para recolher o feedback dos clientes e continuar o trabalho. Para uma migração do BizTalk, sua definição de MVP reflete as iterações, ondas ou grupos de sprints de que você precisa para progredir em direção aos recursos de trabalho e atender às cargas de trabalho iniciais de integração.
Recomendamos que sua definição de MVP inclua os seguintes resultados de negócios, que são expressos como Épicos na terminologia do Scrum:
Resultados de negócios (Épicos)
- Qual é o principal objetivo que pretende alcançar?
- Quais recursos ou recursos você deve abordar para este MVP?
- Quais são os fluxos de processos de negócios? Esta pergunta oferece a oportunidade de otimizar os processos existentes suportados pelo 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 do esource?
Recomendamos que seu MVP inclua os seguintes processos no escopo, que são expressos como Recursos na terminologia do Scrum:
Processos no escopo (Recursos)
| Funcionalidade | Description |
|---|---|
| Funcionalidade do 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 suportados pelo MVP. |
| Orquestrações | Você pode extrair essas informações usando as ferramentas de descoberta. |
| Entidades de dados e mensagens | Esses elementos lhe dão a oportunidade de saber se você pode incluir mais melhorias 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ócio | Essas regras centradas em dados abrem uma oportunidade para você repensar sua abordagem ou reutilizá-las empregando recursos de Aplicativos Lógicos do Azure. |
| Considerações sobre privacidade de dados | Você deve fazer da privacidade uma prioridade máxima. A menos que seu cliente escolha o modelo de implantação híbrida nos Aplicativos Lógicos do Azure (Padrão), você deve abordar essa área em cada onda devido a possíveis alterações no ambiente de implantação. |
| Considerações regulamentares | Esse aspeto é mais relevante se seus clientes não tiverem cargas de trabalho baseadas em nuvem. |
| Concebido para ser seguro | Você deve projetar cada recurso com a segurança em mente. |
| Características propostas para a coexistência | Quando você entrega cada onda, você tem um certo grau de convivência. Você deve alinhar essa arquitetura híbrida com os Indicadores de Nível de Serviço (SLIs) e os Objetivos de Nível de Serviço (SLOs) existentes. |
| Considerações não funcionais | Os processos de negócios 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 empresariais | Uma oportunidade opcional para mostrar o progresso do trabalho de migração. |
Você também desejará identificar e listar as várias variáveis fora do escopo que moldam o escopo do seu trabalho de MVP, por exemplo:
- Disponibilidade do recurso
- Riscos
- Documentação
- Tempo de colocação no mercado
Atraso inicial
A lista de pendências 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 Épicos, Recursos e Histórias de Usuário. Idealmente, cada Epic engloba um grupo de aplicações ou projetos do BizTalk. Você pode usar a regra simples que associa um aplicativo ou projeto do 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. Então, você tem o seguinte recurso proposto e história de usuário:
Desenho: Processamento de empréstimos
História de usuário: "Como cliente, quero enviar um pedido de empréstimo para que o banco possa adicionar fundos à minha conta segura."
Esta História de Utilizador, que pode existir atualmente como uma implementação no BizTalk Server, tem as seguintes tarefas para implementar utilizando as Aplicações Lógicas 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 Azure Service Bus ou o IBM MQ.
- Mapeie JSON para dados XML usando um fluxo de trabalho de Aplicativos Lógicos do Azure.
- Personalize o Azure Integration Services conforme necessário para padrões de mensagens.
O diagrama a seguir mostra as durações sugeridas para Épicos, 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 do BizTalk existentes nos Aplicativos Lógicos do Azure. Crie seus fluxos de trabalho padrão usando os modelos de fluxo de trabalho pré-criados tanto quanto possível.
Ondas de migração (Sprints)
Depois que sua equipe concluir o Sprint 0, você deve 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 tanto quanto possível:
Durante uma onda, sua equipe conclui as atividades para migrar, testar e liberar para a produção. Vamos examinar mais de perto o que acontece em cada onda.
Migrate
Durante cada vaga, a migração centra-se nas Histórias de Utilizador acordadas. Para a primeira onda, sua equipe se concentra na lista de pendências inicial. As decisões de tecnologia devem usar as informações no mapeamento de recursos do BizTalk Server, descrito por Correspondência de recursos - Por que migrar do BizTalk Server para os Aplicativos Lógicos do Azure?
O diagrama a seguir mostra os eventos que devem acontecer durante as ondas de migração:
| Passo | Description |
|---|---|
| 5 | Descubra as aplicações e interfaces existentes do BizTalk. Embora introduzida no Sprint 0, esta atividade deve acontecer quando cada onda começa. Os clientes podem continuar fazendo alterações em seu ambiente do BizTalk. Recursos: - Ferramenta de migração do BizTalk - Ferramenta BizTalk Documenter |
| 2 | Configure seu ambiente de migração inicial. Você pode usar o Azure Integration Services Landing Zone Accelerator, que é uma estrutura de adoção de nuvem para criar e implantar uma plataforma de integração que tenha um design típico de zona de aterrissagem empresarial. Como proprietário da carga de trabalho, você pode atingir com confiança seu estado técnico de destino usando a orientação de arquitetura fornecida e os recursos de migração do BizTalk. Para obter um exemplo de arquitetura, consulte Exemplo de ambiente de migração. |
| 3 | Crie e teste fluxos de trabalho de aplicativos lógicos padrão 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 Aplicativos Lógicos do Azure (Padrão). Com o Visual Studio Code, você pode desenvolver, testar e armazenar localmente seu projeto de aplicativo lógico usando qualquer sistema de controle de origem. Para obter mais informações, consulte a seguinte documentação: - Criar um exemplo de fluxo de trabalho de aplicativo lógico padrão usando o portal do Azure - Criar um exemplo de fluxo de trabalho de aplicativo lógico padrão usando o Visual Studio Code Para obter um diagrama que mostra um aplicativo lógico de exemplo e conexões, consulte Exemplo de ambiente de migração. |
| 4 | Para obter todos os benefícios da implantação fácil e consistente de seus fluxos de trabalho de aplicativos lógicos padrão em diferentes ambientes e plataformas, você também deve automatizar seu processo de compilação e implantação. A extensão de Aplicativos Lógicos do Azure (Padrão) para Visual Studio Code fornece ferramentas para você criar e manter processos automatizados de compilação e implantação usando o Azure DevOps. Para obter mais informações, consulte Automatizar a compilação e a implantação para fluxos de trabalho de aplicativos lógicos padrão com o Azure DevOps. |
| 5 | Para implantar aplicativos lógicos padrão de missão crítica que estão sempre disponíveis e respondem, mesmo durante atualizações ou manutenção, habilite a implantação sem tempo de inatividade criando e usando slots de implantação. Zero tempo de inatividade significa que, quando você implanta novas versões do seu aplicativo, os usuários finais não devem sofrer interrupções ou tempo de inatividade. Para obter mais informações, consulte Configurar slots de implantação para habilitar a implantação sem tempo de inatividade nos Aplicativos Lógicos do Azure. |
O diagrama a seguir mostra um exemplo de ambiente de migração inicial com um aplicativo lógico padrão 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 incorporadas em cada User Story. Se você quiser usar o teste shift-left, certifique-se de concluir as seguintes tarefas:
Automatize seus testes.
Os Aplicativos Lógicos do Azure (Padrão) incluem a capacidade de executar testes automatizados. A lista a seguir inclui mais informações e recursos que estão disponíveis gratuitamente no GitHub:
Testes automatizados com Aplicativos Lógicos do Azure (Padrão) da equipe de Aplicativos Lógicos do Azure
Com os Aplicativos Lógicos do Azure (Padrão), o teste automatizado não é mais difícil de executar, devido à arquitetura subjacente, que se baseia no tempo de execução 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, consulte o projeto de exemplo para a Estrutura de Teste de Aplicativos Lógicos do Azure.
Esta estrutura de teste inclui os seguintes recursos:
- Escreva testes automatizados para funcionalidade de ponta a ponta nos Aplicativos Lógicos do Azure.
- Execute uma 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 localmente ou dentro de pipelines de CI/CD.
- Recursos de teste simulados para ações HTTP e conectores do Azure.
- Configure testes para usar valores de configuração diferentes da produção.
Manual de integração: testes padrão de aplicativos lógicos de Michael Stephenson, MVP da Microsoft
A estrutura de teste do Integration Playbook baseia-se na estrutura de teste fornecida pela Microsoft e oferece suporte a cenários adicionais:
- Conecte-se a um fluxo de trabalho em um aplicativo lógico padrão.
- Obtenha a URL de retorno de chamada para que você possa acionar o fluxo de trabalho a partir de um teste.
- Verifique os resultados da execução do fluxo de trabalho.
- Verifique as entradas e saídas da operação a partir do histórico de execução do fluxo de trabalho.
- Conecte-se a estruturas de teste automatizadas que os desenvolvedores de aplicativos lógicos podem usar.
- Conecte-se ao SpecFlow para oferecer suporte ao desenvolvimento orientado por comportamento (BDD) para aplicativos lógicos.
Independentemente das abordagens ou recursos de automação usados, você está no caminho certo para ter testes de integração repetíveis, consistentes e automatizados.
Configure o teste de resposta simulada usando resultados estáticos.
Independentemente de configurar testes automatizados, você pode usar o recurso de resultados estáticos nos Aplicativos Lógicos do Azure para definir temporariamente respostas simuladas no nível de 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 a quantidade de dados que criaria em sistemas de linha de negócios.
Execute testes lado a lado.
Idealmente, você já tem testes de integração de linha de base para seu ambiente do BizTalk Server e testes automatizados estabelecidos para Aplicativos Lógicos do Azure. Em seguida, você pode executar testes lado a lado de uma forma que o ajude a verificar suas interfaces usando os mesmos conjuntos de dados e melhorar a precisão geral do teste.
Lançamento 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 a sua versão para produção.
Faça um plano de "corte".
Um plano de transição cobre os detalhes sobre as tarefas e atividades necessárias para mudar da plataforma atual para a nova plataforma, incluindo as etapas que sua equipe planeja executar. Inclua as seguintes considerações no seu plano de transferência:
- Passos de pré-requisitos
- Ensaio geral
- Pessoas
- Estimativas de cronograma
- Desativando interfaces na plataforma antiga
- Habilitando interfaces na nova plataforma
- Testes de validação
Determine um plano de reversão.
Execute testes de validação.
Planejar operações ou suporte à produção.
Escolha os critérios "go or no go" para liberar para produção.
Celebre o sucesso da sua equipa.
Faça uma retrospetiva.
Práticas recomendadas para uma migração do 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 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 suportar. O time-to-market é um facilitador fundamental para a transformação digital, portanto, uma prioridade máxima é reduzir atritos desnecessários para desenvolvedores e equipes de suporte.
Ao estabelecer suas próprias práticas recomendadas, considere alinhar-se com as seguintes orientações:
Convenções gerais de nomenclatura para recursos do Azure
Certifique-se de configurar e aplicar consistentemente boas convenções de nomenclatura em todos os recursos do Azure, desde grupos de recursos até cada tipo de recurso. Para estabelecer uma base sólida para a capacidade de descoberta e suporte, uma boa convenção de nomenclatura comunica propósito. O ponto mais importante para nomear convenções é que você as tenha e que sua organização as entenda. Todas as organizações têm nuances que podem ter de ter em conta.
Para obter orientação sobre essa prática, consulte as seguintes recomendações e recursos da Microsoft:
- Exemplos de abreviatura para recursos do Azure
- A Ferramenta de Nomenclatura do Azure, que gera nomes compatíveis com o Azure, ajuda você a padronizar nomes e automatiza seu processo de nomenclatura.
Convenções de nomenclatura para recursos de Aplicativos Lógicos do Azure
O design para seu aplicativo lógico e fluxo de trabalho fornece um ponto de partida importante porque essa área oferece flexibilidade para os desenvolvedores criarem nomes exclusivos.
Nomes de recursos de aplicativos lógicos
Para diferenciar entre recursos do aplicativo lógico Consumo e Padrão, você pode usar abreviaturas diferentes, por exemplo:
- Consumo: LACon
- Padrão: LAStd
De uma perspetiva organizacional, você pode projetar 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, PRODe assim por diante, por exemplo:
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Suponha que você tenha um aplicativo lógico padrão em desenvolvimento que implemente fluxos de trabalho para o departamento de RH na unidade de negócios Serviços Corporativos. Você pode nomear o recurso do aplicativo lógico LAStd-CorporateServices-HR-DEV e usar a notação Pascal Case quando apropriado para consistência.
Nomes de fluxo de trabalho de aplicativos lógicos
Um recurso de aplicativo lógico de consumo sempre mapeia para apenas um fluxo de trabalho, portanto, você só precisa de um único nome. Um recurso de aplicativo lógico padrão pode incluir vários fluxos de trabalho, portanto, projete uma convenção de nomenclatura que você também possa aplicar aos fluxos de trabalho dos membros. Para esses fluxos de trabalho, considere uma convenção de nomenclatura com base no nome do processo, por exemplo:
Process-<*process-name*>
Portanto, se você tiver um fluxo de trabalho que implementa tarefas de integração de funcionários, como a criação de um registro de funcionário, poderá nomear o fluxo de trabalho como Process-EmployeeOnboarding.
Aqui estão mais considerações para projetar sua 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 consideração se um fluxo de trabalho publica ou consome uma mensagem.
Nomes de operações de fluxo de trabalho
Quando você adiciona um gatilho ou ação ao seu fluxo de trabalho, o designer atribui automaticamente o nome genérico padrão para essa operação. No entanto, os nomes de operação devem ser exclusivos em seu fluxo de trabalho, de modo que o designer acrescenta sufixos numéricos sequenciais em instâncias de operação subsequentes, 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 tarefas após o texto padrão e usar a notação Pascal Case para consistência. Por exemplo, para a ação Analisar JSON, você pode usar um nome como Parse JSON-ChangeEmployeeRecord. Com essa abordagem ou outras abordagens semelhantes, você continuará a lembrar que a ação é Parse JSON e o propósito específico da ação. Portanto, se você precisar usar as saídas dessa ação mais tarde em ações de fluxo de trabalho downstream, poderá identificar e encontrar essas saídas mais facilmente.
Nota
Para organizações que usam expressões extensivamente, considere uma convenção de nomenclatura que não promova o uso de 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 hífen ('-'), que fornece legibilidade e não afeta a criação da expressão.
Para evitar possíveis retrabalhos posteriores e problemas em torno de dependências downstream, que são criadas quando você usa saídas de operação, renomeie suas operações imediatamente quando adicioná-las ao seu 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 expressões personalizadas que você criou antes de executar a renomeação.
Nomes de conexão
Quando você cria uma conexão em seu fluxo de trabalho, o recurso de conexão subjacente recebe automaticamente um nome genérico, como sql ou office365. Assim como os nomes de operação, os nomes de conexão também devem ser exclusivos. Conexões subsequentes com o mesmo tipo obtêm um sufixo numérico sequencial, por exemplo, sql-1, sql-2 e assim por diante. Esses nomes não fornecem nenhum contexto, o que torna a diferenciação e o mapeamento de conexões com seus fluxos de trabalho extremamente desafiadores, especialmente para desenvolvedores que não conhecem o espaço da solução e precisam manter esses fluxos de trabalho.
Portanto, nomes de conexão significativos e consistentes são importantes pelos seguintes motivos:
- Legibilidade
- Transferência de conhecimento mais fácil e capacidade de suporte
- Governação
Mais uma vez, ter uma convenção de nomenclatura é fundamental, embora o formato não seja muito importante. Por exemplo, você pode usar o seguinte padrão como diretriz:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
Como um exemplo concreto, você pode renomear uma conexão do Service Bus em um fluxo de trabalho do aplicativo lógico OrderQueue com CN-ServiceBus-OrderQueue como o novo nome. Para obter mais informações, consulte a postagem do blog Turbo360 (Anteriormente Serverless360), Práticas recomendadas do aplicativo lógico, dicas e truques: convenção de nomenclatura de conectores #11.
Lidar com exceções com escopos e opções "Executar após"
Os escopos fornecem a capacidade de agrupar várias ações para que você possa implementar o comportamento Try-Catch-Finally . No designer, você pode recolher e expandir o conteúdo de um escopo para melhorar 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, com base no status de execução da ação anterior, que pode ser Êxito, Falha, Ignorado ou Tempo Limite. Para configurar esse comportamento, use as opções Executar após (runAfter) da ação Escopo:
- É bem sucedido
- Falhou
- É ignorado
- Expirou
Consolidar serviços compartilhados
Ao criar soluções de integração, considere criar e usar serviços compartilhados para tarefas comuns. Você pode fazer com que sua equipe crie e exponha uma coleção de serviços compartilhados que sua equipe de projeto e outras pessoas podem usar. Todos ganham maior produtividade, uniformidade e a capacidade de impor governança nas soluções da sua organização. As seções a seguir descrevem algumas áreas em que você pode considerar a introdução de serviços compartilhados:
| Serviço partilhado | Motivos |
|---|---|
| Registo centralizado | Forneça padrões comuns para como os desenvolvedores instrumentam seu código com registro em 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 de atividades comerciais | Capture e exponha dados para que os especialistas no assunto de negócios possam entender melhor o estado de suas transações comerciais e realizar 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 mais facilmente o aplicativo entre ambientes. Certifique-se de fornecer uma abordagem unificada, consistente e facilmente replicável para acessar dados de configuração para que as equipes de projeto possam se concentrar na solução do problema de negócios, em vez de gastar tempo com configurações de aplicativos para implantação. Caso contrário, se cada projeto abordasse essa separação de uma maneira única, você não poderia se beneficiar de economias de escala. |
| Conectores personalizados | Crie conectores personalizados para sistemas internos que não tenham conectores pré-criados nos Aplicativos Lógicos do Azure para simplificar para sua equipe de projeto e outros. |
| Conjuntos de dados ou feeds de dados comuns | Exponha conjuntos de dados e feeds comuns como APIs ou conectores para as equipes de projeto usarem e evite reinventar a roda. Todas as organizações têm conjuntos de dados comuns de que precisam para integrar sistemas em um ambiente corporativo. |
Próximos passos
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, você pode usar o seguinte formulário: