Quan el vol CA-1187 es retarda tres hores, Contoso Airlines ha de fer sempre el mateix: buscar a db-reservas els passatgers afectats, enviar-los un correu i un missatge de text, publicar l'avís al canal de l'equip d'operacions i obrir una incidència al sistema de suport. Res d'això no és lògica de negoci complexa; és enganxar sistemes entre si. Escrit com a codi serien quatre integracions amb les seves autenticacions, els seus formats i els seus reintents, mantingudes per en Diego Salas. I hi ha un detall incòmode: qui coneix el procés de debò és l'equip d'operacions, que no programa.

Azure Logic Apps existeix per a això. És un motor de fluxos de treball amb més de mil connectors llestos, que es dissenya visualment i es desa com una definició JSON versionable. Aquesta lliçó ensenya a construir aquest flux real, a gestionar-ne els errors, a desplegar-lo entre entorns —on hi ha el problema clàssic, les connexions— i a saber quan toca una aplicació lògica i quan no.

1. Què és una aplicació lògica i en què es diferencia de Functions
2. Consum davant d'Estàndard
3. Anatomia: desencadenador, accions i connectors
4. El flux de retard de vol, pas a pas
5. La definició JSON subjacent
6. Control de flux: condicions, bucles, àmbits i paral·lelisme
7. Gestió d'errors: reintents, execució posterior i compensació
8. Connexions i la seva autenticació
9. Supervisió i depuració d'una execució fallida
10. Integració amb la resta de la plataforma
11. Desplegament amb Bicep i el problema de les connexions
12. Cost per acció executada
13. Logic Apps, Functions o Data Factory
14. Errors Comuns i Consells
15. Exercicis
16. Conclusió

Una aplicació lògica és un flux de treball: un desencadenador i una seqüència d'accions connectades, on la sortida de cada pas alimenta el següent. No compiles res ni gestiones dependències.

La regla és simple: si el problema és «fer alguna cosa complicada», Functions; si el problema és «parlar amb sis sistemes diferents», Logic Apps. I no competeixen: el flux de Contoso cridarà una funció de 06-03 per a la part que sí que requereix codi.

Contoso tria Estàndard per a logic-contoso-retrasos-pro per dues raons concretes: necessita arribar a pe-sql-reservas per punt privat, i amb volum alt el preu fix és més predictible que pagar per acció quan un sol retard pot desencadenar centenars d'accions.

• Desencadenador: què inicia el flux. Pot ser una petició HTTP, una programació, o un connector que sondeja un sistema («quan arribi un correu», «quan es creï una fila»).
• Acció: cada pas posterior. Consulta dades, crida una API, envia un missatge, decideix, itera.
• Connector integrat: s'executa dins del motor. Ràpid, sense cost per acció al nivell Estàndard: HTTP, Service Bus, Azure Functions, SQL Server, control de flux.
• Connector gestionat: un embolcall allotjat per Microsoft sobre un servei extern: Office 365, Salesforce, SAP, Twilio, ServiceNow, Slack. Es factura per acció i requereix una connexió amb les seves credencials.

El valor real de Logic Apps és aquest catàleg de més de mil connectors. Integrar ServiceNow a mà són dies de feina —autenticació, esquema, reintents, paginació— i aquí és arrossegar una acció. Aquest és tot l'argument, i és un argument fort.

Els passos, en ordre:

1. Desencadenador «Quan es rep una petició HTTP». Genera una URL amb una signatura; el sistema d'operacions hi publica { "vuelo": "CA-1187", "minutos": 180, "fecha": "2026-08-15" }. Es defineix un esquema JSON de la càrrega perquè els camps apareguin com a fitxes seleccionables als passos següents.
2. Condició: si el retard no supera 60 minuts, no hi ha obligació de notificar. Es registra i acaba.
3. Acció SQL «Executar consulta» contra db-reservas, amb el número de vol i la data com a paràmetres —mai concatenats al text de la consulta, cosa que seria injecció SQL—, retornant localitzador, nom, correu i telèfon.
4. Cridar la funció CalcularCompensacion de 06-03 amb el retard i la ruta. Aquest càlcul depèn del reglament europeu, té els seus casos especials i és codi: no es fa amb accions visuals.
5. Bucle for each sobre els passatgers, en paral·lel, amb l'enviament de correu (Office 365) i de missatge (Twilio) a dins.
6. Avís al canal d'operacions a Teams, amb el resum i el nombre d'afectats.
7. Obrir la incidència a ServiceNow amb l'import de compensació calculat.

El dissenyador és una vista sobre un fitxer. Això importa: l'aplicació lògica és codi versionable que viu a contoso-infra i passa per revisió com qualsevol canvi (05-02).

Tres peces que convé reconèixer:

• @triggerBody()?['minutos'] és el llenguatge d'expressions. El ? és l'accés segur: si el camp no ve, retorna nul en lloc de trencar el flux. Fes-lo servir sempre amb dades externes.
• runAfter és el que defineix l'ordre real d'execució, no la posició visual. Un pas amb runAfter buit arrenca tan bon punt la branca comença; dues accions amb el mateix runAfter s'executen en paral·lel.
• concurrency.repetitions limita quantes iteracions del bucle corren alhora. Sense aquest límit, un vol de 300 passatgers dispara 300 crides simultànies a Twilio i provoca limitació de sol·licituds.

• Condició (If) amb dues branques, i Switch quan hi ha diversos casos discrets, com el tipus d'incidència.
• For each: itera sobre una col·lecció, per defecte en paral·lel amb 20 repeticions simultànies. Si l'ordre importa, cal forçar la concurrència a 1.
• Until: repeteix fins que es compleix una condició o s'esgota un comptador. És el patró de sondeig —«consultar l'estat del reemborsament cada 5 minuts fins que estigui aprovat o passin 2 hores»—. Posa sempre un límit d'iteracions i de temps, o tens un bucle infinit facturable.
• Àmbit (Scope): agrupa accions en un bloc que té el seu propi estat agregat. És la base de la gestió d'errors de l'apartat següent: funciona com un try.
• Branques paral·leles: dues accions amb el mateix runAfter s'executen alhora. Contoso ho fa servir perquè l'avís a Teams i la incidència de ServiceNow no esperin el bucle de passatgers.

Tres capes, de la més automàtica a la més manual.

Directiva de reintents. Cada acció la porta i per defecte reintenta 4 vegades amb espera exponencial davant d'errors transitoris (429 i 5xx). S'ajusta per acció:

Amb "type": "none" es desactiva, i hi ha un cas en què cal desactivar-la: quan l'acció no és idempotent. Reintentar un càrrec a la passarel·la de pagament cobra dues vegades. És la mateixa lliçó de 06-03, aquí en versió visual.

Accions d'execució posterior. El runAfter es pot condicionar a Failed, TimedOut o Skipped, no només a Succeeded. Aquest és el catch:

Combinat amb un àmbit, el patró try/catch queda: àmbit AmbitoNotificaciones amb els enviaments a dins, i una acció posterior que s'executa només si l'àmbit ha fallat, avisant l'equip amb @result('AmbitoNotificaciones'), que retorna el detall de quina acció concreta ha petat.

Compensació. No hi ha transaccions distribuïdes: si el correu s'ha enviat i el missatge ha fallat, el correu no es pot «desfer». El patró és afegir accions que corregeixen —marcar l'avís com a parcial, encuar un reenviament, obrir una incidència de revisió manual—. Dissenya-ho explícitament, perquè el flux fallarà a mitges tard o d'hora.

Una connexió és un recurs d'Azure independent del flux que desa com autenticar-se contra un sistema. I són de tres tipus:

Contoso fa servir identitat administrada sempre que el connector l'admet: id-contoso-api-pro accedeix a db-reservas i a kv-contoso-pro sense credencials. Per als connectors que exigeixen OAuth delegat, la regla de l'equip és autoritzar-los amb un compte de servei del domini —[email protected]— i mai amb el compte personal de la Marta o d'en Diego. És un error que es paga mesos després, quan algú canvia de lloc de treball i els fluxos comencen a fallar amb 401.

L'historial d'execucions és la millor eina de diagnòstic de tot el mòdul. Cada execució mostra el flux dibuixat amb cada pas en verd o vermell i, en clicar en un pas, les entrades i les sortides exactes d'aquella execució concreta: el JSON que hi va entrar, el que en va sortir i l'error literal.

El procés de depuració pràctic: obrir l'execució fallida, localitzar el primer pas en vermell —els següents solen ser-ne conseqüència—, llegir-ne les entrades per veure quines dades va rebre realment, i contrastar-ho amb el que esperaves. La majoria de les fallades són de forma de les dades: un camp nul que se suposava present, una data en un altre format, una col·lecció buida. Corregit el problema al sistema d'origen, la reexecució rellança aquella mateixa execució amb les mateixes dades d'entrada, sense haver de reproduir l'esdeveniment original.

Es completa amb l'enviament de diagnòstics a log-contoso-pro per consultar amb KQL i crear alertes sobre el nombre d'execucions fallides (07-01 i 07-02).

Aquí és on Logic Apps deixa de ser una eina solta:

• Des d'una alerta d'Azure Monitor (07-01): un grup d'accions pot invocar la URL del desencadenador HTTP. Així, «la latència d'app-contoso-reservas-pro supera 2 s» deixa de ser un correu i passa a ser un flux que obre la incidència, avisa el canal i hi adjunta l'enllaç al tauler.
• Des de Defender for Cloud (04-05): les seves automatitzacions de flux de treball disparen aplicacions lògiques davant d'una alerta de seguretat, per aïllar un recurs o notificar el responsable de guàrdia.
• Des d'Event Grid (06-05): reaccionar a esdeveniments de la plataforma sense escriure res.
• Cridant una funció de 06-03 amb el connector integrat d'Azure Functions, per a la lògica que sí que és codi. Aquesta combinació és la bona: Logic Apps orquestra, Functions calcula.

El flux es desplega com qualsevol altre recurs des de contoso-infra, amb la canalització d'infraestructura de 05-06:

I aquí hi ha el problema clàssic. La definició del flux es promociona netament entre entorns, però les connexions no: cada entorn té les seves, amb identificadors diferents, i les d'OAuth delegat necessiten que un humà premi «Autoritzar» al portal la primera vegada. Si no se separen, el desplegament en producció arrossega la connexió de desenvolupament i el flux acaba consultant db-reservas de l'entorn equivocat. La disciplina que ho evita:

1. La definició del flux no porta mai identificadors de connexió codificats: van al paràmetre $connections.
2. Les connexions es declaren com a recursos a part, per entorn, amb el seu .bicepparam.
3. Les d'identitat administrada s'automatitzen del tot; les d'OAuth s'autoritzen una vegada amb el compte de servei del domini i es documenta aquest pas manual.

Al nivell Consum es paga cada acció executada, i el matís és que les iteracions d'un bucle compten per separat. Fes el compte del flux de Contoso: un vol de 250 passatgers executa 2 accions per passatger, o sigui 500, més una desena de la resta. Cinc retards al dia són 2.500 accions diàries. Amb cèntims per cada mil accions sembla res, però el patró que dispara la factura sense avisar és sempre el mateix: un desencadenador de sondeig cada minut —43.200 comprovacions al mes encara que no passi res—, o un Until mal acotat, o un bucle imbricat que multiplica.

Les mesures: fer servir desencadenadors de notificació en lloc de sondeig quan el sistema ho permet (webhook o Event Grid), espaiar el sondeig al que de debò es necessita, acotar els Until amb comptador i temps màxim, i en volums alts passar al nivell Estàndard, on el cost és un pla fix i els connectors integrats no es facturen per acció.

La frontera amb Data Factory es resol amb una pregunta: el flux tracta un cas o un conjunt? Notificar els passatgers d'un vol és un cas: Logic Apps. Carregar 40 milions de registres d'embarcament a la capa bronce és un conjunt: Data Factory.

• Autoritzar connexions OAuth amb un compte personal. El dia que aquella persona canvia de lloc de treball, els fluxos fallen amb 401. Compte de servei del domini.
• Codificar identificadors de connexió a la definició. Trenca la promoció entre entorns. Paràmetre $connections.
• Concatenar valors en una consulta SQL. Injecció SQL de manual. Fes servir paràmetres.
• Deixar el for each amb la concurrència per defecte quan crida una API amb límit. 300 crides simultànies provoquen limitació i fallades en cascada.
• Reintentar accions no idempotents. Un càrrec reintentat es cobra dues vegades. Desactiva la directiva en aquests passos.
• Un Until sense límit d'iteracions i de temps. Bucle infinit que a més factura.
• Sondejar cada minut per comoditat. És la causa número u de factures sorpresa al nivell Consum.
• Consell: anomena les accions amb el que fan (ObtenerPasajerosAfectados), no amb el nom per defecte. Les expressions referencien aquest nom i canviar-lo després les trenca.
• Consell: si el flux té més de 30 accions o molta lògica condicional, la lògica pertany a una funció. El dissenyador visual deixa d'ajudar quan el flux sembla un plat d'espaguetis.

Exercici 1. Contoso Millas necessita un flux mensual que calculi el nivell de fidelització de cada soci, enviï un correu a qui puja de nivell i publiqui el resum al canal de l'equip comercial.

1. Tria nivell (Consum o Estàndard) i desencadenador, i justifica-ho.
2. Enumera les accions amb el seu control de flux, indicant on cridaries una funció i per què.
3. Indica les etiquetes obligatòries i estima l'ordre de magnitud del cost si hi ha 80.000 socis i 3.000 pugen de nivell.

Exercici 2. Aquest flux falla: l'acció CargarPasaporte puja un document a l'emmagatzematge, ActualizarReserva marca la facturació en línia a db-reservas, i EnviarConfirmacion avisa el passatger. Ahir, ActualizarReserva va fallar per un temps d'espera esgotat i avui hi ha passaports carregats de reserves que figuren sense facturar.

1. Explica per què va fallar, incloent-hi què van fer els reintents.
2. Redissenya el flux amb àmbits, execució posterior i compensació.
3. En què es diferencia això d'una transacció i quina garantia pots donar de debò?

Exercici 3. Per a cada cas tria Logic Apps, Functions o Data Factory: (a) en rebre un correu d'un proveïdor amb un CSV adjunt, validar-lo i obrir una incidència si té errors; (b) recalcular cada nit les tarifes de 12 milions de combinacions origen-destinació; (c) en confirmar-se un pagament, generar la factura en PDF amb les regles fiscals de set països.

Solució 1:

1. Consum amb desencadenador de programació mensual: s'executa una vegada al mes, no necessita xarxa virtual i el preu fix del nivell Estàndard no es justifica per a dotze execucions l'any.
2. Programació → cridar la funció CalcularNiveles amb el lot de socis → for each sobre els que pugen de nivell, amb concurrència limitada, enviant el correu a dins → avís a Teams amb el resum. El càlcul del nivell va en una funció perquè són regles de negoci amb llindars, casos especials i vigències: això és codi, es prova amb proves unitàries i no es manté amb accions visuals. A més, processar 80.000 socis pas a pas al dissenyador seria lentíssim i caríssim en accions.
3. entorno, proyecto=contoso-millas, centro-coste=CC-2077 i propietario. El cost depèn de la clau del disseny: si l'avaluació es fa dins de la funció, es facturen de l'ordre de 3.000 iteracions més una desena d'accions, és a dir, uns pocs milers d'accions al mes: cèntims. Si en canvi s'iterés sobre els 80.000 socis al flux amb dues accions cadascun, serien 160.000 accions mensuals. La lliçó és aquesta: el bucle al lloc equivocat multiplica la factura per cinquanta.

Solució 2:

1. ActualizarReserva va esgotar el temps d'espera contra db-reservas. La directiva de reintents per defecte ho va reintentar quatre vegades amb espera exponencial i, en continuar fallant, l'acció va quedar en Failed; com que EnviarConfirmacion tenia runAfter: Succeeded, no es va executar i el flux va acabar fallit. Però CargarPasaporte ja s'havia completat, i res no ho va revertir: d'aquí els documents orfes.
2. Embolcallar CargarPasaporte i ActualizarReserva en un àmbit AmbitoCheckIn. Afegir una acció amb runAfter: { AmbitoCheckIn: ["Failed","TimedOut"] } que executi la compensació: marcar el document carregat com a pendent de conciliació, encuar un reintent diferit a cola-emision-tarjetas i obrir una incidència amb @result('AmbitoCheckIn'). EnviarConfirmacion es manté amb runAfter: Succeeded sobre l'àmbit, perquè el passatger només rebi la confirmació si tot ha anat bé.
3. Una transacció donaria atomicitat: o tot o res, amb reversió automàtica. Aquí no n'hi ha, perquè els sistemes són independents i no comparteixen un coordinador. El que pots garantir és consistència final amb compensació: cada efecte parcial queda registrat i hi ha un camí explícit que el corregeix o l'escala a un humà. La diferència pràctica és que existeix una finestra en què el sistema és incoherent, i el disseny l'ha d'acceptar i fer-la visible en lloc de fingir que no existeix.

Solució 3: (a) Logic Apps: el desencadenador de correu, l'adjunt i l'obertura de la incidència són tres connectors llestos, i el flux és d'integració pura. (b) Data Factory: és un conjunt massiu processat per lots; fer-ho amb accions de flux seria absurd en cost i temps. (c) Functions: regles fiscals de set països més generació de PDF és lògica complexa i codi provable; com a molt, una aplicació lògica invoca aquesta funció com a part d'un flux més gran.

Saps què és una aplicació lògica i en què es diferencia d'una funció: flux visual davant de codi, integrar davant de calcular, cost per acció davant de cost per execució, i que la combinació bona és que Logic Apps orquestra i Functions calcula. Distingeixes Consum d'Estàndard per motor, preu, xarxa virtual, nombre de fluxos i execució local, i saps per què Contoso va triar Estàndard per a logic-contoso-retrasos-pro. Domines l'anatomia —desencadenador, accions, connectors integrats davant de gestionats— i entens que el catàleg de més de mil connectors és el veritable argument del servei.

Has construït el flux real de Contoso de cap a cap: petició HTTP amb esquema, condició sobre els 60 minuts, consulta parametritzada a db-reservas, crida a una funció per a la compensació, bucle sobre els passatgers amb concurrència limitada, avís al canal d'operacions i incidència al sistema de suport. I n'has llegit la definició JSON, que és el que converteix el dissenyador en una cosa versionable a contoso-infra: @triggerBody()?[...] amb accés segur, runAfter com a ordre real d'execució i control explícit del paral·lelisme. Manegues el control de flux complet —condicions, Switch, for each, Until acotat, àmbits i branques paral·leles— i les tres capes de gestió d'errors: directives de reintent (desactivades on l'acció no és idempotent), accions d'execució posterior com a catch, i compensació, perquè aquí no hi ha transaccions. Saps autenticar amb identitat administrada sempre que es pugui i amb un compte de servei del domini quan toca OAuth delegat, depurar llegint entrades i sortides reals a l'historial i reexecutar, i disparar fluxos des d'Azure Monitor, Defender for Cloud i Event Grid. I t'endus dos avisos concrets: el problema de les connexions en promocionar entre entorns, amb la seva disciplina de paràmetres i recursos separats, i el cost per acció, que es dispara amb el sondeig cada minut i els bucles mal col·locats.

Queda alguna cosa més profunda, i és el substrat de tot l'anterior. Cada vegada que Contoso confirma una reserva, avui passen sis coses en línia, dins de la mateixa petició: es cobra, s'actualitza la disponibilitat, s'emet la targeta, s'acrediten les milles, s'avisa facturació i s'envia la confirmació. Si el servei de milles està caigut, la compra falla. És una arquitectura acoblada, i ni Functions ni Logic Apps l'arreglen tots sols: cal que els components deixin de cridar-se directament i comencin a intercanviar missatges i esdeveniments. La lliçó següent, Missatgeria i esdeveniments: Service Bus, Event Grid i Event Hubs, ataca això de front: la distinció entre missatge i esdeveniment que gairebé tothom confon, els tres serveis amb la seva taula decisòria, cues i temes amb filtres i cua de missatges amb problemes de lliurament, distribució d'esdeveniments amb CloudEvents, ingesta massiva de telemetria amb captura cap al Data Lake, i el disseny complet del flux de Contoso amb les conseqüències que ja intueixes: lliurament almenys una vegada, ordenació i idempotència.