Azure Logic Apps: o futuro dos backends?

Exemplo

Apresentam-se de seguida dois exemplos de Logic Apps criadas com actions disponibilizadas nativamente. Para exemplos passo-a-passo recomenda-se a consulta da documentação em https://azure.microsoft.com/en-us/documentation/services/app-service/logic/.

A figura abaixo apresenta provavelmente o que é o exemplo mais simples possível de uma Logic App.

Exemplo de uma Logic AppEsta Logic App é composta apenas por duas acções, ambas utilizações de uma API App que permite fazer pedidos HTTP. 

A primeira é uma acção de HTTP/Get, que a cada minuto faz um pedido HTTP a ­um URL configurado (no caso, “http://www.example.com”), e obtém tanto o conteúdo HTML da página (“body”) da resposta como os cabeçalhos HTTP (“headers”). A segunda acção é um HTTP/Post, em que se envia a informação obtida no HTTP/Get anterior como corpo do pedido para um serviço gratuito (http://requestb.in) que por sua vez permite consultar o que está a receber via HTTP Post.

De notar que a configuração de que o resultado da 1ª acção deve ser usado como input da 2ª é feito via uma dropdown que apresenta todos valores possíveis de utilizar, não sendo necessário regra geral a introdução de texto. Quando se faz esta escolha, a representação textual interna substitui a dropdown (no caso acima, @triggers().output.body).

A imagem acima é um screenshot retirado do novo Portal de Azure (http://portal.azure.com), onde são efectuadas as operações realizadas tanto com Logic Apps como com API Apps. Além do designer visual na parte central, são visíveis as opções de topo do editor (onde se inclui uma opção “Code View” que permite consultar a especificação do processo em formato JSON passível de armazenamento em source control), como a paleta de API Apps do lado direito, onde se vêm algumas das dezenas de opções já disponíveis.

A figura abaixo apresenta um exemplo um pouco mais complexo que o anterior.Exemplo de uma Logic App

No exemplo acima são usadas 4 acções:

Recurrence
acção de trigger da Logic App, indica que a mesma vai ser executada a cada minuto.
Twitter Connector
procura no Twitter por algum texto (no caso, “Philae”). Quando se adiciona esta action é necessário realizar autenticação no Twitter, que fica guardada internamente à Logic App.
Dropbox Connector
action que pega no resultado da acção de Twitter e cria um ficheiro numa conta Dropbox com o conteúdo do tweet encontrado. Tal como no caso do HTTP/Post no exemplo anterior, esta acção tem uma dependência criada implicitamente pelo facto de usar dados de outra acção, sendo também necessário – como no caso da action de Twitter – fazer autenticação no Dropbox.
Office365 Connector
action que pega no resultado da acção de Twitter e envia um email para o endereço email configurado, com o conteúdo do tweet. Mais uma vez, é necessário fazer autenticação no serviço (agora o Office 365) quando se usa esta acção.

Cada uma das acções anterior tem opções de refinamento que permitem especificar comportamento mais complexo, e a que se acede através do botão de reticências no seu canto superior direito.

Acesso a opções adicionais

No caso anterior, é possível por exemplo indicar que esta acção apenas é executada caso se verifique uma determinada condição, ou que se pretende que iterar a sua utilização sobre uma lista de itens de informação.

A figura abaixo apresenta um excerto da Code View, mostrando o JSON que representa a Logic App descrita acima. Neste JSON podemos ver uma secção de triggers que desencadeiam a execução, e uma sequência de actions, cada uma com o seu tipo e configuração específica. Como se pode reparar também, cada action tem um atributo type que no caso do twitterconnector é uma ApiApp.

"triggers": {
  "recurrence": {
    "recurrence": {
      "frequency": "Minute",
      "interval": 1
    },
    "type": "Recurrence"
  }
},
"actions": {
  "twitterconnector": {
    "type": "ApiApp",
    "inputs": {
      "apiVersion": "2015-01-14",
      "host": {
        "id": "/subscriptions/..."
	"gateway": "https://devtechrefreshlisboa..."
      },
      "operation": "SearchTweets",
      "parameters": {
        "Query": "philae",
        "MaxResults": 20
      },
      "authentication": {
        "type": "Raw",
        "scheme": "Zumo",
        "parameter": "@parameters('/subscriptions/...')"
      }
    },
    "conditions": []
  },
  "dropboxconnector": {
    "type": "ApiApp",
    "inputs": {

Um dos pontos mais curiosos das Logic Apps é a forma como lidam com controlo de fluxo. Por omissão, todas as acções executam em paralelo umas com as outras, não existindo – como sucede nos fluxogramas ou workflows tradicionais – um controlo de fluxo explícito. Este controlo de fluxo é criado implicitamente com base em dependências de dados. Assim, se a acção B depende da acção A, B vai ser executado depois de A. Se não depende, vai ser executado em paralelo.

Na implementação actual, as formas de controlo de fluxo que existem são as 4 já referidas: a) recorrência; b) dependência de dados; c) execução condicionada a uma condição; d) repetição sobre lista. Uma outra action disponibilizada, o “Wait”, pode igualmente ser utilizada neste contexto, mas o mecanismo como um todo é muito diferente daquilo a que estamos habituados, lembrando a forma de funcionamento altamente paralelizável de motores de regras (como o do BizTalk Server ou do Windows Workflow Foudation v2).

Conclusão

Neste artigo procurou-se dar uma introdução às Logic Apps, no seu contexto histórico e arquitectural, sem entrar em detalhe de implementação, e omitindo aspectos como monitoria no Portal Azure, custos, tratamento de erros, escalabilidade, bem como a integração profunda com as Web Apps e vários outros temas. Existem no entanto três aspectos que vale a pena referir como conclusão:

Primeiro, as Logic Apps são uma oferta Empresarial/Premium, tendo origem no mesmo universo empresarial de onde vêm produtos business-critical como o BizTalk Server. São portanto de esperar potencialidades como escalabilidade, tolerância a falhas, tratamento de erros ou robustez, entre outros. Apesar de estarem disponíveis actualmente muitas actions orientadas para o consumidor final (como Facebook ou Twitter), sendo estas sempre usadas nas demonstrações públicas, o foco arquitectural é empresarial.

Segundo, as Logic Apps são materializações de arquitecturas baseada em microserviços, e dependem de API Apps, em que se podem tanto usar as disponibilizadas nativamente pela Microsoft, mas também desenvolver novas, sendo este um processo que se reveste de uma enorme simplicidade (uma API App é essencialmente uma WebApi alojada em Azure, com um contracto de utilização descrito em formato Swagger/JSON). Apesar de ainda não disponível completamente, está previsto um Marketplace de API Apps, onde ISVs poderão disponibilizar as suas próprias APIs e monetizar a sua utilização, quer sejam usadas directamente quer via Logic Apps. Alguns exemplos poderão ser serviços de detecção de rostos, acesso a informação como bolsa ou meteorologia, motores de recomendações, entre muitos outros.

Finalmente, deve salientar-se o facto de as Logic Apps ainda estarem em Preview e com evoluções frequentes (ver por exemplo as alterações mais recentes em http://azure.microsoft.com/en-us/updates/schedule-logic-apps-to-run-in-the-future/), existindo limitações como sejam a impossibilidade de criar workflows em Visual Studio, e de o processo de sincronização com repositórios de código como o TFS ser manual, entre outras. Ainda assim, as Logic Apps são provavelmente a novidade mais interessante de entre as últimas que têm surgido no universo Microsoft Azure, e vale a pena tanto perceber que cenários suportam, como acompanhar o rumo e evolução dos próximos meses.

Publicado na edição 50 (PDF) da Revista PROGRAMAR.