Buenas prácticas de funcionamiento

Utiliza Functions para escribir en tablas

Enfoque recomendado

Crea funciones cuando varias aplicaciones o pasos de una aplicación escriban en la misma tabla y cuando necesites garantizar:

• Campos obligatorios
• Valores válidos (por ejemplo, el estado debe figurar en una lista aprobada)
• Metadatos coherentes (creado por, creado el)

Por qué es importante

Cuando los desarrolladores ciudadanos crean registros de tabla directamente en los disparadores, pueden:

• No respetar las convenciones de nomenclatura de los identificadores
• Olvidarse de campos obligatorios
• Escribir mal los valores de los campos («en curso» frente a «en-curso»)
• Rellenar los metadatos de forma inconsistente

Una función garantiza el cumplimiento del mismo esquema y evita estos errores.

Ejemplo

En lugar de permitir que cada desarrollador de aplicaciones cree registros «de muestra» con campos y contenido incoherentes, crea una función «Crear muestra » que:

• Exija entradas coherentes (ID de trabajo, tipo de muestra, cantidad, marca de tiempo, usuario, nombre de la aplicación)
• Valide que el tipo de muestra figure en una lista aprobada

Función:CreateSampleEntradas: - job_id (texto) - sample_type (texto) - quantity (número) - app name (texto) - user requesting (usuario)

Lógica: 1. Validar que «type_sample» esté en ["A", "B", "C"] 2. Si no es válido, devolver un mensaje de error 3. Crear un registro en la tabla con: - ID: generado dentro de la función - ID del trabajo: entrada - Tipo de muestra: entrada - Cantidad: entrada - Número de lote: entrada (o vacío si no se proporciona) - Creado por: entrada 4. Devolver un mensaje de éxito

Resultados: - estado (texto): «éxito» o «error» - mensaje (texto): descripción del error si falla

Cuando necesites crear un registro de tabla para una muestra, pasa los datos de entrada a una función y esta se encargará del resto.

Patrón a evitar

No crees una función para cada operación de escritura en la tabla, ni siquiera para las más sencillas.

Por qué esto causa problemas

• Genera una proliferación de funciones (cientos de funciones de un solo uso)
• Añade complejidad sin aportar ningún beneficio a las operaciones de escritura sencillas
• Dificulta la depuración (hay más lugares que revisar)

Cuándo evitar el uso de funciones para las operaciones de escritura en tablas

• Actualizar un registro de una tabla existente (por ejemplo, actualizar el estado o reducir la cantidad)
• Escrituras de una sola aplicación en una tabla
• No se requiere gobernanza ni validación

Utilizar funciones para lógica repetitiva de varios pasos

Enfoque recomendado

Si la misma secuencia de acciones desencadenantes se produce en muchos pasos a lo largo de varias aplicaciones, extráela a una función.

Ejemplo: Obtener el código ZPL para imprimir una etiqueta

Función: Obtenercódigo ZPL.Entradas: - ID del material (texto)

Variables: - Variable de código ZPL (texto)

Salidas: - Código ZPL (texto)

Lógica: 1. Actualizar datos: Configuración «Variable de código ZPL» — Establecer en — [Expresión para el código ZPL que incluya @Entradas.ID del material] 2. Devolver: «Código ZPL» Fuente de datos «Variable de código ZPL»

Patrón a evitar

No crees funciones para lógicas que solo se produzcan 1 o 2 veces en total en todas las aplicaciones.

Por qué esto causa problemas

• La sobrecarga que supone gestionar la función supera los beneficios
• Obliga a los desarrolladores de aplicaciones a aprender la interfaz de la función para un caso poco frecuente
• Dificulta la depuración, debido al cambio entre funciones y aplicaciones

Incorpora las funciones del conector en Functions

Enfoque recomendado

Cuando utilices una función de conector, pasa las entradas de dicha función a una función que la llame. De este modo, la función podrá gestionar los reintentos por tiempo de espera y el manejo de errores de una forma más sencilla y centralizada, lo que te permitirá simplificar la lógica de las aplicaciones en toda tu solución.

La integración de funciones de conector en funciones también puede minimizar el esfuerzo de una posible migración futura del ERP, al reducir la cantidad de cambios que habría que realizar en las aplicaciones individuales.

Ejemplo

Función: Actualizarpedido de proceso.Entradas: - ID del pedido (texto) - Estado (texto)

Salidas: - Mensaje de error (texto)

Variables: - Código HTTP (entero) - Reintentos por tiempo de espera (entero) - Mensaje de error (texto)

Lógica: 1. Ejecutar la función del conector. 2. Si el código HTTP indica éxito, finalizar la función. 3. Si el código HTTP indica un tiempo de espera agotado y el valor de «Intentos tras tiempo de espera» es menor o igual que un valor especificado, incrementar el valor de «Intentos tras tiempo de espera» y volver a «Ejecutar la función del conector»4. Si el código HTTP es un código que no puede resolverse mediante la lógica de la función, devolver un mensaje útil en la salida «Mensaje de error»

Pasa los ID de los registros, no los campos individuales de los registros de la tabla

Enfoque recomendado

Cuando una función necesite datos de un registro de una tabla, pasa el ID del registro y carga el registro dentro de la función.

Ejemplo

Aunque el siguiente ejemplo es lógicamente correcto (donde «ID de pedido» es el ID de la tabla «Pedidos» y los demás campos son columnas de esa tabla), existe una configuración más sencilla.

Función: Procesarpedido. Parámetros de entrada: - ID del pedido (texto) - Nombre del cliente (texto) - ID del producto (texto) - Cantidad (número) - Fecha de vencimiento (fecha y hora) - Prioridad (texto)

Lógica: 1. [Aplicar la lógica utilizando los campos de entrada]

El ejemplo siguiente utiliza un mínimo de datos de entrada para obtener el mismo resultado:

Función: Procesarpedido. Entradas: - ID del pedido (texto)

Lógica: 1. Obtener el registro de la tabla: tabla «Orders» donde ID = «ID del pedido» (entrada) 2. [Aplicar la lógica utilizando los campos del registro de la tabla]

Por qué el segundo ejemplo es un enfoque mejor:

• Menos entradas (1 en lugar de 6 o más)
• La función se puede adaptar fácilmente si cambia el esquema de la tabla
• Llamadas a funciones más limpias en las aplicaciones
• Reduce la probabilidad de asignar un campo incorrecto a una entrada errónea

Nombra y describe las funciones y los parámetros de forma coherente

Enfoque recomendado

Utiliza una convención de nomenclatura coherente en todas las funciones de tu espacio de trabajo.

Nombres de funciones

• Utilice verbo + sustantivo: Crear muestra, Actualizar estado del trabajo, Validar número de serie
• No utilices solo sustantivos: Muestra, Trabajo, Número de serie

Descripción de la función

• Escribe una descripción intuitiva de lo que hace la función. Por ejemplo, para una función llamada «Crear defecto», escribe una descripción como «Crea un nuevo registro en la tabla Defectos con el estado ABIERTO».

Nombres de los campos de entrada

• Utiliza una terminología coherente: siempre «ID de orden de trabajo» (no «ID de pedido» ni «Work_id» en algunos casos)
• Haga coincidir los nombres de los campos de la tabla siempre que sea posible

Nombres de bloques lógicos

• Sé explícito: «Obtener registro de trabajo», no «Obtener registro de tabla»
• Ayuda a los futuros lectores: «Validar tipo de muestra», no «Comprobar valor»

Por qué es importante

• Los desarrolladores de aplicaciones comprenden rápidamente la finalidad de las funciones
• Reduce la carga cognitiva al utilizar varias funciones
• Facilita el análisis de «dónde se utiliza»
• Mejora la documentación y la formación

Gestiona la validación de entradas y los mensajes de error de los usuarios de forma fluida

Enfoque recomendado

Marca siempre las entradas de las funciones como campos obligatorios y utiliza reglas de validación de entradas cuando sea adecuado. No valides las entradas dentro de las funciones.

Por qué es importante

• Los usuarios de la aplicación reciben información clara al introducir valores
• Simplifica la lógica de las funciones, ya que la aplicación se encarga de la validación de entradas y permite que la función se ejecute con entradas que se sabe que son válidas
• Evita que se produzcan datos corruptos debido a entradas erróneas

Patrón que hay que evitar

No valides las entradas dentro de la función.

Por qué esto causa problemas

• Es redundante, ya que el editor de la aplicación ya dispone de funciones de validación de entradas
• Latencia adicional innecesaria al volver a comprobar la validez de las entradas dentro de la función

Minimiza las consultas a tablas dentro de los bucles

Si tu función recorre un array, evita consultar las tablas en cada iteración. En su lugar, realiza una consulta única antes del bucle y utiliza el resultado.

Utiliza funciones para la lógica, no para simples referencias

No crees funciones que solo recuperen un único registro de una tabla: para eso están las « record placeholders ». Reserva las funciones para la lógica que transforma los datos.

Limita el tamaño de la salida

Si tu función devuelve objetos o matrices de gran tamaño, plantéate devolver solo los campos que la aplicación necesita, en lugar de toda la matriz de objetos.

Recursos adicionales

{{snippet.Recursos adicionales sobre funciones: biblioteca y comunidad}}

{{snippet.¿Has encontrado lo que buscabas?}}