Diferenças entre aplicativos lógicos de locatário único Standard e aplicativos lógicos multilocatário de Consumo
Os Aplicativos Lógicos do Azure são uma plataforma baseada em nuvem usada para criar e executar fluxos de trabalho de aplicativo lógico automatizados que integram aplicativos, dados, serviços e sistemas. Com essa plataforma, você pode desenvolver rapidamente soluções de integração altamente escalonáveis para seus cenários empresariais e B2B (entre empresas). Ao criar um recurso de aplicativo lógico, você seleciona a opção de hospedagem de Consumo ou Standard. 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 Standard pode ter um ou vários fluxos de trabalho executados nos Aplicativos Lógicos do Azure de locatário único ou em um ASE (Ambiente do Serviço de Aplicativo) v3.
Antes de escolher qual recurso de aplicativo lógico você vai criar, confira o guia a seguir para ver uma comparação entre os tipos de fluxos de trabalho do aplicativo lógico. Depois, você pode tomar uma decisão melhor sobre qual ambiente e fluxo de trabalho de aplicativo lógico melhor se adequam ao seu cenário, aos requisitos de solução e ao destino onde você deseja implantar e executar seus fluxos de trabalho.
Se você não estiver familiarizado com os 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 Standard. Você também aprenderá como o ambiente de locatário único é diferente do ambiente multilocatário para implantar, hospedar e executar seus fluxos de trabalho.
| Opção de hospedagem | Benefícios | Uso e compartilhamento de recursos | Modelo de preço e cobrança | Gerenciamento de limites |
|---|---|---|---|---|
| Consumo Ambiente de host: Aplicativos Lógicos do Azure multilocatário |
– Mais fácil de começar a usar – Pague apenas pelo que você usar – Totalmente gerenciado |
Um recurso de aplicativo lógico individual pode ter apenas um fluxo de trabalho. Todos os aplicativos lógicos nos locatários do Microsoft Entra compartilham o mesmo processamento (computação), armazenamento, rede etc. Para fins de redundância, os dados são replicados na região emparelhada. Para alta disponibilidade, o GRS (armazenamento com redundância geográfica) está habilitado. |
Consumo (pagamento por execução) | Os Aplicativos Lógicos do Azure gerenciam os valores padrão desses 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 host: Aplicativos Lógicos do Azure de locatário único Observação: se 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, confira O que são Aplicativos Lógicos habilitados para Azure Arc? |
– Mais conectores internos hospedados no runtime de locatário único para maior taxa de transferência e custos mais baixos em escala – Mais controle e funcionalidade de ajuste em relação às configurações de runtime e desempenho – Suporte integrado para redes virtuais e pontos de extremidade privados. – Crie seus próprios conectores integrados. |
Um recurso de aplicativo lógico individual pode ter vários fluxos de trabalho com estado 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 em que você implanta seu aplicativo lógico. |
Standard, com base em um plano de hospedagem com um tipo de preço selecionado. Se você executar fluxos de trabalho com estado, que usam armazenamento externo, o runtime dos Aplicativos Lógicos do Azure farão as transações de armazenamento que acompanham o preço do Armazenamento do Azure. |
Você pode alterar os valores padrão para muitos limites com base nas necessidades do cenário. Importante: alguns limites têm máximos rígidos. No Visual Studio Code, as alterações feitas nos valores de limite padrão nos arquivos de configuração do projeto do aplicativo lógico não serão exibidas na experiência do designer. Para obter mais informações, confira Editar configurações de aplicativo e ambiente para aplicativos lógicos nos Aplicativos Lógicos do Azure de locatário único. |
| Standard (Ambiente do Serviço de Aplicativo v3) Ambiente de host: ASEv3 (Ambiente do Serviço de Aplicativo v3) – Somente planos do Windows |
Alguns recursos como locatário único mais estes benefícios: – Isole totalmente seus aplicativos lógicos. – Crie e execute mais aplicativos lógicos do que nos Aplicativos Lógicos do Azure de locatário único. – Pague apenas pelo plano do Serviço de Aplicativo do ASE, independentemente do número de aplicativos lógicos que você criar e executar. – Possibilidade de habilitar o dimensionamento automático ou de dimensionar manualmente com mais instâncias de máquina virtual ou um plano do Serviço de Aplicativo diferente. – Herde a configuração de rede do ASEv3 selecionado. Por exemplo, quando você faz a implantação 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. Observação: se acessado de fora de um ASE interno, os históricos de execução dos fluxos de trabalho nesse ASE não poderão acessar entradas e saídas de ação. |
Um único aplicativo lógico pode ter vários fluxos de trabalho com estado e sem 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 continuam na mesma região em que você implanta os aplicativos lógicos. |
Plano do Serviço de Aplicativo | Você pode alterar os valores padrão para muitos limites com base nas necessidades do cenário. Importante: alguns limites têm máximos rígidos. No Visual Studio Code, as alterações feitas nos valores de limite padrão nos arquivos de configuração do projeto do aplicativo lógico não serão exibidas na experiência do designer. Para obter mais informações, confira Editar configurações de aplicativo e ambiente para aplicativos lógicos nos Aplicativos Lógicos do Azure de locatário único. |
Fluxo de trabalho e aplicativo lógico padrão
O fluxo de trabalho e aplicativo lógico Padrão é da plataforma do runtime dos Aplicativos Lógicos do Azure de locatário único reformulado. Esse runtime usa o modelo de extensibilidade do Azure Functions e é hospedado como uma extensão no runtime do Azure Functions. Esse design oferece portabilidade, flexibilidade e melhor desempenho para os fluxos de trabalho dos aplicativos lógicos, além de outras funcionalidades e recursos herdados da plataforma do 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 Standard apresenta uma estrutura de recursos que pode hospedar vários fluxos de trabalho, de maneira semelhante a como um aplicativo de funções do Azure pode hospedar várias funções. Com um mapeamento de um para muitos, os fluxos de trabalho no mesmo aplicativo lógico e locatário compartilham recursos de computação e processamento, fornecendo melhor desempenho devido à proximidade entre eles. Essa estrutura é diferente do recurso do aplicativo lógico de Consumo, em que você tem um mapeamento individual entre um recurso de aplicativo lógico e um fluxo de trabalho.
Para saber mais sobre a portabilidade, flexibilidade e melhorias de desempenho, confira as seções a seguir. Para saber mais sobre o runtime dos Aplicativos Lógicos do Azure de locatário único e a extensibilidade do Azure Functions, leia a seguinte documentação:
- Execução dos Aplicativos Lógicos do Azure em Qualquer Lugar - Aprofundamento em Runtime
- Introdução ao Azure Functions
- Gatilhos e associações de Azure Functions
Portabilidade e flexibilidade
Ao criar um fluxo de trabalho e aplicativo lógico Padrão, você poderá 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 dos Aplicativos Lógicos do Azure (Padrão), poderá desenvolver, compilar e executar seu fluxo de trabalho localmente em seu ambiente de desenvolvimento sem precisar implantar no Azure. Se seu cenário exigir contêineres, você pode criar aplicativos lógicos de locatário único usando os Aplicativos Lógicos habilitados para Azure Arc. Para saber mais, acesse O que são os Aplicativos Lógicos habilitados para Azure Arc?
Essas funcionalidades proporcionam grandes aprimoramentos e benefícios substanciais em comparação com o modelo multilocatário, que exige que você faça o desenvolvimento em um recurso existente em execução no Azure. O modelo multilocatário para automatizar a implantação de recursos de aplicativo lógico de Consumo é baseado em modelos do ARM (modelos do Azure Resource Manager), que combinam e processam o provisionamento de recursos para os aplicativos e a infraestrutura.
Com o recurso do aplicativo lógico Padrão, a implantação fica mais fácil porque você pode separar a implantação do aplicativo da implantação da infraestrutura. Você pode empacotar os fluxos de trabalho e o runtime dos Aplicativos Lógicos do Azure de locatário único como parte do recurso ou projeto do seu aplicativo lógico. Você pode usar tarefas ou etapas genéricas que criam, montam e compactam os recursos do aplicativo lógico em artefatos prontos para implantação. Para implantar a infraestrutura, você ainda pode usar modelos do ARM para provisionar separadamente esses recursos com outros processos e pipelines usados para essas finalidades.
Para implantar o aplicativo, copie os artefatos para o ambiente de host e inicie os aplicativos para executar os fluxos de trabalho. Ou integre os artefatos em pipelines de implantação usando as ferramentas e os processos que você já conhece e usa. Dessa forma, você pode implantar usando ferramentas de sua escolha, independentemente da pilha de tecnologia usada para desenvolvimento.
Usando as opções padrão de build e implantação, você pode se concentrar no desenvolvimento dos aplicativos separadamente da implantação da infraestrutura. Como resultado, você terá um modelo de projeto mais genérico em que poderá aplicar muitas opções de implantação semelhantes ou idênticas às que 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 quando executa os testes e as validações necessárias antes de publicar para 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 do aplicativo lógico. Com esse mapeamento de um para muitos, os fluxos de trabalho compartilham recursos como computação, processamento, armazenamento e rede, apresentando melhor desempenho devido à proximidade entre eles.
O recurso do aplicativo lógico Padrão e o runtime dos Aplicativos Lógicos do Azure de locatário único fornecem outro aprimoramento significativo ao disponibilizar os conectores gerenciados mais populares como operações de conectores internos. Por exemplo, você pode usar operações de conectores internos para o Barramento de Serviço do Azure, os Hubs de Eventos do Azure, o SQL Server, entre outros. Enquanto isso, as versões do conector gerenciado ainda estão disponíveis e continuam funcionando.
Quando usa as novas operações de conectores internos, você cria conexões chamadas conexões internas ou conexões do provedor de serviço. As contrapartes de conexão gerenciada 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 do ARM. As operações internas e as respectivas conexões são executadas localmente no mesmo processo que executa os fluxos de trabalho. Ambas são hospedadas no runtime dos Aplicativos Lógicos do Azure de locatário único. Como resultado, as operações internas e as respectivas conexões fornecem melhor desempenho devido à proximidade com os fluxos de trabalho. Esse design também funciona bem com pipelines de implantação porque as conexões do provedor de serviço são empacotadas no mesmo artefato de compilação.
Residência de dadosResidência de dados
Os recursos do aplicativo lógico Padrão são hospedados nos Aplicativos Lógicos do Azure de locatário único, que não armazena, processa ou replica dados fora da região em que você implanta os recursos de aplicativo lógico, significando que os dados em seus fluxos de trabalho permanecem na mesma região em que você criou e implantou os recursos pai.
Acesso direto a recursos em redes virtuais do Azure
Os fluxos de trabalho em execução nos Aplicativos Lógicos do Azure de locatário único podem acessar diretamente recursos protegidos como VMs (máquinas virtuais), 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 instâncias dedicadas do serviço de 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 sobre o desempenho dos aplicativos, também conhecido como o efeito dos "vizinhos barulhentos".
Os Aplicativos Lógicos do Azure de locatário único também oferecem os seguintes benefícios:
Seus endereços IP estáticos, que são separados dos endereços IP estáticos 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 adicionais do firewall nesses sistemas de destino.
Aumento dos limites de duração da execução, retenção de armazenamento, taxa de transferência, tempos limite de solicitação e resposta HTTP, tamanhos de mensagem e solicitações de conector personalizado. Para obter mais informações, examine Limites e configuração dos Aplicativos Lógicos do Azure.
Opções de criação, compilação e implantação
Para criar um recurso de aplicativo lógico com base no ambiente desejado, você tem várias opções, por exemplo:
Ambiente de locatário único
Ambientes de multilocatário
Embora as experiências de desenvolvimento variem quando você cria recursos de aplicativo lógico de Consumo ou Standard, você pode encontrar e acessar todos os aplicativos lógicos implantados em sua assinatura do Azure.
Por exemplo, no portal do Azure, a página Aplicativos lógicos mostra os recursos de aplicativo lógico de 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 estado
Em um aplicativo lógico Padrão, você pode criar os seguintes tipos de fluxo de trabalho:
Com estado
Crie um fluxo de trabalho com estado quando precisar manter, revisar ou referenciar 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. Fluxos de trabalho com estado fornecem alta resiliência no caso de interrupções. Depois que os serviços e sistemas forem restaurados, é possível reconstruir as execuções interrompidas a partir do estado salvo, e executar novamente os fluxos de trabalho até a conclusão. Fluxos de trabalho com estado podem continuar em execução por muito mais tempo do que fluxos de trabalho sem estado.
Por padrão, os fluxos de trabalho com estado nos Aplicativos Lógicos do Azure de locatário único e multilocatário são executados de modo assíncrono. 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". Esse código confirma que o destinatário aceitou a solicitação, mas não concluiu o processamento. A resposta pode incluir um cabeçalho
locationque especifica o URI e uma ID de atualização que o autor da chamada pode usar para sondar ou verificar o status da solicitação assíncrona até que o destinatário pare de processar e retorne uma resposta de sucesso "200 OK" ou outra resposta não 202. No entanto, o autor da chamada não precisa esperar o processamento da solicitação. Ele pode continuar e executar a próxima ação. Para saber mais, confira A integração assíncrona de microsserviço impõe autonomia de microsserviço.Sem estado
Crie um fluxo de trabalho sem estado quando não for necessário manter, revisar ou referenciar dados de eventos anteriores no armazenamento externo após o término de cada execução para revisão posterior. Esses fluxos de trabalho salvam todas as entradas e saídas de cada ação e seus estados na memória apenas, não em armazenamento externo. Como resultado, fluxos de trabalho sem estado têm execuções mais curtas que normalmente terminam em 5 minutos ou menos, desempenho mais ágil com tempos de resposta mais rápidos, maior taxa de transferência 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 são automaticamente restauradas, então o chamador precisa reenviá-las manualmente.
Um fluxo de trabalho sem estado fornece o melhor desempenho ao manipular dados ou conteúdo que não excede 64 KB no tamanho total, como um arquivo. Tamanhos de conteúdo maiores, como vários anexos grandes, podem reduzir significativamente o desempenho do fluxo de trabalho ou até mesmo fazer com que o fluxo de trabalho falhe devido a exceções por memória insuficiente. Se seu fluxo de trabalho pode precisar lidar com tamanhos de conteúdo maiores, então use um fluxo de trabalho com estado.
Observação
Em fluxos de trabalho sem estado, você só pode usar gatilhos por push quando não especificar um agendamento para executar seu fluxo de trabalho. Esses gatilhos baseados em webhook esperam 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 estado. Para iniciar seu fluxo de trabalho, selecione um gatilho de push como o gatilho de Solicitação, Hubs de Eventos ou Barramento de Serviço. 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 de forma síncrona somente, para que não usem o padrão de operação assíncrona padrão usado por fluxos de trabalho com 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 cabeçalho
location, um fluxo de trabalho sem estado não sondará 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 estado.Para uma depuração mais fácil, você pode habilitar o histórico de execuções para um fluxo de trabalho sem estado — isso vai gerar algum impacto sobre o desempenho — e desabilitar o histórico de execução quando terminar. Para saber mais, confira 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 o tipo de fluxo de trabalho, com estado ou sem 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 runtime.
Diferenças resumidas de comportamento entre os fluxos de trabalho com e sem estado
| Com estado | Sem estado |
|---|---|
| Armazena o histórico de execuções, as entradas e as saídas | Não armazena o histórico de execuções, as entradas ou as saídas por padrão |
| Os gatilhos de conector gerenciado estão disponíveis e são permitidos | Os gatilhos do conector gerenciado não estão disponíveis ou não são permitidos |
| Há suporte para partes | Não há suporte para partes |
| Há suporte para operações assíncronas | Não há suporte para operações assíncronas |
| Duração de execução máxima padrão de edição na configuração do host | Melhor para fluxos de trabalho com duração máxima inferior a cinco minutos |
| Lida com mensagens grandes | Melhor para lidar com tamanhos de mensagem pequenos (inferiores a 64 KB) |
Diferenças de comportamento aninhado entre os fluxos de trabalho com e sem estado
É possível fazer com que um fluxo de trabalho possa ser chamado por outros fluxos de trabalho existentes no mesmo aplicativo lógico Padrão usando o Gatilho de solicitação, o Gatilho de Webhook HTTP ou gatilhos de conector gerenciado que tenham o tipo ApiConnectionWebhook e possam 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 aguarda o fluxo de trabalho filho responder à chamada inicial. No entanto, o pai verifica continuamente o histórico de execução do filho até que o filho conclua a execução. Por padrão, os fluxos de trabalho com estado seguem esse modelo, que é ideal para fluxos de trabalho filho de longa execução que possam exceder o tempo limite da 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 resposta
202 ACCEPTED. No entanto, o pai não espera que o filho retorne os resultados. Em vez disso, o pai continua na próxima ação no fluxo de trabalho e recebe os resultados quando o filho concluir a execução. Fluxos de trabalho com estado filho que não incluem uma ação de resposta sempre seguem o padrão síncrono e fornecem um histórico de execução para você revisar.Para habilitar esse comportamento, defina a propriedade
operationOptionscomoDisableAsyncPatternna definição JSON do fluxo de trabalho. Para obter mais informações, consulte Gatilho e tipos de ação – Opções de operação.Gatilho e espera
Fluxos de trabalho sem estado são executados na memória. Assim, quando um fluxo de trabalho pai chamar um fluxo de trabalho filho sem estado, o pai espera por uma resposta que retorna os resultados do filho. Esse padrão funciona de forma semelhante ao uso do gatilho ou ação HTTP interno para chamar um fluxo de trabalho filho. Fluxos de trabalho filho sem estado que não incluam uma ação de resposta retornam imediatamente uma resposta
202 ACCEPTED, mas o pai espera que o filho termine antes de continuar para a próxima ação. Esses comportamentos se aplicam somente a fluxos de trabalho filho sem estado.
A tabela a seguir identifica o comportamento do fluxo de trabalho filho baseando-se no fato de o pai e o filho serem com estado, sem estado, ou se são tipos de fluxo de trabalho mistos. A lista após a tabela
| Fluxo de trabalho pai | Fluxo de trabalho filho | Comportamento do filho |
|---|---|---|
| Com estado | Com estado | Assíncrono ou síncrono com configuração "operationOptions": "DisableAsyncPattern" |
| Com estado | Sem estado | Gatilho e espera |
| Sem estado | Com estado | Síncrono |
| Sem estado | Sem estado | Gatilho e espera |
Outros recursos de modelo de locatário único
O modelo de locatário único e o aplicativo lógico Padrão incluem muitos recursos novos e atuais, por exemplo:
Crie aplicativos lógicos e seus fluxos de trabalho a partir de 1.400+ conectores gerenciados para aplicativos e serviços de SaaS (software como serviço) e PaaS (plataforma como serviço), além de conectores para sistemas locais.
Mais conectores gerenciados já estão disponíveis como conectores internos nos fluxos de trabalho Padrão. As versões internas são executadas nativamente no runtime dos Aplicativos Lógicos do Azure de locatário único. Alguns conectores internos também são informalmente conhecidos como conectores do provedor de serviços. Para obter uma lista, examine Conectores internos em Consumo e Standard.
Você pode criar seus conectores internos personalizados para qualquer serviço que precisar usando a estrutura de extensibilidade dos Aplicativos Lógicos do Azure de locatário único. De maneira semelhante a 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 runtime de locatário único. No entanto, conectores internos personalizados não são semelhantes aos conectores gerenciados personalizados, que não têm suporte no momento. Para obter mais informações, leia Visão geral do conector personalizado e Criar conectores internos personalizados para aplicativos lógicos Standard em Aplicativos Lógicos do Azure de locatário único.
Você pode usar as ações a seguir para Operações Liquid e XML sem uma conta de integração. Essas operações incluem as seguintes ações:
XML: Transformar XML, Validação de XML, Composição de XML com esquema e Análise XML com esquema
Liquid: Transformar JSON em JSON, Transformar JSON em TEXTO, Transformar XML em JSONe Transformar XML em texto
Observação
Para usar essas ações em fluxos de trabalho Padrão, você precisa ter mapas líquidos, mapas XML ou esquemas XML. É possível carregar esses artefatos no portal do Azure do menu de recursos do aplicativo lógico, em Artefatos, que inclui os Esquemas e as seções de Mapas. Ou, você pode adicionar esses artefatos à pasta Artifacts do projeto do Visual Studio Code usando as pastas Mapas e Esquemas correspondentes. É possível usar esses artefatos em vários fluxos de trabalho dentro do mesmo aplicativo lógico.
Os fluxos de trabalho do aplicativo lógico Standard podem ser disparados de 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 runtime de conexão de 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 Azure Key Vault ao implantar no Azure.
Os fluxos de trabalho de aplicativo lógico Padrão dão 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 por vez. Embora conectores internos baseados em provedor de serviços ofereçam suporte ao uso da identidade atribuída pelo sistema, a maioria atualmente não dá suporte à seleção de identidades gerenciadas atribuídas pelo usuário para autenticação, exceto para o SQL Server e os conectores HTTP.
Observação
Por padrão, a identidade atribuída pelo sistema já está habilitada para autenticar conexões no 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 no runtime. Para exibir essa configuração, no menu do aplicativo lógico, em Configurações, selecione Identidade.
Execute, teste e depure localmente aplicativos lógicos e 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.jsno para um fluxo de trabalho. Mas neste momento os pontos de interrupção têm suporte apenas para ações, não para gatilhos. Para obter mais informações, confira Criar fluxos de trabalho baseados em locatário único no Visual Studio Code.
Publique ou implante diretamente aplicativos lógicos e os fluxos de trabalho deles do Visual Studio Code para vários ambientes de hospedagem, como o Azure e Aplicativos Lógicos habilitados para Azure Arc.
Habilite o log de diagnóstico e as funcionalidades de rastreamento para seu aplicativo lógico usando o Application insights quando houver suporte para suas configurações de aplicativo lógico e sua assinatura do Azure.
Acesse recursos de rede, como conexão e integração privada com redes virtuais do Azure, semelhante ao Azure Functions, quando criar e implantar seus aplicativos lógicos usando o Azure Functions Premium. Para obter mais informações, examine 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 essa tarefa, siga as mesmas etapas para o aplicativo lógico de Consumo), mas no nível do fluxo de trabalho, e não no nível do recurso do aplicativo lógico.
Conectores internos da camada 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 Padrão tem conectores gerenciados e conectores internos para o Blob do Azure, o Azure Cosmos DB, os Hubs de Eventos do Azure, o Barramento de Serviço do Azure, o DB2, o FTP, o MQ, o SFTP, o SQL Server e outros. Embora um fluxo de trabalho de Consumo não tenha essas mesmas versões internas do conector, outros conectores internos, como o Gerenciamento de API do Azure e os Serviços de Aplicativos do Azure, estão disponíveis.
Em Aplicativos Lógicos do Azure de locatário único, conectores internos com atributos específicos são informalmente conhecidos como provedores de serviços. Alguns conectores internos dão suporte a apenas uma maneira de autenticar uma conexão com o serviço subjacente. Outros conectores internos podem oferecer uma opção, como usar uma cadeia de conexão, o Microsoft Entra ID ou uma identidade gerenciada. Todos os conectores internos são executados no mesmo processo do runtime reprojetado dos Aplicativos Lógicos do Azure. Para obter mais informações, veja a lista de conectores internos para fluxos de trabalho de aplicativo lógico Standard.
Importante
Certifique-se de configurar e testar corretamente qualquer gatilho baseado no provedor de serviços para confirmar a operação bem-sucedida. Um gatilho baseado no provedor de serviços com falha pode criar dimensionamento desnecessário, o que pode aumentar muito os custos de cobrança. Por exemplo, um erro comum é definir um gatilho sem conceder a permissão de aplicativo lógico ou o acesso ao destino, como uma fila do Barramento de Serviço, um 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 detectar e corrigir rapidamente quaisquer problemas.
Recursos alterados, limitados, indisponíveis ou sem suporte
Para o fluxo de trabalho do aplicativo lógico Padrão, os seguintes recursos são diferentes, atualmente limitados, indisponíveis ou sem suporte:
Gatilhos e ações: gatilhos e ações internas são executados de maneira nativa nos Aplicativos Lógicos do Azure, enquanto conectores gerenciados são hospedados e executados usando recursos compartilhados no Azure. Para fluxos de trabalho Standard, alguns gatilhos e ações internos não estão disponíveis no momento, como operações de Janela Deslizante e Serviço de Aplicativo do Azure. Para iniciar um fluxo de trabalho com ou sem estado, use o gatilho interno como o gatilho de Solicitação, Hubs de Eventos ou Barramento de Serviço. O gatilho de Recorrência está disponível para fluxos de trabalho com estado, mas está para fluxos de trabalho sem estado. No designer, os 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 só podem usar gatilhos por push quando você não especificar um agendamento para executar seu fluxo de trabalho. Esses gatilhos baseados em webhook esperam 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 estado. Para iniciar seu fluxo de trabalho, selecione um gatilho de push como o gatilho de Solicitação, Hubs de Eventos ou Barramento de Serviço. Embora você possa habilitar conectores gerenciados para fluxos de trabalho sem estado, a galeria de conectores não mostra nenhum gatilho de sondagem de conector gerenciado para você adicionar.
Observação
Os gatilhos e as ações baseadas em webhook precisam de configuração adicional para executar localmente no Visual Studio Code. Para obter mais informações, confira 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, não possuem suporte ou não estão disponíveis:
A ação interna Azure Functions — Escolha uma função do Azure passou a se chamar Operações do Azure Functions — Chame uma Função do Azure. Atualmente, essa ação funciona apenas para funções criadas a partir do modelo de gatilho HTTP.
No portal do Azure, você pode selecionar uma função de gatilho HTTP a que tenha acesso criando uma conexão por meio da experiência do usuário. Se você inspecionar a definição JSON da ação da função na exibição de código ou no arquivo workflow.json no Visual Studio Code, a ação fará referência à função usando uma referência
connectionName. Essa versão abstrai as informações da função como uma conexão, que pode ser encontrada no arquivo connections.json do projeto do aplicativo lógico, que fica disponível após você criar uma conexão no Visual Studio Code.Observação
No modelo de locatário único, a ação da função dá suporte apenas à autenticação da cadeia 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 aplicativo e a usam para autenticação ao chamar a função.
Assim como ocorre com o modelo multilocatário, se você renovar essa chave, por exemplo, por meio da experiência do Azure Functions no portal, a ação de 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 de Código embutido interna passou a ser chamada de Operações de código embutido, não requer mais uma conta de integração e tem limites atualizados.
A ação interna, Aplicativos Lógicos do Azure -Escolher um fluxo de trabalho de Aplicativo Lógico agora é Operações de Fluxo de Trabalho – Invocar um fluxo de trabalho neste aplicativo de fluxo de trabalho.
Atualmente, não há suporte para conectores gerenciados personalizados. No entanto, você pode criar operações internas personalizadas ao usar o Visual Studio Code. Para obter mais informações, confira Criar fluxos de trabalho baseados em locatário único usando o Visual Studio Code.
Um fluxo de trabalho Standard pode ter apenas um gatilho e não dá suporte a vários gatilhos.
Autenticação
Alguns gatilhos baseados em solicitação que lidam com chamadas de entrada, como o gatilho de solicitação, atualmente não dão suporte à Autenticação Aberta do Microsoft Entra ID (Microsoft Entra ID OAuth), enquanto outros, como o gatilho de Webhook HTTP, têm esse suporte.
Alguns conectores internos baseados em provedor de serviços atualmente não dão suporte à seleção da identidade gerenciada atribuída pelo usuário para autenticação. No entanto, o suporte à identidade gerenciada atribuída pelo sistema e pelo usuário está disponível em geral. Por padrão, a identidade gerenciada atribuída pelo sistema é habilitada automaticamente.
Depuração de ponto de interrupção no Visual Studio Code: embora você possa adicionar e usar pontos de interrupção dentro do arquivo workflow.jsno para um fluxo de trabalho, os pontos de interrupção têm suporte apenas para ações no momento, não para gatilhos. Para obter mais informações, confira Criar fluxos de trabalho baseados em locatário único no Visual Studio Code.
Histórico de gatilhos e histórico de execuções: para um fluxo de trabalho de aplicativo lógico Standard, o histórico de gatilhos e o histórico de execuções no portal do Azure aparecem no nível do fluxo de trabalho, não no nível do recurso do aplicativo lógico. Para obter mais informações, confira Criar fluxos de trabalho baseados em locatário único usando o portal do Azure.
Modelos do Terraform: você não pode usar esses modelos com um recurso de aplicativo lógico Standard para implantação completa de infraestrutura. Para obter mais informações, consulte O que o Terraform no Azure?
Permissões rígidas de tráfego de rede e firewall
Se o ambiente tiver requisitos rigorosos de rede, ou firewalls que limitem o tráfego, será preciso configurar permissões para qualquer conexão de gatilho ou ação do seu fluxo de trabalho. Opcionalmente, você pode permitir o tráfego de marcas de serviço e usar o mesmo nível de restrições ou políticas que Serviço de Aplicativo do Azure. Você também precisa localizar e usar os FQDNs (nomes de domínio totalmente qualificados) para suas conexões. Para obter mais informações, examine as seções correspondentes na seguinte documentação:
- 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óximas etapas
- Criar fluxos de trabalho baseados em locatário único no portal do Azure
- Criar fluxos de trabalho baseados em locatário único no Visual Studio Code
Também gostaríamos de conhecer suas experiências com os Aplicativos Lógicos do Azure de locatário único!
- Para bugs ou problemas, crie uma publicação no GitHub.
- Para perguntas, solicitações, opiniões e outros tipos de comentários, use este formulário de comentários.