Punto de partida. Actividad «Automatización diseñada y simulada», sesión 1 de 3. Abre los materiales enlazados y crea el registro de la unidad. La guía de arranque permite preparar las herramientas sin depender de otros módulos.
Se explica
10 minutos · contexto, explicación y ejemplo
Una API permite que una aplicación solicite datos o acciones a otra siguiendo un acuerdo. La petición indica qué se necesita; la respuesta dice qué ocurrió y puede aportar datos. Un evento comunica que algo ya ha pasado: «reparación terminada». No son sinónimos: un evento puede provocar que otra aplicación llame a una API.
En Reparaciones Rápidas, terminar una reparación puede iniciar la preparación de su factura. Para conectar ambas tareas hay que saber qué datos se necesitan y qué aplicación los conoce. Hoy representaremos ese intercambio sobre papel o en un diagrama; no hace falta programar el backend.
Consultar ejemplos y conceptos de esta sesión
API: una puerta para comunicarse con una aplicación
Las APIs ya se han estudiado desde la perspectiva de la programación.
Aquí nos interesa entender para qué sirven dentro de una empresa.
Una API permite que otra aplicación pueda solicitar o enviar información de forma controlada.
Por ejemplo:
- Nuestra aplicación
- API
- Servicio meteorológico
Nuestra aplicación podría preguntar:
¿Qué temperatura hace ahora en Alicante?
y recibir:
{
"temperature": 31,
"condition": "sunny"
}La API actúa como una especie de puerta de entrada definida por el sistema.
No necesitamos saber cómo funciona internamente el servicio meteorológico.
Solo necesitamos conocer:
- qué podemos solicitar;
- qué datos debemos enviar;
- qué respuesta obtendremos.
Polling
El funcionamiento puede representarse así:
Es sencillo de implementar.
Su eficiencia, sin embargo, puede ser reducida.
Imaginemos que preguntamos cada minuto y el estado cambia una vez al día.
Estamos realizando miles de preguntas innecesarias.
Otra posibilidad: webhook
En lugar de preguntar continuamente:
¿Ha ocurrido algo?
podemos decir:
Avísame cuando ocurra.
Ese es el concepto fundamental de un webhook.
Por ejemplo:
- Pago completado
- Webhook
- Nuestra tienda
El servicio de pago avisa automáticamente a nuestra aplicación.
Polling vs webhook
Una forma sencilla de recordarlo:
Polling
El interesado pregunta periódicamente si ha ocurrido algo.
Webhook
El sistema donde ocurre el evento avisa en cuanto sucede.
Comparación:
| Polling | Webhook | |
|---|---|---|
| Quién inicia la comunicación | El interesado | El sistema donde ocurre el evento |
| Consultas repetidas | Sí | No normalmente |
| Tiempo de reacción | Depende del intervalo | Normalmente inmediato |
| Sencillez | Alta | Requiere preparar un receptor |
| Ejemplo | Consultar estado cada minuto | Avisar cuando cambia el estado |
Ninguno es siempre mejor.
Depende del problema.
Los eventos
Muchas aplicaciones modernas funcionan alrededor de acontecimientos.
Por ejemplo:
- usuario registrado;
- pedido creado;
- pago realizado;
- paquete enviado;
- reparación terminada;
- contraseña modificada.
Podemos llamar a estos acontecimientos:
Eventos
Un evento significa simplemente:
ha ocurrido algo relevante dentro del sistema.
Por ejemplo:
Evento: reparación terminada
A partir de ese evento podrían ejecutarse varias acciones:
Una única acción puede desencadenar muchas otras.
Cola de mensajes
Imagina una cola en un supermercado.
Una persona no desaparece porque la caja esté ocupada.
Espera su turno.
Una cola de mensajes utiliza una idea parecida:
Si el receptor está ocupado o temporalmente no disponible, los mensajes pueden esperar.
Tecnologías como:
- RabbitMQ;
- Apache Kafka;
- Amazon SQS;
se utilizan para resolver problemas relacionados con este tipo de comunicación.
No necesitamos aprenderlas en esta unidad.
Lo importante es entender el problema que solucionan.
Low-Code y No-Code
No todas las integraciones tienen que programarse desde cero.
Existen herramientas como:
- n8n;
- Zapier;
- Make;
- Power Automate.
Permiten construir flujos visualmente.
Por ejemplo:
- Nuevo formulario
- Crear registro
- Enviar correo
- Avisar por Teams
La idea es similar a programar:
- Si ocurre A
- entonces ejecuta B
- después ejecuta C
Estas herramientas son especialmente útiles para:
- automatizaciones sencillas;
- conectar servicios;
- prototipos;
- tareas internas.
Tampoco sustituyen en todos los casos al desarrollo tradicional.
Cuando necesitamos:
- lógica compleja;
- rendimiento;
- control;
- gran escalabilidad;
puede ser mejor desarrollar la solución mediante código.
Se trabaja
45 minutos · trabajo guiado sobre la actividad
- Abre la ficha de Reparaciones Rápidas y crea el registro de la UD2. Copia únicamente el fragmento del proceso que comienza cuando un técnico termina una reparación.
- Escribe el evento en pasado y enumera sus datos mínimos: identificador de reparación, fecha de cierre y referencia del cliente. Explica por qué cada dato resulta necesario.
- Dibuja tres participantes: gestión de reparaciones, facturación y servicio de avisos. Asigna a cada uno una responsabilidad; evita que dos piezas mantengan estados contradictorios sin explicarlo.
- Simula un intercambio: una persona prepara una tarjeta con la petición de factura y otra responde «creada» con su identificador. Si falta un dato, devuelve «petición incompleta» e indica cuál.
- Registra la petición, la respuesta y una condición que impida continuar. Comprueba que otra pareja entiende quién solicita, quién responde y qué cambia al terminar.
Cierre
5 minutos · comprobar el resultado
Al terminar la sesión:
Hay un intercambio completo con datos, respuesta y responsables. Distingue la orden «crear factura» del evento «factura creada».