Lógica del Lado del Servidor

La mayoría de los productos que te dejan armar una interfaz te abandonan apenas necesitás que algo pase en un servidor. Las automatizaciones son la respuesta de Praxsuite a eso: son el backend, y no hay servidor que vos tengas que correr, escalar ni parchear.

Esta página trata de usarlas así — como la mitad confiable de tu sistema.

Por qué hace falta un servidor

Un navegador es un lugar hostil para guardar un secreto. Todo lo que tenga tu página lo tiene el visitante: claves, tokens, reglas de negocio, todo. Y todo lo que decida tu página, un visitante puede decidirlo distinto editando el pedido.

Así que la división no es por comodidad, es por confianza:

Una automatización como API HTTP

El trigger Endpoint convierte una automatización en una API que tu app puede llamar. Entra el pedido, corre tu flujo, y un nodo Response define exactamente qué vuelve — código de estado, headers, cuerpo.

Trigger Endpoint ──▶ validar ──▶ hacer el trabajo ──▶ Response (200, { ok: true })

Tres reglas que la plataforma valida, así te enterás al guardar y no en producción:

• Una automatización con endpoint debe tener un nodo Response.

• Puede tener exactamente uno. Ni cero, ni dos.

• Una automatización sin trigger de endpoint no puede tener ninguno.

Esta última sorprende. Un nodo Response no significa nada en un trabajo agendado — no hay nadie esperando una respuesta — así que el validador lo rechaza en vez de dejarlo ahí sin hacer nada.

Compará con el trigger Webhook, que responde al instante y corre después. Usá webhooks para "otro sistema me está avisando que pasó algo". Usá endpoints para "mi app me está haciendo una pregunta y necesita la respuesta".

El nodo Script

Cuando los nodos incorporados no expresan lo que necesitás, el nodo Script corre tu propio código — JavaScript o Python — en un sandbox aislado.

Es una salida de emergencia de verdad, no un juguete: parsear un payload incómodo, calcular algo que el nodo de fórmula no puede expresar, remodelar una respuesta antes de devolverla.

Archivos que entran y salen

Un script puede declarar un blob que se carga antes de correr, que llega como cadena base64 o como objeto con los datos, el content type y el nombre de archivo. Y puede devolver base64 en una clave de salida, que se sube por vos y se reemplaza por el id del archivo guardado, su URL, nombre, content type y tamaño.

Entre las dos cosas, "leé el CSV subido, transformalo, devolveme un XLSX" es un solo nodo.

Tres trampas que cuestan una tarde

Las entradas necesitan sus llaves. Una entrada es una plantilla: {{context.steps.query.rows}}. Un nombre de campo suelto es una cadena literal, y no va a dar error — simplemente va a estar mal.

No parsees lo que ya viene parseado. Las entradas llegan como valores reales. Llamar a JSON.parse sobre una que ya es un objeto lanza una excepción, de una forma que parece falla de la plataforma.

Los nombres de columna pierden los espacios. Las filas de un nodo Query Rows llegan a un script indexadas con guion bajo — Player_Name, no Player Name. Leer el nombre con espacio no devuelve nada, en silencio. El gateway no hace esto; solo muerde dentro de automatizaciones.

Secretos

Las credenciales van en el Vault, no en la configuración de un nodo. Leé un secreto con el nodo Vault y queda disponible para los nodos siguientes; nunca aparece en la definición de la automatización, y no es algo que alguien mirando el flujo pueda leer de la pantalla.

También hay un lado de escritura, para rotar un secreto desde un flujo — la forma honesta de manejar una credencial que vence periódicamente.

Hablar con el mundo exterior

El nodo HTTP Request llama a cualquier endpoint interno o externo y captura la respuesta. Combinado con el Vault, ese es el patrón entero de una integración con terceros: leé la clave, hacé la llamada, usá la respuesta — con la clave sin salir nunca del servidor.

Control de flujo que sobrevive al contacto con la realidad

Try/Catch es el que la gente adopta demasiado tarde. Una llamada HTTP a la API de otro va a fallar en algún momento — su caída, un timeout, un cambio que no avisaron. Sin camino de catch, la corrida se detiene ahí y lo que venía antes queda a medias.

Call Automation no espera. Inicia el otro flujo y sigue; no aguarda, y no trae un resultado. Cuando necesitás la respuesta, el diseño es otro — el trabajo va en línea, o detrás de un endpoint que llamás.

Mantenerlo rápido

Cada nodo cuesta algo, así que pocos pasos grandes le ganan a muchos chicos. Dos hábitos que se pagan solos:

Filtrá en la consulta, no después. Leer filas y después descartar la mayoría en un script hace igual la parte cara. Además la lectura de filas tiene tope por llamada, así que un filtro suele ser la diferencia entre correcto y truncado en silencio.

No pongas un bucle donde va un filtro. Un For Table sobre todo, con un If adentro, es el mismo trabajo que una consulta filtrada — salvo que corre un nodo por fila.

Siguiente

• Nodos Trigger — las cinco formas de entrar

• Nodos de lógica — ramificación, bucles, manejo de errores, Response

• Corridas y depuración — leer qué pasó realmente

• API Gateway — la otra mitad: qué pueden hacer los clientes directo