Extensión de la aplicación para diferentes poblaciones de usuarios

En una aplicación empresarial global, es posible que deba ampliar la aplicación existente para cumplir con los requerimientos de expansión del negocio. Entre los requerimientos de extensión de aplicación más comunes, se incluyen los siguientes:

• extender una aplicación para una nueva población de usuarios,
• dividir una población de usuarios existente.

Con el fin de ampliar la aplicación existente para el nuevo conjunto de usuarios, puede usar uno de los siguientes métodos:

• ampliar la aplicación dentro de la base de datos existente, 
• ampliar la aplicación mediante la implementación en una nueva base de datos.

Método 1: Ampliar la aplicación dentro de la base de datos existente 

Para admitir una nueva población de usuarios dentro de una base de datos existente, ejecute New Application wizard con el fin de generar una aplicación que amplíe las clases de los tipos de casos de la aplicación existente. El asistente crea un nuevo grupo de clase para la nueva población de usuarios; los datos del caso se almacenan en tablas separadas. 

Por ejemplo, es posible que necesite una nueva población de usuarios para manejar eventos de transmisión en línea en la aplicación FSG actual. Cree una nueva aplicación o evento de transmisión en línea ampliando la aplicación Booking.

Las instancias de asignaciones y archivos adjuntos en la aplicación no se pueden separar en diferentes tablas según la aplicación. Puede aprovechar las siguientes propiedades de la organización para restringir el acceso entre estas aplicaciones. 

Supongamos que la nueva población de usuarios está asociada con la nueva división, y esta nueva población de usuarios no debe acceder a ninguna asignación creada en la división original. La solución más sencilla es implementar una política de acceso de lectura en la clase Work- que haga referencia a la siguiente condición de política de acceso. 

pyOwnerDivision = Application.pyOwningDivision

Y pyOwnerOrg = Application.pyOwningOrganization

Método 2: Ampliar la aplicación mediante la implementación en una nueva base de datos

La especialización de rulesets dentro de nuevas aplicaciones basadas en la aplicación existente sería suficiente como para admitir una nueva población de usuarios, siempre que estén alojados en una nueva base de datos.

Por ejemplo, imaginemos que existe un requerimiento para que una nueva población de usuarios maneje los eventos de música en línea. Cree una nueva aplicación, Evento de transmisión en línea, ampliando la aplicación Booking . Aloje esa nueva aplicación de eventos de música en línea dentro de una nueva base de datos.

En algunas situaciones, es posible que desee dividir en subconjuntos la población de usuarios existente de una aplicación. Cada uno de los subconjuntos resultantes accede a una aplicación específica de la población de usuarios construida sobre la aplicación original.

Cuando hay casos activos en una población de usuarios, y existe el mandato de subdividir esa población de usuarios en dos aplicaciones distintas, la creación de reportes y la seguridad se vuelven problemáticos. La clonación de la base de datos existente no es el enfoque correcto. Si la aplicación usa un procesamiento en segundo plano, existe un procesamiento duplicado. 

Son posibles dos de los principales enfoques de implementación:

• mover un subconjunto de la población de usuarios existente a una nueva base de datos,
• crear subconjuntos de la población de usuarios existente dentro de la base de datos original.

Mover un subconjunto de la población de usuarios existente a una nueva base de datos,

Imagine que crea una nueva base de datos para admitir una población de usuarios subdividida y no se requiere la migración inmediata de usuarios. En ese caso, puede realizar una transición gradual de los datos de usuario o cuenta de la base de datos existente a la nueva base de datos. Idealmente, transfiera datos de usuario o cuenta comenzando con clases que tengan la menor cantidad de dependencias. Por ejemplo, los datos de archivos adjuntos no hacen referencia a otras instancias.

Copie los casos resueltos para un usuario o una cuenta determinados en la nueva base de datos, pero no elimine de inmediato del sistema original los casos resueltos. Se recomienda esperar hasta que se complete el proceso de migración para el usuario o la cuenta. Use el Purge/Archive wizard para realizar esta tarea (Dev Studio > Configure > System > Operations > Purge/Archive) (Dev Studio>Configurar> Sistema > Operaciones > Purgar/Archivo). Opcionalmente, modifique las propiedades de organización de datos de casos para reflejar la nueva población de usuarios.

Un requerimiento para mover inmediatamente un subconjunto de una población de usuarios existente a una nueva base de datos es más complejo debido a la probabilidad de casos abiertos. Use el Package Work wizard para realizar esta tarea (Dev Studio > Configure > Application > Distribution > Package Work) (Dev Studio > Configurar > Aplicación > Distribución > Paquete de trabajo).

Crear subconjuntos de la población de usuarios existente dentro de la base de datos original.

La situación más compleja se presenta cuando se exige la separación inmediata de la población de usuarios dentro de la misma base de datos. Un subconjunto de los casos existentes debe refactorizarse a diferentes nombres de clase para admitir este requerimiento.

Manipular el modelo de datos de casos para una jerarquía de casos completa mientras un caso está activo es arriesgado y complejo. Por este motivo, busque el asesoramiento y la asistencia de un ejecutivo de Pega antes de intentar dividir la población de usuarios para la misma aplicación dentro de la misma base de datos.