Hemos creado un nuevo método para adaptar aplicaciones a consumidores específicos: el método de extensiones.
¿Qué tiene de bueno las extensiones?
Las extensiones ofrecen una estrategia diferente a la ya existente, que implica un cambio en las configuraciones estándar. El uso de esta nueva estrategia facilitará sustancialmente el soporte de soluciones estándar adaptadas a las necesidades de una implementación específica o de un cliente específico.
¿Cuál es la estructura de este proceso en este momento? Aquí hay una configuración estándar. Está completamente respaldada por el proveedor. Esto significa que no se puede modificar. De vez en cuando, el proveedor lanza nuevas versiones (mejoradas) de esta configuración. En tal situación, la actualización de la versión antigua de la configuración a una nueva versión se completa automáticamente. Esto es conveniente y no requiere habilidades o conocimientos especiales por parte del cliente.
Pero muchas veces el cliente querrá agregar o cambiar algo en la configuración estándar para “adaptarla a ellos mismos”. Para hacerlo, el modo de soporte tendrá que cambiar y la configuración ya no estará completamente respaldada. Nuestro socio que completa la implementación, o los propios especialistas en TI del cliente, realizarán los cambios necesarios. Después de eso, la actualización automática completa de la configuración estándar a una nueva versión lanzada por el proveedor se vuelve imposible.
En este momento, la actualización de la configuración requerirá la intervención de un especialista. Además, si los cambios realizados basados en la voluntad del cliente fueron significativos, también se pueden requerir gastos significativos de tiempo por parte del especialista que completa la actualización de la configuración. Y muchas veces, se puede requerir un nivel muy alto de conocimiento tanto para la configuración estándar en sí como para realizar correcciones.
La estrategia de usar extensiones se describe de la siguiente manera. Si desea cambiar la configuración estándar, no toque la configuración en sí. Realice todos los cambios en la extensión, que es esencialmente una configuración también.
En el modo 1C:Enterprise, simplemente conecte su extensión a la configuración estándar. La plataforma combinará automáticamente su extensión con la configuración estándar en el modo 1C:Enterprise. Como resultado, el cliente trabajará con la solución estándar modificada según sus necesidades.
Cuando el proveedor lanza una nueva versión de la configuración estándar, se realiza una actualización automática, siempre y cuando el modo de soporte de la configuración estándar no haya cambiado. Ha permanecido completamente respaldado por el proveedor. Y cuando se inicia la aplicación actualizada, la plataforma combina automáticamente la configuración estándar modificada con su extensión una vez más. Y el cliente continúa operando con la solución estándar modificada según sus preferencias.
¿Cuándo necesitas usar las extensiones?
El método de extensiones es atractivo por su universalidad. Por esta razón, es importante comprender completamente qué tipo de tareas está diseñado para cumplir.
En primer lugar, las extensiones son irremplazables cuando la aplicación está operando en modo de separación de datos, por ejemplo, en modo SaaS. Uno de los suscriptores quiere tener un par de informes adicionales. Mientras tanto, el resto de los clientes quieren operar con la configuración estándar sin cambios.
En este caso, puedes desarrollar una extensión específicamente para ese cliente, donde puedes hacer realidad todos sus deseos. El cliente adjuntará esta extensión y trabajará con la configuración modificada. Mientras tanto, para el resto de los clientes, no se realizarán cambios porque todas las extensiones se adjuntan y se lanzan de acuerdo con los valores de separador actuales.
Otra situación es ajustar la configuración estándar adaptada para un cliente específico para su implementación en su ubicación o, también, ajustar la configuración estándar realizada por los especialistas en TI de los clientes por su cuenta para su propio uso. Si todo este ajuste fino se realiza en la extensión, entonces la configuración estándar seguirá siendo completamente compatible, lo que facilita significativamente su soporte continuo.
Puede que te tientes a usar las extensiones para crear aplicaciones de producción en masa; sin embargo, esto no es una buena idea. En primer lugar, las extensiones no están diseñadas para tareas como estas y, en segundo lugar, otras características de la plataforma, por ejemplo, la funcionalidad de entrega y soporte, no saben nada acerca de las extensiones.
Si echas un vistazo al pasado en el surgimiento de las extensiones, entonces, sin duda, hemos visto y vemos ahora que las configuraciones se están volviendo cada vez más complejas. Vemos que se requiere soporte adicional en varios niveles de desarrollo: biblioteca, módulo, soporte de la industria, y así sucesivamente. Hemos analizado todas estas tareas y hemos llegado a la conclusión de que la adaptación de las configuraciones a las necesidades de los clientes durante la implementación es la máxima prioridad en este momento.
Específicamente para estas tareas creamos la funcionalidad de las extensiones. Por supuesto, se pueden observar varias características y otras tendencias de desarrollo enumeradas en ella. Pero no son su propósito principal y no deberían confundirte.
¿Qué puedes cambiar usando las extensiones en este momento?
Hasta ahora, no se ha completado mucho de lo que se planea hacer. Las extensiones, por supuesto, se desarrollarán aún más. Pero lo que ya se ha hecho puede resultar útil en muchos casos de implementación. En este momento puedes:
- Modificar los formularios gestionados existentes en una configuración estándar
- Agregar nuevos subsistemas o cambiar el contenido de los subsistemas dentro de una configuración estándar
- Modificar los roles de la configuración estándar agregando objetos creados en una extensión en ellos
- Modificar la interfaz de comandos de una configuración estándar (de la sección principal, subsistemas)
- Agregar nuevos informes y procesadores de datos
Planeamos continuar expandiendo gradualmente la funcionalidad de las extensiones y estaremos encantados de recibir tu opinión sobre qué funcionalidad es la más demandada para implementaciones que requieren pequeños ajustes.
¿Cómo está diseñada la extensión?
Una extensión es muy similar a una configuración regular. También se representa en forma de un árbol de objetos. Para trabajar con una extensión, se utilizan las mismas prácticas que para las configuraciones regulares.
Una característica importante de una extensión es que contiene objetos adoptados. Cualquier objeto de configuración estándar se puede adoptar utilizando un comando en el menú contextual:
No siempre son necesarios los objetos adoptados. Se explica mejor utilizando un ejemplo “cotidiano”, con la analogía de una cena en un restaurante.
La primera situación es cuando los objetos adoptados son necesarios.
Te has acostumbrado a cenar regularmente en el mismo restaurante. Siempre pides un filete y un poco de té cuando vas allí. Digamos que son realmente buenos en este restaurante en particular, o por cualquier otra razón. No importa. Lo único que importa es que esto es lo que vas a tener, no otra cosa.
En este caso, el restaurante es una base de datos de información estándar y tú eres una extensión. El menú del restaurante es la configuración estándar. El filete y el té, mientras tanto, son objetos adoptados. Los has adoptado (has aprendido que están en el menú).
¿Cómo se conecta la extensión a la configuración y cómo funciona? Vas al restaurante y pides el menú. En el menú ves que tienen filete y té. En otras palabras, estableces una correspondencia entre los objetos adoptados y los objetos de configuración estándar. Naturalmente, estableces la correspondencia basándote en los nombres 
. Te traen el filete y el té y los tienes, lo que significa que la extensión está conectada y funciona.
Una semana después, vuelves al restaurante, pero esta vez el menú del restaurante ha cambiado (se ha actualizado la configuración estándar). Sin embargo, todavía tienen filete y té en el menú y eso es exactamente lo que quieres. Te los traen. Los consumes. En otras palabras, la extensión sigue funcionando con una configuración estándar actualizada.
Luego, una semana después, vuelves al restaurante una vez más y ves que el filete y el té han desaparecido del menú. Te levantas y te vas (mensaje de error de conexión de extensión) porque eso es exactamente lo que querías tener. Y no tienes idea de ningún otro plato (objeto). El desarrollador no te enseñó cómo comer caracoles y langosta correctamente.
Es una situación completamente diferente cuando puedes prescindir de cualquier objeto adoptado.
Vas al restaurante, pero no te interesan los platos específicos que tienen porque de todos modos no vas a comer ninguno. Solo estás allí para tomar fotos. Y tienes la capacidad de tomar fotos de cualquier plato que quieras. En ese caso, simplemente te conectas a la configuración y dices: trae todos los aperitivos que tengas en el menú (recibes una colección de documentos de metadatos). Voy a volver a publicar (fotografiar) ellos.
Hablando en términos más mundanos utilizados por los desarrolladores, dirías que los objetos deben ser adoptados:
- Cuando son necesarios para una construcción visual. Por ejemplo, expandes un formulario y agregas un atributo de formulario como CatalogCurrencies.Ref. Entonces, por supuesto, tendrás que adoptar el catálogo Currencies para asegurarte de que el atributo aún existe en el catálogo al adjuntar la extensión a la configuración estándar.
- Cuando son necesarios para que funcione un script. Por ejemplo, en un script de extensión llamas al atributo Importer del catálogo Products. Entonces, este atributo también debe ser adoptado para asegurarte de que dicho atributo aún existe en el catálogo Products al adjuntar la extensión.
Conectando una extensión
Has creado una extensión en Designer. Después de depurarla y probarla, puedes guardar la extensión en el archivo *.cfe.
Puedes enviar este archivo al cliente. El cliente lo cargará de forma independiente en su base de datos en el modo 1C:Enterprise utilizando la función estándar Administrar extensiones de configuración.
La operación con extensiones está disponible desde el script de 1C:Enterprise, por lo que en la aplicación podrás crear tu propio procesador de datos que cargará las extensiones. Para evitar que los usuarios regulares estropeen las extensiones, hemos agregado un nuevo derecho: Administración de extensiones de configuración.
Cuando cargas una extensión desde un archivo, se almacena en la base de datos. Ten en cuenta que se almacena de acuerdo con los valores actuales del separador de sesión.
Para que la extensión “comience a funcionar”, será necesario reiniciar la sesión. Cuando comienza la sesión, todas las extensiones almacenadas en la base de datos y que coinciden con los valores actuales del separador se adjuntarán inmediatamente antes del evento de llamada SessionParametersSetting.
Como resultado, mientras operas en modo de separación de datos, la extensión se aplicará solo a los usuarios de ese suscriptor específico. Y si no se utiliza la separación de datos, entonces la extensión funcionará para todos los usuarios de la base de datos.
Cuando se conectan las extensiones, como dijimos, se controla que los objetos adoptados existan en la configuración estándar. Se realiza una comparación de los objetos basada en sus nombres.
Además de eso, también es posible un control más flexible. No solo puedes controlar la existencia de los objetos en sí, sino también la condición de sus propiedades individuales. En otras palabras, si volvemos a la analogía con el restaurante y el filete, puede que no solo sea importante para ti que tengan un filete cocido, sino también que puedan cocinarlo poco hecho, “con sangre”.
Volviendo a la extensión, normalmente no controla las propiedades de los objetos adoptados. Pero si es necesario, puedes hacer que ciertas propiedades sean controlables. Por ejemplo, es importante para tu algoritmo que no solo exista un catálogo CuentasBancarias, sino que su código tenga un tipo Cadena.
Entonces, si en la configuración estándar el proveedor cambia el tipo de código de este catálogo a Número, tu extensión lo detectará durante la adjunción y devolverá un error.
Un aspecto interesante se relaciona con el cambio de nombre de los objetos de la configuración estándar. Por ejemplo, vas al restaurante y en el menú en lugar de decir Filete dice Carne de res. En este caso, al conectarse a la configuración, la extensión no encuentra el catálogo Productos porque el proveedor lo ha renombrado a Bienes.
Ahora esa situación ya no te supone un problema. Y no necesitas revisar todo el código de la extensión para escribir Bienes en lugar de Productos. El algoritmo que cambia el código del módulo después de renombrar los objetos de la configuración y el algoritmo de refactorización hacen todo el trabajo. Así que solo tienes que cambiar el nombre del objeto adoptado a Bienes y el resto de los cambios en la extensión se realizarán automáticamente por la plataforma o con un esfuerzo mínimo de tu parte.
El funcionamiento de las extensiones
Podemos hablar durante bastante tiempo sobre las características de varias extensiones de objetos y sobre las características de cómo funcionan las extensiones en sí. Pero estamos limitados por los límites de un artículo de resumen y solo podremos tocar los aspectos clave y más demostrativos de ello.
La principal “atracción” de las extensiones no es, por supuesto, que puedas agregar algo a la configuración estándar que no tenga. Sino más bien, que puedes cambiar en una extensión lo que la configuración estándar ya tiene. En otras palabras, puedes cambiar las propiedades de los objetos adoptados.
El concepto principal utilizado durante la cooperación de una configuración y una extensión se puede describir de la siguiente manera. En los lugares donde “no se intersectan”, la extensión complementa la configuración. Y en los lugares donde “se intersectan”, se aplica la extensión.
Puedes ver esto con más detalle en el ejemplo de los formularios gestionados. Puedes adoptar un formulario de la configuración principal y editarlo en la extensión sin ninguna limitación. Se utilizan dos combinaciones estratégicas diferentes para la parte visual del formulario y su módulo.
La parte visual del formulario se fija en la extensión durante su adopción. En el modo 1C:Enterprise, las modificaciones para cada elemento del formulario se analizan en relación con esta condición tanto en la configuración estándar como en la extensión.
Si no hay cambios o solo están en la configuración estándar, se aplica el valor de la configuración estándar. En todos los demás casos, se aplica el valor de la extensión.
Así que si has agregado un nuevo comando al formulario en la extensión, lo verás junto con el resto de los comandos del formulario. Y si has cambiado el título de un grupo existente, verás tu título incluso si el proveedor cambia el título del grupo en la configuración estándar.
Otro enfoque se utiliza para los módulos de formulario. Para el formulario adoptado en una extensión, se crea un nuevo módulo con sus propios controladores de todos los eventos. En el modo 1C:Enterprise, ambos módulos de formulario (de la configuración estándar y la extensión) se combinan en un solo contexto. Por esta razón, cada extensión tiene su propio prefijo que se agrega a los controladores de todos los eventos en el módulo de formulario para evitar la superposición de los controladores de la configuración estándar. Después de eso, los controladores de eventos y comandos se llaman de forma secuencial y sincrónica: primero, el controlador de la extensión, luego, el de la configuración estándar. Puede cambiar esta secuencia o puede prohibir totalmente la ejecución de un controlador de la configuración estándar.
De hecho, en lo que respecta a la cooperación de la configuración y la extensión en el modo 1C:Enterprise, existen en un solo espacio de nombres. Esto se aplica no solo a los módulos separados, sino también a los árboles de metadatos en sí. Por lo tanto, no es posible determinar en el modo 1C:Enterprise si este objeto es “nativo” para la configuración estándar o si surgió de la extensión.
Para el resto de los objetos que puede utilizar en la extensión, todo parece mucho más simple.
En la extensión, puede crear sus propios subsistemas. Utilizando los objetos adoptados, puede ampliar los subsistemas existentes: agregar objetos y subsistemas que ya existen en la configuración estándar o aquellos que ha creado en la extensión. No puede eliminar algo de un subsistema existente.
Solo puede ampliar los roles agregando objetos creados en la extensión. No puede eliminar nada del rol existente. Esto también se aplica a la interfaz de comandos.
Una extensión es casi una configuración
Dijimos al principio que una extensión es similar a una configuración ordinaria. Por esta razón, en conclusión, me gustaría decir algunas palabras sobre cómo se integran las extensiones con las demás características de la plataforma.
Una extensión (al igual que una configuración regular) tiene una configuración principal y una configuración de base de datos. La comparación y fusión de configuraciones funcionan con las extensiones de la misma manera que con las configuraciones regulares.
Puede exportar una extensión a un archivo (por supuesto, con una extensión diferente *.cfe) y cargarla desde el archivo. Las extensiones se pueden exportar/importar desde archivos XML.
La búsqueda global de texto en la interfaz, los métodos de reemplazo y edición también funcionan con las extensiones.
También han surgido nuevas opciones de línea de comandos para trabajar con extensiones, así como eventos en el registro de eventos.
En el script de 1C:Enterprise, el objeto principal para trabajar con extensiones es ConfigurationExtensionsManager.
