Diferenças entre aplicativos lógicos padrão de locatário único versus aplicativos lógicos multilocatários de consumo
As Aplicações Lógicas do Azure são uma plataforma baseada na nuvem para criar e executar fluxos de trabalho automatizados de aplicações lógicas que integram as suas aplicações, dados, serviços e sistemas. Com essa plataforma, você pode desenvolver rapidamente soluções de integração altamente escaláveis para sua empresa e cenários B2B (business-to-business). Ao criar um recurso de aplicativo lógico, você seleciona a opção Consumo ou Hospedagem padrão. Um aplicativo lógico de consumo pode ter apenas um fluxo de trabalho executado em Aplicativos Lógicos do Azure multilocatário . Um aplicativo lógico padrão pode ter um ou vários fluxos de trabalho executados em Aplicativos Lógicos do Azure de locatário único ou em um Ambiente do Serviço de Aplicativo v3 (ASE v3).
Antes de escolher qual recurso de aplicativo lógico criar, revise o guia a seguir para saber como os tipos de fluxo de trabalho do aplicativo lógico se comparam entre si. Em seguida, você pode fazer uma escolha melhor sobre qual fluxo de trabalho e ambiente de aplicativo lógico melhor se adapta ao seu cenário, aos requisitos da solução e ao destino onde deseja implantar e executar seus fluxos de trabalho.
Se você é novo nos Aplicativos Lógicos do Azure, consulte O que são os Aplicativos Lógicos do Azure? e O que é um fluxo de trabalho de aplicativo lógico?.
Tipos e ambientes de fluxo de trabalho de aplicativo lógico
A tabela a seguir resume as diferenças entre um fluxo de trabalho de aplicativo lógico de consumo e um fluxo de trabalho de aplicativo lógico padrão. Você também aprende como o ambiente de locatário único difere do ambiente multilocatário para implantar, hospedar e executar seus fluxos de trabalho.
| Opção de hospedagem | Benefícios | Partilha e utilização de recursos | Modelo de preços e faturação | Gestão de limites |
|---|---|---|---|---|
| Consumo Ambiente de host: Aplicativos Lógicos do Azure Multilocatário |
- Mais fácil de começar - Pague pelo que usar - Totalmente gerido |
Um único recurso de aplicativo lógico pode ter apenas um fluxo de trabalho. Todos os aplicativos lógicos em locatários do Microsoft Entra compartilham o mesmo processamento (computação), armazenamento, rede e assim por diante. Para fins de redundância, os dados são replicados na região emparelhada. Para alta disponibilidade, o armazenamento com redundância geográfica (GRS) está habilitado. |
Consumo (pagamento por execução) | Os Aplicativos Lógicos do Azure gerenciam os valores padrão para esses limites, mas você pode alterar alguns desses valores, se essa opção existir para um limite específico. |
| Standard (Plano de Serviço de Fluxo de Trabalho) Ambiente de acolhimento: Aplicativos Lógicos do Azure de locatário único Observação: se o seu cenário exigir contêineres, crie aplicativos lógicos baseados em locatário único usando os Aplicativos Lógicos habilitados para Azure Arc. Para obter mais informações, consulte O que é o Azure Arc habilitado para Aplicativos Lógicos? |
- Mais conectores integrados hospedados no tempo de execução de um único locatário para maior taxa de transferência e menores custos em escala - Mais controle e capacidade de ajuste fino em torno de configurações de tempo de execução e desempenho - Suporte integrado para redes virtuais e terminais privados. - Crie seus próprios conectores embutidos. |
Um único recurso de aplicativo lógico pode ter vários fluxos de trabalho com e sem monitoração de estado. Os fluxos de trabalho em um único aplicativo lógico e locatário compartilham o mesmo processamento (computação), armazenamento, rede e assim por diante. Os dados permanecem na mesma região onde você implanta seu aplicativo lógico. |
Standard, baseado em um plano de hospedagem com um nível de preço selecionado. Se você executar fluxos de trabalho com monitoração de estado, que usam armazenamento externo, o tempo de execução dos Aplicativos Lógicos do Azure fará transações de armazenamento que seguem os preços do Armazenamento do Azure. |
Você pode alterar os valores padrão para muitos limites, com base nas necessidades do seu cenário. Importante: Alguns limites têm máximos máximos rígidos. No Visual Studio Code, as alterações feitas nos valores de limite padrão em seus arquivos de configuração de projeto de aplicativo lógico não aparecerão na experiência do designer. Para obter mais informações, consulte Editar configurações de aplicativo e ambiente para aplicativos lógicos em Aplicativos Lógicos do Azure de locatário único. |
| Padrão (Ambiente do Serviço de Aplicativo v3) Ambiente de acolhimento: Ambiente do Serviço de Aplicativo v3 (ASEv3) - somente planos do Windows |
Os mesmos recursos que o locatário único, além dos seguintes benefícios: - Isole totalmente seus aplicativos lógicos. - Crie e execute mais aplicativos lógicos do que em aplicativos lógicos do Azure de locatário único. - Pague apenas pelo plano ASE App Service, independentemente do número de aplicativos lógicos que você criar e executar. - Pode habilitar o dimensionamento automático ou dimensionar manualmente com mais instâncias de máquina virtual ou um plano de Serviço de Aplicativo diferente. - Herdar a configuração de rede do ASEv3 selecionado. Por exemplo, quando você implanta em um ASE interno, os fluxos de trabalho podem acessar os recursos em uma rede virtual associada ao ASE e ter pontos de acesso internos. Nota: Se acessado de fora de um ASE interno, execute históricos para fluxos de trabalho em que o ASE não pode acessar entradas e saídas de ação. |
Um único aplicativo lógico pode ter vários fluxos de trabalho com e sem monitoração de estado. Os fluxos de trabalho em um único aplicativo lógico e locatário compartilham o mesmo processamento (computação), armazenamento, rede e assim por diante. Os dados permanecem na mesma região onde você implanta seus aplicativos lógicos. |
Plano do Serviço de Aplicações | Você pode alterar os valores padrão para muitos limites, com base nas necessidades do seu cenário. Importante: Alguns limites têm máximos máximos rígidos. No Visual Studio Code, as alterações feitas nos valores de limite padrão em seus arquivos de configuração de projeto de aplicativo lógico não aparecerão na experiência do designer. Para obter mais informações, consulte Editar configurações de aplicativo e ambiente para aplicativos lógicos em Aplicativos Lógicos do Azure de locatário único. |
Aplicativo lógico padrão e fluxo de trabalho
O aplicativo lógico padrão e o fluxo de trabalho são alimentados pelo tempo de execução redesenhado dos Aplicativos Lógicos do Azure de locatário único. Esse tempo de execução usa o modelo de extensibilidade do Azure Functions e é hospedado como uma extensão no tempo de execução do Azure Functions. Esse design fornece portabilidade, flexibilidade e mais desempenho para seus fluxos de trabalho de aplicativos lógicos, além de outros recursos e benefícios herdados da plataforma Azure Functions e do ecossistema do Serviço de Aplicativo do Azure. Por exemplo, você pode criar, implantar e executar aplicativos lógicos baseados em locatário único e seus fluxos de trabalho no Ambiente do Serviço de Aplicativo do Azure v3 (somente planos do Windows).
O aplicativo lógico padrão apresenta uma estrutura de recursos que pode hospedar vários fluxos de trabalho, semelhante a como um aplicativo de função do Azure pode hospedar várias funções. Com um mapeamento de 1 para muitos, fluxos de trabalho no mesmo aplicativo lógico e locatário compartilham recursos de computação e processamento, proporcionando melhor desempenho devido à sua proximidade. Essa estrutura difere do recurso do aplicativo lógico de consumo, onde você tem um mapeamento de 1 para 1 entre o recurso do aplicativo lógico e um fluxo de trabalho.
Para saber mais sobre portabilidade, flexibilidade e melhorias de desempenho, continue analisando as seções a seguir. Para obter mais informações sobre o tempo de execução dos Aplicativos Lógicos do Azure de locatário único e a extensibilidade do Azure Functions, consulte a seguinte documentação:
- Aplicativos lógicos do Azure em execução em qualquer lugar - Runtime Deep Dive
- Introdução às Funções do Azure
- Gatilhos e associações do Azure Functions
Portabilidade e flexibilidade
Ao criar um aplicativo lógico e um fluxo de trabalho padrão, você pode implantar e executar seu fluxo de trabalho em outros ambientes, como o Ambiente do Serviço de Aplicativo do Azure v3 (somente planos do Windows). Se você usar o Visual Studio Code com a extensão Azure Logic Apps (Standard), poderá desenvolver, compilar e executar localmente seu fluxo de trabalho em seu ambiente de desenvolvimento sem precisar implantar no Azure. Se o seu cenário exigir contêineres, você poderá criar aplicativos lógicos de locatário único usando os Aplicativos Lógicos habilitados para Azure Arc. Para obter mais informações, consulte O que são os Aplicativos Lógicos habilitados para Azure Arc?
Esses recursos fornecem grandes melhorias e benefícios substanciais em comparação com o modelo multilocatário, que exige que você desenvolva em relação a um recurso em execução existente no Azure. O modelo multilocatário para automatizar a implantação de recursos do aplicativo lógico de consumo é baseado em modelos do Azure Resource Manager (modelos ARM), que combinam e manipulam o provisionamento de recursos para aplicativos e infraestrutura.
Com o recurso de aplicativo lógico padrão, a implantação se torna mais fácil porque você pode separar a implantação do aplicativo da implantação da infraestrutura. Você pode empacotar o tempo de execução dos Aplicativos Lógicos do Azure de locatário único e seus fluxos de trabalho juntos como parte do seu recurso ou projeto de aplicativo lógico. Você pode usar etapas ou tarefas genéricas que criam, montam e compactam os recursos do aplicativo lógico em artefatos prontos para implantação. Para implantar sua infraestrutura, você ainda pode usar modelos ARM para provisionar separadamente esses recursos junto com outros processos e pipelines que você usa para esses fins.
Para implantar seu aplicativo, copie os artefatos para o ambiente host e inicie seus aplicativos para executar seus fluxos de trabalho. Ou integre seus artefatos em pipelines de implantação usando as ferramentas e os processos que você já conhece e usa. Dessa forma, você pode implantar usando suas próprias ferramentas escolhidas, independentemente da pilha de tecnologia que você usa para desenvolvimento.
Usando opções padrão de compilação e implantação, você pode se concentrar no desenvolvimento de aplicativos separadamente da implantação de infraestrutura. Como resultado, você obtém um modelo de projeto mais genérico onde pode aplicar muitas opções de implantação semelhantes ou iguais que você usa para um aplicativo genérico. Você também se beneficia de uma experiência mais consistente ao criar pipelines de implantação para seus aplicativos e ao executar os testes e validações necessários antes de publicar na produção.
Desempenho
Com um aplicativo lógico padrão , você pode criar e executar vários fluxos de trabalho no mesmo recurso e locatário de aplicativo lógico único. Com esse mapeamento de 1 para muitos, esses fluxos de trabalho compartilham recursos, como computação, processamento, armazenamento e rede, proporcionando um melhor desempenho devido à sua proximidade.
O recurso de aplicativo lógico padrão e o tempo de execução dos Aplicativos Lógicos do Azure de locatário único fornecem outra melhoria significativa, disponibilizando os conectores gerenciados mais populares como operações de conector internas. Por exemplo, você pode usar operações de conector internas para o Barramento de Serviço do Azure, Hubs de Eventos do Azure, SQL Server e outros. Enquanto isso, as versões do conector gerenciado ainda estão disponíveis e continuam a funcionar.
Ao usar as novas operações de conector interno, você cria conexões chamadas conexões internas ou conexões de provedor de serviços. Suas contrapartes de conexão gerenciadas são chamadas de conexões de API, que são criadas e executadas separadamente como recursos do Azure que você também precisa implantar usando modelos ARM. As operações internas e suas conexões são executadas localmente no mesmo processo que executa seus fluxos de trabalho. Ambos são hospedados no tempo de execução dos Aplicativos Lógicos do Azure de locatário único. Como resultado, as operações integradas e suas conexões fornecem um melhor desempenho devido à proximidade com seus fluxos de trabalho. Esse design também funciona bem com pipelines de implantação porque as conexões do provedor de serviços são empacotadas no mesmo artefato de compilação.
Residência de dados
Os recursos do aplicativo lógico padrão são hospedados em Aplicativos Lógicos do Azure de locatário único, que não armazenam, processam ou replicam dados fora da região onde você implanta esses recursos do aplicativo lógico, o que significa que os dados em seus fluxos de trabalho permanecem na mesma região onde você cria e implanta seus recursos pai.
Acesso direto a recursos em redes virtuais do Azure
Os fluxos de trabalho executados em Aplicativos Lógicos do Azure de locatário único podem acessar diretamente recursos protegidos, como máquinas virtuais (VMs), outros serviços e sistemas que existem em uma rede virtual do Azure.
Os Aplicativos Lógicos do Azure de locatário único são uma instância dedicada do serviço Aplicativos Lógicos do Azure, usam recursos dedicados e são executados separadamente dos Aplicativos Lógicos do Azure multilocatário. A execução de fluxos de trabalho em uma instância dedicada ajuda a reduzir o impacto que outros locatários do Azure podem ter no desempenho do aplicativo, também conhecido como efeito "vizinhos barulhentos".
Os Aplicativos Lógicos do Azure de locatário único também oferecem os seguintes benefícios:
Seus próprios endereços IP estáticos, que são separados dos endereços IP estáticos que são compartilhados pelos aplicativos lógicos nos Aplicativos Lógicos do Azure multilocatário. Você também pode configurar um único endereço IP de saída público, estático e previsível para se comunicar com os sistemas de destino. Dessa forma, você não precisa configurar aberturas de firewall extras nesses sistemas de destino.
Maiores limites de duração de execução, retenção de armazenamento, taxa de transferência, tempo limite de solicitação e resposta HTTP, tamanhos de mensagem e solicitações de conector personalizadas. Para obter mais informações, consulte Limites e configuração para Aplicativos Lógicos do Azure.
Criar, criar e implantar opções
Para criar um recurso de aplicativo lógico com base no ambiente desejado, você tem várias opções, por exemplo:
Ambiente de inquilino único
Ambiente multilocatário
Embora suas experiências de desenvolvimento sejam diferentes com base na criação de recursos de aplicativo lógico Consumo ou Padrão , você pode encontrar e acessar todos os seus aplicativos lógicos implantados em sua assinatura do Azure.
Por exemplo, no portal do Azure, a página Aplicativos lógicos mostra os recursos do aplicativo lógico Consumo e Padrão. No Visual Studio Code, os aplicativos lógicos implantados aparecem em sua assinatura do Azure, mas os aplicativos lógicos de consumo aparecem na janela do Azure na extensão Aplicativos Lógicos do Azure (Consumo), enquanto os aplicativos lógicos padrão aparecem na seção Recursos.
Fluxos de trabalho com e sem monitoração de estado
Dentro de um aplicativo lógico padrão , você pode criar os seguintes tipos de fluxo de trabalho:
Com estado
Crie um fluxo de trabalho com monitoração de estado quando precisar manter, revisar ou fazer referência a dados de eventos anteriores. Esses fluxos de trabalho salvam todas as entradas, saídas e estados das operações no armazenamento externo. Essas informações possibilitam a revisão dos detalhes e do histórico de execução do fluxo de trabalho após a conclusão de cada execução. Os fluxos de trabalho com monitoração de estado fornecem alta resiliência se ocorrerem interrupções. Depois que os serviços e sistemas forem restaurados, você poderá reconstruir execuções interrompidas a partir do estado salvo e executar novamente os fluxos de trabalho até a conclusão. Os fluxos de trabalho com monitoração de estado podem continuar em execução por muito mais tempo do que os fluxos de trabalho sem monitoração de estado.
Por padrão, os fluxos de trabalho com monitoração de estado nos Aplicativos Lógicos do Azure multilocatário e de locatário único são executados de forma assíncrona. Todas as ações baseadas em HTTP seguem o padrão de operação assíncrona padrão. Depois que uma ação HTTP chama ou envia uma solicitação para um ponto de extremidade, serviço, sistema ou API, o destinatário da solicitação retorna imediatamente uma resposta "202 ACEITO". Este código confirma que o destinatário aceitou o pedido, mas não terminou o processamento. A resposta pode incluir um
locationcabeçalho que especifica o URI e um ID de atualização que o chamador pode usar para sondar ou verificar o status da solicitação assíncrona até que o recetor pare de processar e retorne uma resposta de sucesso "200 OK" ou outra resposta não 202. No entanto, o chamador não precisa esperar que a solicitação termine o processamento e pode continuar a executar a próxima ação. Para obter mais informações, consulte A integração assíncrona de microsserviços impõe a autonomia do microsserviço.Apátrida
Crie um fluxo de trabalho sem monitoração de estado quando não precisar manter, revisar ou fazer referência a dados de eventos anteriores no armazenamento externo após a conclusão de cada execução para revisão posterior. Esses fluxos de trabalho salvam todas as entradas e saídas para cada ação e seus estados apenas na memória, não no armazenamento externo. Como resultado, os fluxos de trabalho sem monitoração de estado têm execuções mais curtas que geralmente terminam em 5 minutos ou menos, desempenho mais rápido com tempos de resposta mais rápidos, taxa de transferência mais alta e custos de execução reduzidos porque o armazenamento externo não salva os detalhes e o histórico de execução do fluxo de trabalho. No entanto, se ocorrerem interrupções, as execuções interrompidas não serão restauradas automaticamente, portanto, o chamador precisará reenviar manualmente as execuções interrompidas.
Um fluxo de trabalho sem monitoração de estado fornece o melhor desempenho ao manipular dados ou conteúdo que não exceda 64 KB de tamanho total , como um arquivo. Tamanhos de conteúdo maiores, como vários anexos grandes, podem diminuir significativamente o desempenho do fluxo de trabalho ou até mesmo fazer com que ele falhe devido a exceções de falta de memória. Se o seu fluxo de trabalho tiver que lidar com tamanhos de conteúdo maiores, use um fluxo de trabalho com monitoração de estado.
Nota
Em fluxos de trabalho sem monitoração de estado, você só pode usar gatilhos de push quando não especificar um agendamento para execução do fluxo de trabalho. Esses gatilhos baseados em webhook aguardam que um evento aconteça ou que os dados fiquem disponíveis. Por exemplo, o gatilho Recorrência está disponível apenas para fluxos de trabalho com monitoração de estado. Para iniciar seu fluxo de trabalho, selecione um gatilho por push, como Solicitação, Hubs de Eventos ou gatilho do Service Bus. Para obter mais informações sobre gatilhos, ações e conectores limitados, indisponíveis ou sem suporte, consulte Recursos alterados, limitados, indisponíveis ou sem suporte.
Os fluxos de trabalho sem estado são executados apenas de forma síncrona, portanto, não usam o padrão de operação assíncrona padrão usado por fluxos de trabalho com monitoração de estado. Em vez disso, todas as ações baseadas em HTTP que retornam uma resposta "202 ACEITO" continuam para a próxima etapa na execução do fluxo de trabalho. Se a resposta incluir um
locationcabeçalho, um fluxo de trabalho sem estado não pesquisará o URI especificado para verificar o status. Para seguir o padrão de operação assíncrona padrão, use um fluxo de trabalho com monitoração de estado.Para facilitar a depuração, você pode habilitar o histórico de execução para um fluxo de trabalho sem monitoração de estado, o que tem algum impacto no desempenho, e desabilitar o histórico de execução quando terminar. Para obter mais informações, consulte Criar fluxos de trabalho baseados em locatário único no Visual Studio Code ou Criar fluxos de trabalho baseados em locatário único no portal do Azure.
Importante
Você precisa decidir sobre o tipo de fluxo de trabalho, com ou sem monitoração de estado, para implementar no momento da criação. Alterações no tipo de fluxo de trabalho após a criação resultam em erros de tempo de execução.
Diferenças de resumo entre fluxos de trabalho com e sem monitoração de estado
| Com monitorização de estado | Sem monitorização de estado |
|---|---|
| Armazena o histórico de execução, entradas e saídas | Não armazena histórico de execução, entradas ou saídas por padrão |
| Gatilhos de conector gerenciados estão disponíveis e são permitidos | Os gatilhos de conector gerenciado não estão disponíveis ou não são permitidos |
| Suporta fragmentação | Sem suporte para fragmentação |
| Suporta operações assíncronas | Sem suporte para operações assíncronas |
| Editar a duração máxima de execução padrão na configuração do host | Ideal para fluxos de trabalho com duração máxima inferior a 5 minutos |
| Lida com mensagens grandes | Ideal para lidar com mensagens pequenas (menos de 64 KB) |
Diferenças de comportamento aninhadas entre fluxos de trabalho com e sem monitoração de estado
Você pode tornar um fluxo de trabalho chamável de outros fluxos de trabalho que existem no mesmo aplicativo lógico padrão usando o gatilho Request, o gatilho HTTP Webhook ou os gatilhos de conector gerenciado que têm o tipo ApiConnectionWebhook e podem receber solicitações HTTPS.
A lista a seguir descreve os padrões de comportamento que os fluxos de trabalho aninhados podem seguir depois que um fluxo de trabalho pai chama um fluxo de trabalho filho:
Padrão de sondagem assíncrona
O fluxo de trabalho pai não espera que o fluxo de trabalho filho responda à chamada inicial. No entanto, o pai verifica continuamente o histórico de execução da criança até que ela termine de correr. Por padrão, os fluxos de trabalho com monitoração de estado seguem esse padrão, que é ideal para fluxos de trabalho filho de longa execução que podem exceder os limites de tempo limite de solicitação.
Padrão síncrono ("disparar e esquecer")
O fluxo de trabalho filho reconhece a chamada do fluxo de trabalho pai retornando imediatamente uma
202 ACCEPTEDresposta. No entanto, os pais não esperam que a criança devolva os resultados. Em vez disso, o pai continua para a próxima ação no fluxo de trabalho e recebe os resultados quando o filho termina a execução. Os fluxos de trabalho com monitoração de estado filho que não incluem uma ação Resposta sempre seguem o padrão síncrono e fornecem um histórico de execução para você revisar.Para habilitar esse comportamento, na definição JSON do fluxo de trabalho, defina a
operationOptionspropriedade comoDisableAsyncPattern. Para obter mais informações, consulte Tipos de gatilho e ação - Opções de operação.Acionar e esperar
Fluxos de trabalho sem estado são executados na memória. Assim, quando um fluxo de trabalho pai chama um fluxo de trabalho filho sem monitoração de estado, o pai aguarda uma resposta que retorna os resultados do filho. Esse padrão funciona de forma semelhante ao uso do gatilho ou ação HTTP interna para chamar um fluxo de trabalho filho. Os fluxos de trabalho filhos sem estado que não incluem uma ação Resposta retornam imediatamente uma
202 ACCEPTEDresposta, mas o pai aguarda a conclusão da criança antes de continuar para a próxima ação. Esses comportamentos se aplicam apenas a fluxos de trabalho filhos sem monitoração de estado.
A tabela a seguir identifica o comportamento do fluxo de trabalho filho com base no fato de o pai e o filho serem stateful, stateless ou serem tipos de fluxo de trabalho mistos. A lista após a tabela
| Fluxo de trabalho pai | Fluxo de trabalho filho | Comportamento infantil |
|---|---|---|
| Com monitorização de estado | Com monitorização de estado | Assíncrono ou síncrono com "operationOptions": "DisableAsyncPattern" configuração |
| Com monitorização de estado | Sem monitorização de estado | Acionar e esperar |
| Sem monitorização de estado | Com monitorização de estado | Synchronous (Síncrono) |
| Sem monitorização de estado | Sem monitorização de estado | Acionar e esperar |
Outros recursos de modelo de locatário único
O modelo de locatário único e o aplicativo lógico padrão incluem muitos recursos atuais e novos, por exemplo:
Crie aplicativos lógicos e seus fluxos de trabalho a partir de centenas de conectores gerenciados para aplicativos e serviços de Software como Serviço (SaaS) e Plataforma como Serviço (PaaS), além de conectores para sistemas locais.
Mais conectores gerenciados agora estão disponíveis como conectores integrados em fluxos de trabalho padrão. As versões internas são executadas nativamente no tempo de execução dos Aplicativos Lógicos do Azure de locatário único. Alguns conectores internos também são conhecidos informalmente como conectores do provedor de serviços. Para obter uma lista, consulte Conectores integrados em Consumo e Padrão.
Você pode criar seus próprios conectores internos personalizados para qualquer serviço necessário usando a estrutura de extensibilidade dos Aplicativos Lógicos do Azure de locatário único. Semelhante aos conectores internos, como o Barramento de Serviço do Azure e o SQL Server, os conectores internos personalizados fornecem maior taxa de transferência, baixa latência e conectividade local porque são executados no mesmo processo que o tempo de execução do locatário único. No entanto, os conectores internos personalizados não são semelhantes aos conectores gerenciados personalizados, que não são suportados atualmente. Para obter mais informações, consulte Visão geral do conector personalizado e Criar conectores internos personalizados para aplicativos lógicos padrão em aplicativos lógicos do Azure de locatário único.
Você pode usar as seguintes ações para Operações Líquidas e Operações XML sem uma conta de integração. Estas operações incluem as seguintes ações:
XML: Transformar XML e validação XML
Líquido: Transformar JSON em JSON, Transformar JSON em TEXT, Transformar XML em JSON e Transformar XML em texto
Nota
Para usar essas ações em fluxos de trabalho padrão, você precisa ter mapas líquidos, mapas XML ou esquemas XML. Você pode carregar esses artefatos no portal do Azure no menu de recursos do seu aplicativo lógico, em Artefatos, que inclui as seções Esquemas e Mapas . Ou, você pode adicionar esses artefatos à pasta Artefatos do seu projeto do Visual Studio Code usando as respetivas pastas Mapas e Esquemas. Em seguida, você pode usar esses artefatos em vários fluxos de trabalho dentro do mesmo aplicativo lógico.
Os fluxos de trabalho de aplicativos lógicos padrão podem ser executados em qualquer lugar porque os Aplicativos Lógicos do Azure geram cadeias de conexão SAS (Assinatura de Acesso Compartilhado) que esses aplicativos lógicos podem usar para enviar solicitações para o ponto de extremidade de tempo de execução da conexão em nuvem. Os Aplicativos Lógicos do Azure salvam essas cadeias de conexão com outras configurações de aplicativo para que você possa armazenar facilmente esses valores no Cofre da Chave do Azure quando implantar no Azure.
Os fluxos de trabalho de aplicativos lógicos padrão oferecem suporte à habilitação da identidade gerenciada atribuída pelo sistema e de várias identidades gerenciadas atribuídas pelo usuário ao mesmo tempo, embora você possa selecionar apenas uma identidade para usar de cada vez. Embora os conectores internos baseados em provedor de serviços ofereçam suporte ao uso da identidade atribuída pelo sistema, a maioria atualmente não oferece suporte à seleção de identidades gerenciadas atribuídas pelo usuário para autenticação, exceto para o SQL Server e os conectores HTTP.
Nota
Por padrão, a identidade atribuída ao sistema já está habilitada para autenticar conexões em tempo de execução. Essa identidade difere das credenciais de autenticação ou da cadeia de conexão que você usa ao criar uma conexão. Se você desabilitar essa identidade, as conexões não funcionarão em tempo de execução. Para exibir essa configuração, no menu do aplicativo lógico, em Configurações, selecione Identidade.
Você pode executar, testar e depurar localmente seus aplicativos lógicos e seus fluxos de trabalho no ambiente de desenvolvimento do Visual Studio Code.
Antes de executar e testar seu aplicativo lógico, você pode facilitar a depuração adicionando e usando pontos de interrupção dentro do arquivo workflow.json para um fluxo de trabalho. No entanto, os pontos de interrupção são suportados apenas para ações no momento, não para gatilhos. Para obter mais informações, consulte Criar fluxos de trabalho baseados em locatário único no Visual Studio Code.
Publique ou implante diretamente aplicativos lógicos e seus fluxos de trabalho do Visual Studio Code em vários ambientes de hospedagem, como os Aplicativos Lógicos habilitados para Azure e Azure Arc.
Habilite os recursos de log e rastreamento de diagnóstico para seu aplicativo lógico usando o Application Insights quando suportado por sua assinatura do Azure e configurações de aplicativo lógico.
Aceda a capacidades de rede, como ligar e integrar de forma privada com redes virtuais do Azure, semelhante ao Azure Functions quando cria e implementa as suas aplicações lógicas utilizando o plano Azure Functions Premium. Para obter mais informações, consulte a seguinte documentação:
Regenere chaves de acesso para conexões gerenciadas usadas por fluxos de trabalho individuais em um aplicativo lógico padrão . Para esta tarefa, siga as mesmas etapas para um aplicativo lógico de consumo , mas no nível do fluxo de trabalho, não no nível de recurso do aplicativo lógico.
Conectores integrados para Standard
Um fluxo de trabalho padrão pode usar muitos dos mesmos conectores internos que um fluxo de trabalho de Consumo, mas não todos. Vice-versa, um fluxo de trabalho padrão tem muitos conectores internos que não estão disponíveis em um fluxo de trabalho de Consumo.
Por exemplo, um fluxo de trabalho Standard tem conectores gerenciados e conectores internos para Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server e outros. Embora um fluxo de trabalho de Consumo não tenha essas mesmas versões de conector interno, outros conectores internos, como o Gerenciamento de API do Azure e os Serviços de Aplicativo do Azure, estão disponíveis.
Nos Aplicativos Lógicos do Azure de locatário único, os conectores internos com atributos específicos são conhecidos informalmente como provedores de serviços. Alguns conectores internos suportam apenas uma única maneira de autenticar uma conexão com o serviço subjacente. Outros conectores internos podem oferecer uma escolha, como usar uma cadeia de conexão, ID do Microsoft Entra ou uma identidade gerenciada. Todos os conectores internos são executados no mesmo processo que o tempo de execução redesenhado dos Aplicativos Lógicos do Azure. Para obter mais informações, consulte a lista de conectores interna para fluxos de trabalho de aplicativos lógicos padrão.
Importante
Certifique-se de configurar e testar corretamente qualquer gatilho baseado em provedor de serviços para confirmar a operação bem-sucedida. Um gatilho baseado em provedor de serviços com falha pode criar dimensionamento desnecessário, o que pode aumentar drasticamente seus custos de cobrança. Por exemplo, um erro comum é definir um gatilho sem dar permissão ao seu aplicativo lógico ou acesso ao destino, como uma fila do Barramento de Serviço, contêiner de blob de Armazenamento do Azure e assim por diante. Além disso, certifique-se de monitorar esses gatilhos o tempo todo para que você possa detetar e corrigir prontamente quaisquer problemas.
Recursos alterados, limitados, indisponíveis ou sem suporte
Para o fluxo de trabalho do aplicativo lógico padrão , esses recursos foram alterados ou estão atualmente limitados, indisponíveis ou sem suporte:
Gatilhos e ações: gatilhos e ações internos são executados nativamente nos Aplicativos Lógicos do Azure, enquanto os conectores gerenciados são hospedados e executados usando recursos compartilhados no Azure. Para fluxos de trabalho padrão, alguns gatilhos e ações internos estão atualmente indisponíveis, como Janela Deslizante, Serviço de Aplicativo do Azure e Gerenciamento de API do Azure. Para iniciar um fluxo de trabalho com ou sem monitoração de estado, use um gatilho interno, como o gatilho Solicitação, Hubs de Eventos ou Service Bus. O gatilho de Recorrência está disponível para fluxos de trabalho com monitoração de estado, mas não para fluxos de trabalho sem monitoração de estado. No designer, gatilhos e ações internos aparecem com o rótulo no aplicativo , enquanto os gatilhos e ações do conector gerenciado aparecem com o rótulo compartilhado .
Os fluxos de trabalho sem estado podem usar apenas gatilhos de push nos quais você não especifica um cronograma para execução do fluxo de trabalho. Esses gatilhos baseados em webhook aguardam que um evento aconteça ou que os dados fiquem disponíveis. Por exemplo, o gatilho Recorrência está disponível apenas para fluxos de trabalho com monitoração de estado. Para iniciar seu fluxo de trabalho, selecione um gatilho por push, como Solicitação, Hubs de Eventos ou gatilho do Service Bus. Embora você possa habilitar conectores gerenciados para fluxos de trabalho sem monitoração de estado, a galeria de conectores não mostra nenhum gatilho de sondagem de conector gerenciado para você adicionar.
Nota
Para executar localmente no Visual Studio Code, gatilhos e ações baseados em webhook exigem configuração adicional. Para obter mais informações, consulte Criar fluxos de trabalho baseados em locatário único no Visual Studio Code.
Os seguintes gatilhos e ações foram alterados ou estão atualmente limitados, sem suporte ou indisponíveis:
A ação interna, Azure Functions - Choose an Azure function is now Azure Functions Operations - Call an Azure function. Atualmente, essa ação funciona apenas para funções criadas a partir do modelo HTTP Trigger .
No portal do Azure, você pode selecionar uma função de gatilho HTTP que pode ser acessada criando uma conexão por meio da experiência do usuário. Se você inspecionar a definição JSON da ação de função no modo de exibição de código ou o arquivo de workflow.json usando o Visual Studio Code, a ação se refere à função usando uma
connectionNamereferência. Esta versão abstrai as informações da função como uma conexão, que você pode encontrar no arquivo de connections.json do seu projeto de aplicativo lógico, que está disponível depois de criar uma conexão no Visual Studio Code.Nota
No modelo de locatário único, a ação de função suporta apenas a autenticação de cadeia de caracteres de consulta. Os Aplicativos Lógicos do Azure obtêm a chave padrão da função ao fazer a conexão, armazenam essa chave nas configurações do seu aplicativo e usam a chave para autenticação ao chamar a função.
Como no modelo multilocatário, se você renovar essa chave, por exemplo, por meio da experiência do Azure Functions no portal, a ação da função não funcionará mais devido à chave inválida. Para corrigir esse problema, você precisa recriar a conexão com a função que deseja chamar ou atualizar as configurações do aplicativo com a nova chave.
A ação interna, Inline Code, é renomeada Inline Code Operations, não requer mais uma conta de integração e tem limites atualizados.
A ação interna, Aplicativos Lógicos do Azure - Escolha um fluxo de trabalho do Aplicativo Lógico agora é Operações de Fluxo de Trabalho - Invoque um fluxo de trabalho neste aplicativo de fluxo de trabalho.
Atualmente, o conector do Gmail não é compatível.
Atualmente, não há suporte para conectores gerenciados personalizados . No entanto, você pode criar operações internas personalizadas quando você usa o Visual Studio Code. Para obter mais informações, consulte Criar fluxos de trabalho baseados em locatário único usando o Visual Studio Code.
Um fluxo de trabalho de aplicativo lógico padrão pode ter apenas um gatilho e não suporta vários gatilhos.
Autenticação: Os seguintes tipos de autenticação estão atualmente indisponíveis para fluxos de trabalho padrão :
Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) para chamadas de entrada para gatilhos baseados em solicitação, como o gatilho Request e o gatilho HTTP Webhook.
Autenticação de identidade gerenciada: O suporte a identidades gerenciadas atribuído pelo sistema e pelo usuário está disponível. Por padrão, a identidade gerenciada atribuída ao sistema é ativada automaticamente. No entanto, a maioria dos conectores internos baseados em provedor de serviços atualmente não oferece suporte à seleção de identidades gerenciadas atribuídas pelo usuário para autenticação.
Transformação XML: Atualmente, apenas XSLT 1.0 é suportado.
Depuração de ponto de interrupção no Visual Studio Code: Embora você possa adicionar e usar pontos de interrupção dentro do arquivo de workflow.json para um fluxo de trabalho, os pontos de interrupção são suportados apenas para ações no momento, não para gatilhos. Para obter mais informações, consulte Criar fluxos de trabalho baseados em locatário único no Visual Studio Code.
Histórico de gatilhos e histórico de execução: para um aplicativo lógico padrão , o histórico de gatilhos e o histórico de execução no portal do Azure aparecem no nível do fluxo de trabalho, não no nível de recurso do aplicativo lógico. Para obter mais informações, consulte Criar fluxos de trabalho baseados em locatário único usando o portal do Azure.
Backup e restauração para o histórico de execução do fluxo de trabalho: os aplicativos lógicos padrão atualmente não oferecem suporte a backup e restauração para o histórico de execução do fluxo de trabalho.
Modelos Terraform: não é possível usar esses modelos com um recurso de aplicativo lógico padrão para implantação completa da infraestrutura. Para obter mais informações, consulte O que é Terraform no Azure?
Gerenciamento de API do Azure: no momento, não é possível importar um recurso de aplicativo lógico padrão para o Gerenciamento de API do Azure. No entanto, você pode importar um recurso de aplicativo lógico de consumo .
Permissões rígidas de tráfego de rede e firewall
Se o seu ambiente tiver requisitos de rede rigorosos ou firewalls que limitem o tráfego, você terá que permitir o acesso para quaisquer conexões de gatilho ou ação em seus fluxos de trabalho. Opcionalmente, você pode permitir o tráfego de tags de serviço e usar o mesmo nível de restrições ou políticas que o Serviço de Aplicativo do Azure. Você também precisa encontrar e usar os FQDNs (nomes de domínio totalmente qualificados) para suas conexões. Para obter mais informações, revise as seções correspondentes na documentação a seguir:
- Permissões de firewall para aplicativos lógicos de locatário único - Portal do Azure
- Permissões de firewall para aplicativos lógicos de locatário único - Visual Studio Code
Próximos passos
- Criar fluxos de trabalho baseados em inquilino único no portal do Azure
- Criar fluxos de trabalho baseados em locatário único no Visual Studio Code
Também gostaríamos de saber mais sobre suas experiências com os Aplicativos Lógicos do Azure de locatário único!
- Para bugs ou problemas, crie seus problemas no GitHub.
- Para perguntas, solicitações, comentários e outros comentários, use este formulário de feedback.