Power Automate Cloud – Sesión 08 – Resumen

🎯 Objetivo de la clase
Aprender a consumir APIs en Power Automate cuando no existe un conector, dominando:
- Métodos HTTP (GET/POST/PUT/DELETE)
- Validación por códigos de estado (Status Codes)
- Transformación de respuestas con Parse JSON
- Uso de Postman para probar y entender la estructura de una API antes de automatizarla [learn.microsoft.com], [learn.microsoft.com], [learn.microsoft.com]
🧩 Temas tratados
- Conectores vs APIs: cuándo usar cada uno [learn.microsoft.com], [learn.microsoft.com]
- Estructura de una API REST: URL + método + inputs + headers + body + output [learn.microsoft.com]
- Status Codes como validación (ej. 200, 401, 403, 404) y control del flujo [learn.microsoft.com], [learn.microsoft.com]
- Postman como herramienta de verificación (request/response) antes de Power Automate (buenas prácticas) [learn.microsoft.com], [learn.microsoft.com]
- Implementación en Power Automate:
- Acción HTTP
- Condición (status code)
- Parse JSON
- Uso de propiedades parseadas como contenido dinámico [learn.microsoft.com], [learn.microsoft.com], [learn.microsoft.com]
- API con seguridad: Bearer Token en headers +
Content-Type: application/json[learn.microsoft.com], [learn.microsoft.com] - Casos prácticos:
- API pública (GET, input por URL)
- API para mensajería (POST + token + body JSON) [learn.microsoft.com], [learn.microsoft.com]
🔑 Conceptos clave
- Conector: integración ya “empaquetada” (acciones/triggers) para hablar con un servicio sin construir solicitudes HTTP manuales. [learn.microsoft.com], [learn.microsoft.com]
- HTTP (acción): permite llamar APIs directamente indicando URL, método, headers y body. [learn.microsoft.com]
- Parse JSON: convierte un JSON “en texto” en un objeto para usar propiedades en pasos posteriores. [learn.microsoft.com]
- Condición: control de rutas (true/false) para ejecutar acciones solo si se cumple una validación (ej. statusCode = 200). [learn.microsoft.com]
- Run after / manejo de errores: permite ejecutar pasos alternos si una acción falla, se omite o expira. [learn.microsoft.com], [learn.microsoft.com]
1️⃣ Conectores vs APIs: ¿cuándo usar HTTP?
Idea principal:
- Si Power Automate ya tiene conector, úsalo (más rápido y estable).
- Si no hay conector, usa HTTP y consume la API directamente. [learn.microsoft.com], [learn.microsoft.com]
✅ Esto es clave porque en escenarios reales, TI suele entregar una API (con documentación) para integraciones específicas. [learn.microsoft.com], [learn.microsoft.com]
2️⃣ Anatomía de una API REST (lo que siempre debes pedir)
Para consumir correctamente una API, necesitas como mínimo:
| Elemento | Qué es | Ejemplo práctico |
|---|---|---|
| URL | Dirección del servicio | https://.../endpoint |
| Método | Operación | GET / POST / PUT / DELETE |
| Inputs | Parámetros | en URL (query/path) o en body |
| Headers | Metadatos | Content-Type, Authorization |
| Body | Datos enviados | usual en POST/PUT como JSON |
| Output | Respuesta | JSON con campos/arrays |
Power Automate permite definir esta estructura directamente en la acción HTTP. [learn.microsoft.com]
3️⃣ Métodos HTTP y su uso típico
Se reforzó que el método debe coincidir con la intención del endpoint:
- GET → recuperar datos (consultar) [learn.microsoft.com]
- POST → enviar/crear datos (registrar, disparar acciones) [learn.microsoft.com]
- PUT/PATCH → actualizar datos [learn.microsoft.com]
- DELETE → eliminar recursos [learn.microsoft.com]
4️⃣ Validación correcta: Status Codes ✅
Punto crítico de la sesión: en APIs, la “verdad” no es si “hay registros”, sino el código HTTP.
- La práctica recomendada es: si statusCode = 200 → continuar; si no, ejecutar ruta de error. [learn.microsoft.com], [learn.microsoft.com]
📌 Para construir automatizaciones robustas, Microsoft recomienda configurar rutas de error (Run after / scopes / notificaciones). [learn.microsoft.com], [learn.microsoft.com]
5️⃣ Postman: por qué se usó antes de Power Automate 🧪
Se trabajó Postman como herramienta para:
- Confirmar que la API responde (antes del flujo)
- Ver el JSON real del output
- Identificar si los inputs van en URL, headers o body
- Copiar un ejemplo real de respuesta para generar el esquema de Parse JSON [learn.microsoft.com], [learn.microsoft.com]
✅ En Power Automate, Parse JSON necesita un schema; Postman ayuda a obtener una muestra válida. [learn.microsoft.com]
6️⃣ Implementación en Power Automate: patrón recomendado (plantilla)
✅ Patrón aplicado en la sesión (reutilizable)
- Instant cloud flow (manual) para pruebas rápidas [learn.microsoft.com], [learn.microsoft.com]
- Acción HTTP (URL + método + headers/body) [learn.microsoft.com]
- Condition:
statusCode == 200[learn.microsoft.com] - En True: Parse JSON usando el body de la respuesta [learn.microsoft.com]
- Uso de campos parseados en acciones posteriores (Compose/variables/notificación/registro) [learn.microsoft.com]
- En False: manejo del error (log + notificación + terminate opcional) [learn.microsoft.com], [learn.microsoft.com]
Microsoft documenta el uso de data operations (incluye Parse JSON) para transformar datos y facilitar su reutilización en el flujo. [learn.microsoft.com]
7️⃣ Autenticación: Bearer Token 🔐
Para APIs “no públicas”, se explicó el patrón típico:
- Header:
Authorization: Bearer <token> - Header:
Content-Type: application/json(cuando envías body JSON)
Esto se alinea con recomendaciones de robustez y control de errores: si falta token o es inválido, el servicio puede devolver 401/403 y el flujo debe manejarlo. [learn.microsoft.com], [learn.microsoft.com]
✅ Ejemplo 1: Consulta de datos personales (API tipo GET) + Parse JSON
🎯 ¿Qué se buscaba lograr?
Consumir una API pública para consultar información de una persona usando un identificador (DNI) como parámetro, validando la respuesta por status code y transformando el JSON para usar sus campos en el flujo. [learn.microsoft.com]
🔧 Herramientas usadas
- Postman: verificar que la URL y el método funcionan antes de llevarlo a Power Automate. [learn.microsoft.com]
- Power Automate: flujo instantáneo + acción HTTP + Condition + Parse JSON + Compose. [learn.microsoft.com], [learn.microsoft.com]
🧭 Pasos trabajados en clase (resumen)
A) En Postman (validación previa)
- Crear Workspace personal y una Collection para ordenar requests.
- Crear un Request GET pegando la URL y agregando el input (DNI) en la propia URL (parámetro en la cabecera/endpoint).
- Ejecutar Send y revisar la respuesta:
- Se presentó un error 422 por DNI incompleto (faltaba dígito) y se corrigió ajustando el parámetro.
- Confirmar que la respuesta viene en JSON y ubicar los campos relevantes (nombre, apellidos, tipo doc, número doc).
Aprendizaje clave: Postman se usa como “laboratorio” para validar la API antes de automatizarla, y para capturar un ejemplo real del JSON de respuesta.[learn.microsoft.com]
B) En Power Automate (implementación del flujo)
- Crear un Instant cloud flow con disparador manual (“Manually trigger a flow”). [learn.microsoft.com]
- Agregar acción HTTP con:
- Método: GET
- URL: la de la API (incluyendo el parámetro DNI)
- Agregar Condition para validar:
statusCode == 200(solo si es exitoso se continúa). [learn.microsoft.com]
- En la rama True, usar Parse JSON:
- Content:
Bodydel HTTP - Schema: generado con “Generate from sample” pegando el JSON copiado desde Postman. [learn.microsoft.com]
- Content:
- Finalmente, usar Compose (Redactar) para imprimir o reutilizar propiedades como:
nombre,apellidoPaterno,apellidoMaterno,numeroDocumento, etc.[learn.microsoft.com]
Resultado: tras Parse JSON, el contenido dinámico “aparece” como propiedades utilizables; antes de Parse JSON, solo se veía el body como texto. [learn.microsoft.com]
⚠️ Errores / problemas reales vistos
- No aparecían las propiedades (nombre, apellidos) en contenido dinámico → se resolvió con Parse JSON (schema generado desde muestra). [learn.microsoft.com]
- Error por parámetro mal pegado / DNI incompleto → la API devolvió 422 (no procesable) y se corrigió el input.
✅ Ejemplo 2: Enviar un mensaje por WhatsApp (API tipo POST) con Token (Bearer)
🎯 ¿Qué se buscaba lograr?
Consumir una API externa de WhatsApp (servicio “WAPI”) para enviar mensajes, entendiendo:
- diferencia entre conector vs API,
- uso de POST,
- uso de Headers (
Content-Type+Authorization: Bearer <token>), - y configuración correcta del Body JSON. [learn.microsoft.com]
🔧 Herramientas usadas
- Registro/activación del servicio WAPI (trial) + vinculación con WhatsApp vía QR/código.
- Power Automate: flujo instantáneo + HTTP POST (endpoint de mensajes).
🧭 Pasos trabajados en clase (resumen)
A) Configuración del servicio (WAPI)
- Crear cuenta en el servicio (prueba limitada por días).
- Vincular WhatsApp:
- En algunos casos el QR falló (según país/dispositivo) y se intentó alternativa con código/numero.
- Identificar y copiar el TOKEN personal del canal (clave para autenticación).
B) En Power Automate (flujo POST)
- Crear un Instant cloud flow (manual) “API con WhatsApp”. [learn.microsoft.com]
- Agregar acción HTTP:
- Método: POST
- URL: endpoint específico
.../message/text(según documentación del proveedor)
- Configurar Headers:
Content-Type: application/jsonAuthorization: Bearer <token>
- Configurar el Body (JSON):
to: número destinobody: texto del mensaje
Se probó enviarse un mensaje “a sí mismo” y también a otro número para validar entrega.
❓ Preguntas y respuestas destacadas (con refuerzo oficial)
1) ¿Qué pasa si cambian la estructura del JSON?
✅ Respuesta del docente: si cambia la estructura esperada, el flujo puede fallar al analizar JSON (schema ya no coincide).
🔎 Refuerzo (Microsoft):
- Las operaciones de datos como Parse JSON dependen del esquema; ante cambios, se recomienda reforzar manejo de errores y rutas alternativas.
✅ Solución recomendada: implementar control de errores con Scopes (Try/Catch) + Run after para notificar y registrar fallas. [learn.microsoft.com], [learn.microsoft.com] [learn.microsoft.com], [learn.microsoft.com]
2) ¿Por qué validar siempre statusCode antes de Parse JSON?
✅ Respuesta del docente: porque statusCode confirma si la petición fue correcta; si no, Parse JSON puede fallar o procesar un error HTML/JSON inesperado.
🔎 Refuerzo (Microsoft): uso de Condition para ejecutar acciones solo si la condición se cumple y uso de rutas alternativas cuando falle. [learn.microsoft.com], [learn.microsoft.com]
3) ¿Para qué sirve Postman si igual lo haré en Power Automate?
✅ Respuesta del docente: Postman sirve para comprobar que la API funciona y para conocer la estructura del response antes de automatizar.
🔎 Refuerzo (Microsoft): la documentación de operaciones de datos (Parse JSON) requiere una muestra válida y esquema para trabajar correctamente con respuestas. [learn.microsoft.com]
4) ¿Qué hacer si el envío por API “sale correcto” pero el mensaje tarda o no llega?
✅ Respuesta del docente (enfoque): puede ser un tema del servidor/proveedor de la API o de formato (por ejemplo, número con prefijo).
🔎 Refuerzo (Microsoft): para escenarios con APIs externas, aplicar manejo de errores, reintentos y notificaciones (Run after / retry / scopes).
✅ Solución recomendada: [learn.microsoft.com], [learn.microsoft.com]
- Registrar response completo (Compose + log)
- Implementar reintento/espera según políticas del servicio
- Notificar si el proveedor devuelve estado “pendiente” [learn.microsoft.com], [learn.microsoft.com]
✅ Conclusiones
- Integrar APIs en Power Automate es una habilidad clave cuando no existe conector, usando la acción HTTP. [learn.microsoft.com], [learn.microsoft.com]
- El flujo debe validarse por statusCode antes de procesar el body. [learn.microsoft.com], [learn.microsoft.com]
- Parse JSON es el paso crítico para convertir la respuesta en campos reutilizables (contenido dinámico). [learn.microsoft.com]
- Para soluciones profesionales: incorporar manejo de errores (Scopes, Run after, notificaciones, logs). [learn.microsoft.com], [learn.microsoft.com]
⭐ Recomendaciones finales
- ✅ Siempre probar primero la API (Postman) y guardar un ejemplo de respuesta para el esquema. [learn.microsoft.com]
- ✅ Validar
statusCode == 200antes de Parse JSON. [learn.microsoft.com] - 🔐 No exponer tokens: usar conexiones/secret management según política interna; y manejar 401/403 con ruta de error. [learn.microsoft.com]
- 🧱 Implementar robustez: Scopes + Run after (Try/Catch) para fallas o cambios de estructura. [learn.microsoft.com], [learn.microsoft.com]
- 🧾 Registrar trazabilidad: guardar response, statusCode y URL de ejecución para soporte. [learn.microsoft.com], [learn.microsoft.com]
📚 Referencias oficiales
- Microsoft Learn. Connectors overview.
[https://learn.microsoft.com/en-us/connectors/overview], [learn.microsoft.com] [learn.microsoft.com] - Microsoft Learn. HTTP actions reference (Power Automate).
[https://learn.microsoft.com/es-es/power-automate/desktop-flows/actions-reference/web], [learn.microsoft.com] [learn.microsoft.com] - Microsoft Learn. Use data operations in Power Automate (incluye Parse JSON).
[https://learn.microsoft.com/en-us/power-automate/data-operations], [learn.microsoft.com] [learn.microsoft.com] - Microsoft Learn. Add a condition to a cloud flow.
[https://learn.microsoft.com/en-us/power-automate/add-condition], [learn.microsoft.com] [learn.microsoft.com] - Microsoft Learn. Employ robust error handling (Run after, scopes, retry, terminate).
[https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling], [learn.microsoft.com] [learn.microsoft.com] - Microsoft Learn. Use scopes to organize actions in cloud flows.
[https://learn.microsoft.com/en-us/power-automate/scopes], [learn.microsoft.com] [learn.microsoft.com] - Microsoft Learn. Triggers introduction (instant/manual flows).
[https://learn.microsoft.com/en-us/power-automate/triggers-introduction], [learn.microsoft.com] [learn.microsoft.com]

