¿De quién es esa feature?

Abre lmstat y verás features: ANSYS, nx_design, CATIA_V5_HARDWARE, acad_2024. Abre tu sistema de compras y verás aplicaciones: ANSYS Mechanical, Siemens NX, CATIA, AutoCAD. Las dos listas se solapan, pero no son la misma lista, y el mapeo entre ellas es donde se acumula en silencio una buena parte del trabajo de gestión de licencias — y de sus errores.

LiMon construye y mantiene ese mapeo por ti. El modelo mental es pequeño una vez lo ves, y el resto de este artículo va de exponerlo con claridad para que no tengas que ir descubriendo cada pieza por accidente.

Las tres entidades del modelo

Servidores. Un daemon de licencias — FlexLM, RLM, LM-X, DSLS, Sentinel — corriendo en algún sitio de tu red y sirviendo features. LiMon lo consulta, observa lo que tiene y registra lo que está en uso.

Aplicaciones. Una entidad de negocio en la que tu equipo realmente piensa: “ANSYS Mechanical”, “NX”, “CATIA V5”. Una aplicación es un nombre que tu departamento financiero reconoce y una línea de coste anual que todo el mundo entiende. La creas pulsando “Añadir Aplicación” — o eligiendo de la biblioteca de plantillas de productos habituales (que pre-rellena patrones de mapeo de features razonables para ese producto) o partiendo de cero. Muchos servidores de licencias sirven más de una aplicación; algunas aplicaciones se reparten entre varios servidores por región, redundancia o failover.

Despliegues. El enlace entre los dos. La mayor parte del tiempo aparecen como efecto secundario del flujo de aplicaciones — marcas servidores en la aplicación que acabas de añadir (o abres una existente y enlazas más servidores después) y se crea un registro de despliegue por cada marca. Si prefieres trabajar desde el otro extremo, la página de administración de Despliegues te deja crearlos directamente: eliges aplicación, eliges servidor, escoges el ámbito de alcance, guardas. Cualquiera de las dos rutas produce el mismo registro. Cada despliegue lleva metadatos sobre el entorno (PROD/TEST/DEV/DR), si está activo y el modo de ámbito de features del que hablaremos a continuación.

Los servidores existen desde el momento en que los configuraste para que se consulten — están ahí etiquetes o no lo que contienen. Las aplicaciones, en cambio, son inertes por sí solas: una aplicación sin ningún servidor enlazado es solo un nombre en una lista, no hace nada. El trabajo que hace el resto del sistema — atribución, seguimiento de uso, informes de coste — solo se pone en marcha cuando una aplicación tiene al menos un despliegue.

Compartido vs. Exclusivo: opciones al enlazar un servidor

Al enlazar un servidor a una aplicación, eliges un feature scope mode o ámbito de alcance. Hay dos:

Exclusivo. Este servidor aloja solo esta aplicación. Toda feature servida desde él — actual y futura — pertenece a esta app de forma automática. La primera vez que LiMon refresca la atribución tras el enlace, toda feature del servidor queda reclamada. Cualquier cosa que aparezca después (un nuevo entitlement, el vendor añade un SKU, una renovación trae un módulo extra) también queda reclamada sin que hagas nada. Es el valor por defecto al enlazar un servidor a una app, porque el caso más común es realmente un servidor, una aplicación.

Solo puede haber un despliegue exclusivo activo por servidor. Eso es debido al significado de exclusivo.

Compartido. Este servidor aloja varias aplicaciones, y hay que resolver de algún modo a quién pertenece cada feature. Varios productos de Adobe en un mismo servidor de licencias es el ejemplo clásico; aplicaciones de Siemens como Simcenter o Amesim corriendo en paralelo es otro. Con Compartido, enlazar el servidor por sí solo no reclama ninguna feature. Se quedan sin atribuir hasta que una regla de mapeo de features en una de las aplicaciones co-desplegadas le diga a LiMon qué pertenece a quién.

La elección correcta no suele ser un compromiso. Si el servidor de verdad sirve solo un producto, deja el Exclusivo por defecto y sigue. Si está sirviendo features de varias aplicaciones de negocio, marca el enlace como Shared (Compartido) y asume que harás una pequeña configuración inicial con mapeos de features.

Cómo se atribuyen las features en la práctica

Cuando LiMon refresca la atribución en un servidor — algo que ocurre tras una consulta que detecta inventario nuevo, tras cambiar un despliegue, tras editar un mapeo de feature o bajo petición — recorre cada feature actualmente visible en ese servidor y se hace cuatro preguntas, en orden:

1. ¿Esta feature ya estaba atribuida a una aplicación que sigue enlazada activamente aquí? Si sí, se mantiene. Las decisiones de atribución anteriores son persistentes — una vez que una app ha reclamado una feature en un servidor, los refrescos no la deshacen mientras esa app siga enlazada al servidor.
2. ¿Hay un enlace Exclusivo activo en este servidor? Si sí, todas las features sin atribuir van a esa aplicación como reclamación automática.
3. ¿Exactamente una de las aplicaciones co-enlazadas tiene una regla de mapeo de features que case con este nombre de feature? Si es así, esa aplicación la reclama. Las reglas pueden ser nombres exactos (nx_design) o patrones tipo LIKE de SQL (CATIA_V5_%), definidos una vez por aplicación en la página de administración de mapeos de features.
4. ¿Casó el patrón de más de una aplicación? Entonces la feature es ambigua — y no se reclama. LiMon prefiere sacar a la luz el conflicto que elegir un ganador en silencio.

Si ninguna de esas cuatro resuelve la feature, se queda en estado sin resolver y aparece como “Sin mapear” en la vista del servidor.

Dos ideas que conviene interiorizar:

• Los patrones solo cuentan para aplicaciones ya enlazadas al servidor. Una regla con patrón en la Aplicación X no tiene efecto en el Servidor Y a menos que X esté enlazada a Y. Esto evita la trampa de que un patrón genérico reclame por accidente features en un servidor con el que la aplicación no tiene nada que ver.
• La ambigüedad es una feature, no un bug. Cuando dos aplicaciones podrían reclamar legítimamente una misma feature, dejarla sin atribuir te obliga a mirarla. O quitarás uno de los patrones que compite, o ajustarás el que era demasiado amplio, o descubrirás que el servidor en realidad no debería compartirse entre esas dos aplicaciones.

Los campos de “Prioridad”

LiMon tiene dos números de prioridad sin relación entre sí ligados a despliegues y mapeos. Hacen trabajos muy diferentes.

Prioridad de despliegue

Visible en cada tarjeta de despliegue en la página de detalle de la aplicación. Por defecto 1, los números más bajos van primero. Su propósito es ordenar los despliegues de una aplicación cuando los visualizas, para que puedas señalar “este es el sitio principal para esta app” sin que sea un campo aparte.

Lo que explícitamente no hace: decidir quién gana cuando dos aplicaciones comparten un servidor y ambas tienen reglas que casan con la misma feature. Ese caso cae en el cubo ambiguo de arriba. La prioridad de despliegue es una pista de presentación por aplicación, no un árbitro entre aplicaciones.

Así que si tienes AutoCAD e Inventor ambos enlazados como Compartido al mismo servidor, y ambas listas de patrones casan de algún modo con dwg_export, subir o bajar los números de prioridad de despliegue no lo arreglará. Ajustar uno de los patrones sí.

Prioridad de regla de mapeo

Visible en cada fila de la página de administración de Mapeos de Features. Por defecto 100, los números más bajos van primero. Su propósito es desempatar dentro de la lista de reglas de una aplicación: si la Aplicación X tiene dos reglas que casan con el mismo nombre de feature, gana la que tenga el número de prioridad más bajo, y asigna a esa feature su nombre de display y sus metadatos de paquete.

El caso de uso canónico es un fallback amplio junto a una excepción específica. Supón que CATIA tiene una regla atrapa-todo CATIA_* con prioridad 100, y otra más específica CATIA_V5_DESIGNER con prioridad 10. Cuando CATIA_V5_DESIGNER aparece en un servidor, gana la regla específica y la feature recibe el nombre de display correcto; todo lo demás que case con CATIA_* cae en el patrón amplio y recibe la etiqueta genérica. Sin prioridad de regla tendrías que escribir cada patrón para que fuera mutuamente excluyente — algo que se vuelve tedioso muy rápido en un producto con docenas de features.

Como en el campo del despliegue, esta prioridad tampoco arbitra ambigüedad entre aplicaciones. La lista de reglas de cada aplicación se evalúa de forma independiente — la prioridad dentro de la app elige el mejor match para esa app, y solo después LiMon comprueba si más de una aplicación hizo una reclamación. Si lo hicieron dos, la feature va al cubo ambiguo da igual qué lado tuviera el número de prioridad más bajo.

Un modelo mental rápido

Ámbitos diferentes, sin interacción:

• Prioridad de despliegue ordena los servidores de una aplicación entre sí (cuál es el primario).
• Prioridad de mapeo de feature ordena las reglas de una aplicación entre sí (qué patrón gana cuando varios casan dentro de la misma app).
• Ninguna decide nada entre aplicaciones distintas. Los conflictos entre aplicaciones se resuelven siempre por la regla de ambigüedad de arriba.

Veo una feature sin mapear. ¿Cómo la reclamo?

La ruta soportada:

1. Confirma que la aplicación está realmente enlazada al servidor en cuestión. Sin enlace, ningún patrón puede reclamar nada ahí.
2. Ve a la página de administración de Feature Mappings y crea una regla cuyo patrón case con el nombre de la feature — exacto o LIKE — y asígnala a la aplicación.
3. Guardar la regla dispara un refresco de atribución en los servidores afectados. Si la feature estaba en el cubo de no resueltas y ningún patrón de aplicación competidora casa con el mismo nombre, queda reclamada y pasa a la lista de features de la aplicación en el siguiente ciclo de refresco.

Si estaba en el grupo ambiguo en lugar de no resuelta, añadir otra regla no ayuda — solo profundizará la ambigüedad. El arreglo es mirar las otras aplicaciones que tienen patrones que casan y o bien quitar el patrón competidor o estrecharlo.

Si tienes un servidor de una sola aplicación pero está actualmente configurado como Compartido, la solución directa es cambiar el enlace a Exclusivo — eso reclamará automáticamente todas las features del servidor sin necesidad de patrones. Solo ten en cuenta que es a nivel de servidor entero: cualquier cosa que esté ahora en él, más lo que aparezca después, queda atribuida a esa única aplicación.

Una técnica de diagnóstico gratuita

Cuando algo no te cuadre en la lista de features de una aplicación, la comprobación más barata es comparar dos páginas:

• La página de detalle del servidor muestra cada feature actualmente licenciada en ese servidor, independientemente de la atribución. Es el inventario real.
• La página de detalle de la aplicación muestra solo las features atribuidas a esa aplicación a través de todos sus despliegues. Es la vista filtrada.

Toda feature que aparezca en la página del servidor pero no en la de la aplicación cae en uno de estos tres grupos:

• Reclamada por otra aplicación en el mismo servidor.
• Ambigua — varias aplicaciones tenían patrones que casaban y ninguna se la llevó.
• Sin resolver — ningún patrón casó y el despliegue no la reclamó automáticamente.

Normalmente puedes saber en cuál cae mirando las otras aplicaciones desplegadas en el servidor, pero el origen de resolución de cada reclamación también queda registrado, así que una herramienta de administración puede mostrarte la razón directamente cuando la comparación entre pantallas no basta.

¿Por qué es así el modelo?

En el mundo real, los servidores de licencias no siempre siguen el modelo limpio de “un servidor, un producto”. Los publishers agrupan varios títulos en un mismo daemon. Los vendors consolidan productos adquiridos en el servidor que ya tenían en marcha. Un equipo reutiliza un servidor de licencias existente para una herramienta pequeña nueva porque montar otro no compensa. En todos esos casos, la lista cruda de nombres de features que devuelve un daemon — acdlt_2024, prem_pro, solver_token_a — no le dice por sí sola a nadie qué features pertenecen a qué línea de presupuesto, qué aplicación, qué conversación de renovación.

El modelo de atribución de LiMon es la capa más pequeña que une esas dos vistas, y la mayoría de sus beneficios derivados salen de él gratis. El mismo mapeo que decide “esta feature pertenece a AutoCAD” también alimenta el nombre amigable que ves en paneles, informes, vistas de expiración y resúmenes de denegaciones — así que IT y compras acaban mirando las mismas palabras en la misma página en vez de discutir sobre mnemónicos crudos del vendor. También te da una forma limpia de escalar un servidor compartido sin tener que dividirlo: dos pilares de CAD en un solo daemon siguen siendo un solo daemon. LiMon hace el trabajo de atribución; el servidor de licencias subyacente no tiene que reestructurarse.

El propio modelo intenta opinar cuando las opiniones son baratas y explícito donde lo que está en juego es real:

• La atribución es persistente — una vez una feature ha sido reclamada para una app en un servidor, los refrescos no la deshacen mientras esa app siga enlazada ahí.
• Los enlaces Exclusivos son una señal honesta de “este es el único dueño” que recoge features nuevas automáticamente y no hay que revisitarla nunca.
• Las reglas con patrón te dejan codificar los mapeos obvios una vez y dejar de mantenerlos.
• Los casos ambiguos salen a la luz en lugar de elegirse en silencio, porque una elección silenciosa equivocada es peor que una feature sin mapear que sí puedes ver.

El efecto neto es que las partes del sistema que pueden automatizarse en silencio lo están, y las partes donde alguien tiene que pensar están visiblemente esperando que alguien piense en ellas. Esa es la diferencia entre una herramienta que te ayuda a gestionar licencias y una que solo te enseña números.

Dónde encaja LiMon

LiMon consulta servidores FlexLM, RLM, LM-X, DSLS… en tu red, construye y mantiene el mapeo de aplicación a feature descrito arriba, y lo convierte en informes de utilización, documentación de defensa ante auditorías y munición para conversaciones de renovación. Se ejecuta en tu hardware — sin nube, sin agentes en los servidores de licencias, sin phone-home. Solicita una evaluación para probar el flujo de atribución, y elige Standard o Professional para la escala de servidores, la analítica y los informes de auditoría que ponen a trabajar el modelo.