Introducción
Si llevas un tiempo utilizando Acumatica, o estás a punto de empezar a utilizar el mejor ERP del mercado, es seguro que te has encontrado -o pronto lo harás- con los paquetes de personalización de Acumatica.
Los paquetes de personalización son una parte esencial del sistema y de su extensibilidad. Es la herramienta que nos permite a los ISV, VAR y usuarios finales retocar diversas funcionalidades o redefinirlas por completo.
La mayor parte de esta información está muy bien documentada en las guías de desarrollo que ofrece Acumatica. En este artículo, sin embargo, analizaremos los efectos de publicar un paquete de personalización e identificaremos lo que sucede dentro del directorio de la instancia y su base de datos. Echemos un vistazo bajo el capó.
¿Qué hay disponible en un paquete de personalización?
Un paquete de personalización se compone de múltiples nodos/áreas asociadas a diferentes características del sistema: desarrollo de código, personalización de páginas, extensión/creación de endpoints, etc.
En este artículo vamos a analizar los efectos de dos de estos nodos. Me centraré en los que más utilizo a diario en mi trabajo.
Tenga en cuenta que el análisis de los resultados que se mostrará a continuación puede revisarse/probarse fácilmente en un entorno en el que sea posible acceder al directorio de instalación de la instancia. Si está trabajando en una instancia SaaS, es conveniente probar esto primero en un entorno local.
Nodo CODE
Está bien documentado que esta característica se puede utilizar para ampliar la funcionalidad de Acumatica. También se puede utilizar para el desarrollo de nuevas características, es decir, nuevos gráficos, nuevos DAC, o incluso sólo la codificación general de C #.
Para este ejemplo, crearemos una nueva Acción/Botón en la página de Facturas y Ajustes(AP301000):
A continuación, lo publicamos y obtenemos la funcionalidad esperada:
Veamos ahora qué ha ocurrido realmente bajo el capó:
Si vamos al directorio [Instancia]\App_RuntimeCode encontraremos un archivo .CS con el nombre del nodo y la lógica que se acaba de publicar.
Es el contenido de esta carpeta -la que utiliza Acumatica para identificar cualquier extensibilidad- el que se ha aplicado al sistema[1].
Lo realmente interesante de esto, es que podemos abrir el archivo (o crear uno nuevo) y hacer cualquier ajuste directamente desde nuestro IDE - trabajando en una interfaz más amigable con el código. Si abrimos la instancia y el archivo desde Visual Studio - por ejemplo - obtendremos el contenido real del archivo.
A continuación, podemos añadir cambios y guardarlos directamente desde VS, y estarán disponibles automáticamente sin tener que volver a publicar. Basta con actualizar el navegador, y obtendrá la nueva versión.
También puedes añadir nuevos archivos y ver inmediatamente los efectos en el sistema:
¡Achtung! Esto es estupendo para un desarrollo rápido. Sin embargo, si publica sin actualizar primero el paquete, corre el riesgo de perder los cambios. El paquete de personalización dirige el contenido. Y los cambios implementados directamente en el IDE no son la versión final del paquete.
Entonces, ¿cómo introducir estos cambios en el paquete?
Dado que no existe una opción directa para "Recargar desde Instancia", este es un proceso que tendrá que realizarse con una combinación de funciones disponibles en la IU del paquete de personalización y pasos manuales:
- Si hemos implementado cambios en un archivo que fue creado originalmente desde el paquete de personalización - en nuestro ejemplo - cs - entonces tendrás la opción de recargar el contenido si intentas publicarlo[2]:
ACTUALIZAR PROYECTO DE PERSONALIZACIÓN ⇒ toma los cambios realizados en el IDE y actualiza el paquete.
DESCARTAR TODOS LOS CAMBIOS ⇒ sobrescribe los cambios realizados en el IDE con la última versión disponible en el paquete.
Si seleccionamos la primera opción, veremos que el contenido del paquete de personalización se actualiza con los cambios implementados manualmente.
- Por otro lado, si añadimos un nuevo archivo directamente en el IDE - en nuestro ejemplo cs, entonces no hay una opción directa para "Actualizar proyecto de personalización". Este es un proceso que tendrá que hacerse manualmente. Afortunadamente, ¡es un copiar/pegar directo de nuestros cambios!
Como nota final, es importante tener en cuenta que debido a que no hay compilación o publicación involucrada en el proceso, cualquier error de sintaxis no será capturado hasta que la funcionalidad sea probada.
En conclusión, esta es una gran manera de probar rápidamente pequeños cambios sin tener que publicar o compilar, lo que a menudo es conveniente para verificar resultados y alternativas.
PANTALLAS Nodo
Ahora, vamos a profundizar en otro nodo que se utiliza muy a menudo en las personalizaciones: el nodo Pantallas.
Con esta característica, podemos personalizar las páginas existentes, o crear otras nuevas. De forma similar a lo que hicimos con el nodo CODE, vamos a ver qué ocurre cuando se publica cualquiera de estos cambios.
Por el bien de este post, vamos a hacer un ajuste drástico - no muy estético - y ubicar el campo Descripción en la tercera línea de la cabecera de la página Facturas y Ajustes. Para ello utilizaremos el control Árbol del paquete de personalización:
Entonces, ¿cómo sabe Acumatica que la página debe tener este aspecto ahora si el archivo ASPX original no ha cambiado? La respuesta está en [Instancia]\CstPublished publicado.
Cualquier personalización realizada en las páginas listas para usar se mostrará como un nuevo conjunto de archivos ASPX y ASPX.CS en esa carpeta:
Sin embargo, estos archivos no contendrán sólo los cambios específicos. Contendrán el resultado fusionado de la página original más los nuevos cambios. Se trata de una redefinición de página completa.
De forma similar a como se hizo para el nodo de código, podrá realizar cambios directos en estos archivos y ver el efecto inmediato en la interfaz de usuario. Sigamos adelante e intercambiemos los campos Estado y Descripción:
Sólo tenemos que guardar el archivo, actualizar el navegador, y el cambio estará disponible para que lo veamos:
De nuevo, como ocurre para el nodo Código, es el contenido real del Paquete de Personalización, el que maneja la información. Si se publica la versión anterior del paquete, este cambio se perderá. Por lo tanto, antes de volver a publicar el paquete, debemos asegurarnos de actualizarlo con la última versión de nuestros cambios manuales.
En este caso, no se nos ofrecerá la opción de "Recargar" como en el nodo Código. Por lo tanto, puede trabajar con la opción Acciones > Editar ASPX para realizar los cambios:
Busque el área que desea modificar, aplique los cambios y pulse el botón GENERAR GUIÓN DE PERSONALIZACIÓN:
Esta opción de editar directamente el APSX es una buena alternativa al uso del control de árbol. Sin embargo, es un poco engorrosa en ocasiones, ya que no es un control de texto plano. A medida que se implementan nuevos cambios, tarda unos segundos en responder. Personalmente recomendaría usarlo para cambios pequeños y específicos, más que para un reemplazo completo de los contenedores.
Consejo rápido: ¿Alguna vez ha realizado cambios en una página del paquete de personalización, pero no los ve reflejados en la interfaz de usuario? Sólo tienes que borrar el contenido de la carpeta CstPublished y volver a publicar tu paquete[3].
Resumen
Los nodos del paquete de personalización que se trataron en este post se aplican a todos los tenants. En otras palabras, no es posible aplicar la lógica personalizada o la página personalizada a un tenant, pero no a otro.
Sin embargo, es posible que haya visto la opción de "Publicación de varios inquilinos". Esta característica se aplica a otras áreas disponibles en el paquete de personalización, que serán cubiertos en los siguientes posts de esta serie.
¡Feliz codificación!
[1 ] hay formas alternativas de hacer esto a través del directorio Bin/, pero no lo cubriremos en este post.
[2 ] Esta función estará disponible si intenta publicar desde el propio paquete de personalización. No desde la página de proyectos de personalización (SM204505)
[3 ] Puede emular la eliminación de los archivos anulando la publicación de todos los paquetes.