Scripts personalizados

Scripts are the lightest-weight entry point into Behavior Extensibility – Python code that runs on the platform server and can be triggered, scheduled, or called from within larger automation flows.

Dentro del marco de Behavior Extensibility, los scripts son código Python del lado del servidor que se ejecuta en el contexto de la plataforma Altium 365. A diferencia de las extensiones compiladas o de la automatización completa de flujos de trabajo, los scripts son intencionalmente ligeros: un solo archivo, un contrato de entrada/salida definido y un propósito concreto. Se pueden activar manualmente, invocar desde hooks, incrustar en flujos de trabajo como pasos o programar para que se ejecuten de forma periódica.

Los scripts comparten la misma infraestructura de extensibilidad que los checks, hooks y bloques de flujo de trabajo: tienen acceso a los datos del Workspace, pueden llamar a sistemas externos y sus resultados pueden alimentar otras partes de la canalización de automatización. La diferencia está en el alcance: un script hace una sola cosa, la hace bien y puede iterarse rápidamente.

Para qué se usan los scripts en este contexto

• Targeted automation – un script que se ejecuta una vez al activarse – normalizar valores de parámetros de componentes en una biblioteca, generar un informe personalizado a partir de datos del Workspace, enviar un conjunto de datos a un sistema externo después de una liberación. Operaciones focalizadas que no necesitan integrarse en todo el marco de checks o de flujo de trabajo.

• Data transformation – los scripts son la herramienta adecuada cuando los datos deben remodelarse entre sistemas – convertir estructuras de datos de Altium a un formato que espera una API externa, o transformar datos entrantes antes de escribirlos en el Workspace. Una lógica de transformación limpia en un script es más fácil de probar y mantener que una transformación oculta dentro de un flujo de trabajo más grande.

• Policy enforcement, lightweight – para reglas de cumplimiento que no necesitan ejecutarse en puntos de control automáticos – reglas que un líder de equipo ejecuta antes de una revisión de hitos, comprobaciones invocadas bajo demanda en lugar de en cada commit – un script es más apropiado que un check completo registrado en un evento de la plataforma. La sobrecarga de la infraestructura completa de checks no está justificada cuando el desencadenante es intencional y manual.

• Building blocks for larger automation – los scripts pueden ser llamados desde hooks y bloques de flujo de trabajo, lo que los convierte en unidades reutilizables dentro de automatizaciones más amplias. Un script que consulta, por ejemplo, una lista externa de proveedores aprobados puede ser llamado desde múltiples checks y hooks diferentes sin duplicar la lógica. El script se encarga de la interacción con el sistema externo; el check o hook se encarga de la decisión de política.

Scripts frente a otros elementos primitivos de Behavior Extensibility

Los scripts no sustituyen a los checks, hooks ni bloques de flujo de trabajo; son un elemento primitivo complementario con una función diferente:

Los checks están conectados a eventos de validación de la plataforma y se ejecutan automáticamente en puntos de control definidos. Los scripts se ejecutan cuando se invocan explícitamente.

Los hooks responden a eventos del ciclo de vida de la plataforma y se activan automáticamente. Los scripts se llaman de manera deliberada: por un usuario, mediante una programación o desde otro elemento primitivo de automatización.

Los bloques de flujo de trabajo son pasos reutilizables dentro de definiciones de flujo de trabajo. Los scripts pueden implementar la lógica a la que llama un bloque de flujo de trabajo, pero un script por sí solo no es un paso de flujo de trabajo.

Comience con un script cuando el requisito sea una operación enfocada, bajo demanda o programada. Traslade la lógica a un check o hook cuando necesite ejecutarse automáticamente en eventos de la plataforma. Envuélvalo en un bloque de flujo de trabajo cuando necesite componerse dentro de procesos estructurados de varios pasos.

Mantenimiento e iteración

Los scripts son archivos Python: viven en el control de versiones como cualquier otro código. Como son interpretados y no requieren un paso de compilación, la iteración es rápida: cambiar el script, desplegar, probar. Esto hace que los scripts sean el punto de partida adecuado cuando los requisitos exactos todavía no están completamente definidos, o cuando la lógica necesita evolucionar rápidamente en respuesta al uso real.

Un script que comienza como una utilidad para una sola persona a menudo acaba convirtiéndose en infraestructura compartida por el equipo. Cuando un script llega a ese punto – usado por varias personas, cubriendo un proceso crítico, con expectativas de fiabilidad – merece la pena invertir en una estructura adecuada: validación de entradas, manejo de errores, registro y, potencialmente, migración a un check o hook más formal si pasa a necesitar activación automática.