Novedades Power Platform

Para la Transformación Digital e Innovación Tecnológica

Novedades Power Platform

Para la Transformación Digital e Innovación Tecnológica

Power Platform

Power Automate Cloud – Sesión 08 – Resumen

🎯 Objetivo de la clase

Aprender a consumir APIs en Power Automate cuando no existe un conector, dominando:


🧩 Temas tratados

  1. Conectores vs APIs: cuándo usar cada uno [learn.microsoft.com], [learn.microsoft.com]
  2. Estructura de una API REST: URL + método + inputs + headers + body + output [learn.microsoft.com]
  3. Status Codes como validación (ej. 200, 401, 403, 404) y control del flujo [learn.microsoft.com], [learn.microsoft.com]
  4. Postman como herramienta de verificación (request/response) antes de Power Automate (buenas prácticas) [learn.microsoft.com], [learn.microsoft.com]
  5. Implementación en Power Automate:
  6. API con seguridad: Bearer Token en headers + Content-Type: application/json [learn.microsoft.com], [learn.microsoft.com]
  7. Casos prácticos:

🔑 Conceptos clave


1️⃣ Conectores vs APIs: ¿cuándo usar HTTP?

Idea principal:

✅ 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:

ElementoQué esEjemplo práctico
URLDirección del serviciohttps://.../endpoint
MétodoOperaciónGET / POST / PUT / DELETE
InputsParámetrosen URL (query/path) o en body
HeadersMetadatosContent-Type, Authorization
BodyDatos enviadosusual en POST/PUT como JSON
OutputRespuestaJSON 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:


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.

📌 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)

  1. Instant cloud flow (manual) para pruebas rápidas [learn.microsoft.com], [learn.microsoft.com]
  2. Acción HTTP (URL + método + headers/body) [learn.microsoft.com]
  3. Condition: statusCode == 200 [learn.microsoft.com]
  4. En True: Parse JSON usando el body de la respuesta [learn.microsoft.com]
  5. Uso de campos parseados en acciones posteriores (Compose/variables/notificación/registro) [learn.microsoft.com]
  6. 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


🧭 Pasos trabajados en clase (resumen)

A) En Postman (validación previa)

  1. Crear Workspace personal y una Collection para ordenar requests.
  2. Crear un Request GET pegando la URL y agregando el input (DNI) en la propia URL (parámetro en la cabecera/endpoint).
  3. Ejecutar Send y revisar la respuesta:
    • Se presentó un error 422 por DNI incompleto (faltaba dígito) y se corrigió ajustando el parámetro.
  4. 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)

  1. Crear un Instant cloud flow con disparador manual (“Manually trigger a flow”). [learn.microsoft.com]
  2. Agregar acción HTTP con:
    • Método: GET
    • URL: la de la API (incluyendo el parámetro DNI)
  3. Agregar Condition para validar:
  4. En la rama True, usar Parse JSON:
    • Content: Body del HTTP
    • Schema: generado con “Generate from sample” pegando el JSON copiado desde Postman. [learn.microsoft.com]
  5. Finalmente, usar Compose (Redactar) para imprimir o reutilizar propiedades como:

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)

  1. Crear cuenta en el servicio (prueba limitada por días).
  2. Vincular WhatsApp:
    • En algunos casos el QR falló (según país/dispositivo) y se intentó alternativa con código/numero.
  3. Identificar y copiar el TOKEN personal del canal (clave para autenticación).

B) En Power Automate (flujo POST)

  1. Crear un Instant cloud flow (manual) “API con WhatsApp”. [learn.microsoft.com]
  2. Agregar acción HTTP:
    • Método: POST
    • URL: endpoint específico .../message/text (según documentación del proveedor)
  3. Configurar Headers:
    • Content-Type: application/json
    • Authorization: Bearer <token>
  4. Configurar el Body (JSON):
    • to: número destino
    • body: 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):


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]


✅ Conclusiones


⭐ Recomendaciones finales

  1. Siempre probar primero la API (Postman) y guardar un ejemplo de respuesta para el esquema. [learn.microsoft.com]
  2. ✅ Validar statusCode == 200 antes de Parse JSON. [learn.microsoft.com]
  3. 🔐 No exponer tokens: usar conexiones/secret management según política interna; y manejar 401/403 con ruta de error. [learn.microsoft.com]
  4. 🧱 Implementar robustez: Scopes + Run after (Try/Catch) para fallas o cambios de estructura. [learn.microsoft.com], [learn.microsoft.com]
  5. 🧾 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]

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

advanced-floating-content-close-btnBoton