Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Administración de recompensas a empleados con Office y SharePoint BCS
Ying Xiong
Administrar las recompensas a empleados es una función fundamental en todas las empresas. Esto es especialmente verdadero para empresas grandes como Microsoft. En Microsoft, ofrecemos muchos tipo de recompensas a empleados elegibles, como aumentos en el pago según sus méritos, ascensos, bonos, acciones y otros premios. Administrar estas recompensas de acuerdo con las instrucciones y los presupuestos de la empresa (establecidos para cada región, unidad de negocio u organización, plan salarial de los empleados y nivel de pago) es un proceso complejo.
Hay muchas normas de negocio en juego cuando se trata de otorgar recompensas a los empleados. Entre otros objetivos, estas normas aseguran que nuestros empleados de rendimiento sobresaliente en todos los niveles reciban las recompensas máximas mientras las organizaciones en todos los niveles cumplen sus objetivos y permanecen dentro de sus presupuestos e instrucciones. Cada año, los gerentes y personal de Recursos Humanos analizan las cifras y determinan las instrucciones o límites de cada recompensa en todos los niveles. Este proceso (denominado calibración) requiere mucho tiempo y es complicado.
La herramienta actual para la administración de recompensas que usan nuestros gerentes y personal de RR.HH. es una aplicación de Windows Forms. La herramienta funciona según como está diseñada, pero no satisface todas nuestras necesidades; existen varias maneras en que podría mejorarse para simplificar y refinar el proceso de calibración.
En respuesta a sugerencias para mejorar las herramientas de calibración, los equipos de productos de TI de Microsoft (MSIT), negocio de RR.HH. y Microsoft Office y SharePoint colaboraron para crear una solución nueva basada en Servicios de conectividad empresarial de Microsoft (BCS), una característica de Microsoft Office 2010 y SharePoint 2010. BCS proporciona acceso de lectura y escritura a datos externos desde sistemas de línea de negocio (LOB), servicios web y bases de datos, así como aplicaciones de SharePoint y Office.
La solución nueva usa Microsoft Excel 2010 como la UI de administración de recompensas y aprovecha la tecnología de BCS para almacenar en memoria caché y sincronizar datos de empleados y normas empresariales entre la máquina local del usuario y los sistemas de back-end (Servicios web de recompensas y una base de datos de SQL Server).
Este artículo comparte las experiencias de los equipos de Microsoft al desarrollar e implementar la solución de BCS de administración de recompensas.
Dónde comenzamos
La herramienta actual de administración de recompensas se diseñó para apoyar una experiencia de administración de rendimiento integrada para la evaluación de los empleados en general, la calibración, las calificaciones y las recompensas a través de un conjunto de herramientas único y cohesivo. En la Figura 1 se muestra el diseño de la arquitectura de la herramienta existente. Esta herramienta es una aplicación típica de tres niveles en que la capa de UI es una aplicación de Windows Forms que lee y escribe datos desde y hacia los servicios web de back-end. Estos servicios consultan y actualizan los registros de empleados, las normas empresariales y otros datos de referencia en una base de datos de SQL Server.
Figura 1 Arquitectura de la herramienta actual de administración de recompensas
Esta solución se diseñó para minimizar el tráfico de red entre los equipos de los usuarios y los servidores web que hospedan el componente de los servicios web. Cuando la aplicación cliente se inicia, recupera y almacena en la memoria caché todos los datos necesarios de referencia, de norma empresarial y los registros de los empleados de la organización a los cuales el usuario tiene permisos de acceso. La mayor parte de la lógica y las normas de negocio de la administración de recompensas se implementan en el componente de cliente. De allí que, cuando el usuario asigna o cambia las recompensas de los empleados, se activan las normas empresariales correspondientes para validar los cambios sin llamar a los servicios web al back-end.
El componente de servicios web se creó con el marco de servicios web de Microsoft .NET Framework 2.0 (servicios web de ASP.NET). Tal como se mencionó anteriormente, este devuelve los registros de los empleados y los datos de las normas empresariales a la aplicación de cliente y guarda los cambios de los datos que pasan de los clientes a la base de datos. Existe una lógica de validación empresarial en el servicio web para asegurar la integridad de los datos antes de que se guarden en la base de datos. Todas las llamadas de los servicios web están diseñadas como métodos asincrónicos.
Los usuarios obtiene mensajes de error cuando las llamadas de servicios web no se concretan y pueden tomar medidas basados en la naturaleza del error. Además, el servicio web se diseñó para serializar los registros de datos de los empleados y de otro tipo en una matriz de bytes y devolverla a los clientes a fin de minimizar el tamaño de los datos transferidos entre los servidores de servicios web y la aplicación de cliente.
Por último, los datos de las recompensas se almacenaban en una base de datos relacional implementada en Microsoft SQL Server 2005. Esta base de datos almacena todos los datos necesarios para administrar las recompensas de los empleados, así como los datos históricos para períodos pasados de revisión de rendimiento.
Tal como mencioné anteriormente, esta arquitectura de aplicación funcionó en gran medida como estaba pensada y significó una importante mejora respecto de recompensas y sistemas de calibración anteriores. Sin embargo, una vez en uso, detectamos muchas áreas en que podíamos mejorar la herramienta para facilitar la calibración y consumir menos tiempo. De manera que para que comprenda el razonamiento tras las decisiones de diseño para el nuevo servicio, echemos un vistazo a algunos de los problemas detectados en el antiguo.
El primer problema, y probablemente el más importante, que se encontró en la herramienta antigua de calibración implicaba la dificultad de modelar las recompensas. Durante el proceso de calibración, los gerentes deben equilibrar dos variables. Cada empleado debe recibir recompensas adecuadas basadas en una calificación de rendimiento. Sin embargo, toda la organización debe cumplir con un presupuesto definido previamente para las recompensas. Lograr este equilibrio es un proceso que consume mucho tiempo. Los gerentes deben ingresar los números de recompensas de los empleados, ver cómo afectan el presupuesto de las recompensas del equipo y ajustar las recompensas para equilibrar las normas y el presupuesto de dichas recompensas. Esto puede demorar varias iteraciones antes de que se finalicen las recompensas.
La herramienta existente no facilitaba el proceso de equilibrio entre recompensas y presupuesto. No proporcionaba capacidades para que los gerentes ingresaran números diferentes para cada recompensa y analizaran el resultado para ver el impacto en los presupuestos y las instrucciones. En su lugar, a menudos los gerentes tenían que exportar los datos de los empleados a una hoja de cálculo Excel y modelar manualmente las cifras de recompensas y presupuesto.
Cuando la calibración se completa y las recompensas de cada empleado han finalizado, los gerentes tiene que ingresar los daros en la herramienta manualmente y enviar las recompensas para aprobación. Este ingreso doble de datos también consume mucho tiempo.
La herramientas basada en Windows Forms requiere que los usuarios estén en línea y en la red corporativa, porque la herramienta requiere acceso a los servicios web de back-end para lecturas y escrituras de datos. Esto agrega otro nivel de complicaciones para los empleados con horarios ocupados o que viajan con frecuencia.
Por último, aunque la herramienta existente de administración de recompensas proporcionaba un conjunto integrado de informes, teníamos muchas solicitudes de informes adicionales y capacidades de generación de informes ad hoc flexibles para lograr que el proceso de calibración fuera más transparente y eficaz.
Aspectos básicos de BCS
BCS le permite usar aplicaciones de Office (Excel, Outlook, InfoPath, Word y otras) y SharePoint para procesar datos desde sistemas de back-end. Tal como mencioné anteriormente, BCS es un componente tanto para Office 2010 como SharePoint 2010, de manera que está disponible en los equipos de cliente y servidor. (Consulte msdn.microsoft.com/library/ee556826 para obtener más información sobre las herramientas y los componentes de tiempo de ejecución de BCS.)
Al diseñar una solución habilitada para BCS, usted empieza por definir un modelo de entidad que se puede conectar a sistemas externos y asignar datos desde esas estructuras de datos externos a la estructura de datos de BCS. Este modelo de entidad se denomina tipo de contenido externo (ECT). Puede crear tantos ECT como desee para su solución a través de SharePoint Designer o Visual Studio.
Los metadatos de ECT, incluido el código para definir el modelo de entidad, se publica y almacena en una tienda de metadatos de SharePoint. El modelo de ECT publicado se puede descargar e instalar en equipos cliente del usuario a través de un espacio de trabajo de SharePoint o mediante una herramienta de empaquetado independiente proporcionada por BCS.
En el tiempo de ejecución, el componente de tiempo de ejecución de BCS en el cliente o el servidor invoca el modelo de ECT para comunicarse con los sistemas externos. En el cliente, los datos de cualquier sistema externo se almacenan en la memoria caché del equipo del usuario en una base de datos de SQL Server Compact Edition (SQL CE). Los datos almacenados en la memoria caché luego se pueden mostrar y manipular en aplicaciones de Office a través de API de BCS. Los cambios realizados en los datos almacenados en la memoria caché por los usuarios quedarán en cola en los equipos de los usuarios en la misma base de datos de SQL CE. El componente de tiempo de ejecución de BCS es entonces responsable de actualizar los cambios en sistemas externos a través del modelo ECT.
La nueva herramienta de recompensas
Para la herramienta nueva de recompensas, creamos una solución que usa el marco de BCS, con Excel como la UI de administración de recompensas, para abordar los problemas empresariales descritos anteriormente. En esta solución Excel/BCS, definimos un total de 15 ECT para información de los empleados, normas empresariales y otros datos de referencia. El tiempo de ejecución de BCS usa estos ECT para conectarse con servicios web de administración de recompensas (como sistemas externos) y para recuperar y almacenar en la memoria caché datos de los empleados y normas empresariales.
Los datos de los empleados se presentan como una hoja de cálculo de Excel a través de un complemento de Excel que usa API locales de memoria caché de BCS. Los gerentes pueden asignar, calibrar y administrar las recompensas de sus empleados completamente dentro de Excel y aún ser capaces de hacer cumplir todas las normas empresariales basadas en los datos de normas almacenados en la memoria caché en la tienda local de BCS (aun cuando los gerentes no estén conectados). Con la solución de Excel y BCS, los gerentes pueden ver una lista de empleados seleccionados (en la hoja de cálculo de Excel) y diversas estadísticas (en el panel de tareas de Excel) en una pantalla. Las estadísticas en la parte inferior se actualizan de manera dinámica a medida que los valores de la recompensa cambian y se muestran diferentes estadísticas, dependiendo del campo seleccionado por el usuario. Se trata de una experiencia de usuario mejorada en gran medida.
Al usar las funciones nativas de Excel, como las tablas y los gráficos dinámicos, los gerentes y el personal de RR.HH. pueden crear y visualizar diversos informes para los datos almacenados en la memoria caché por BCS, con lo cual se mejora la productividad. A través de plantillas de Excel, los usuarios pueden crear informes más fácilmente y estos no requieren desarrollo de TI.
Aparte de los beneficios empresariales, un punto técnico interesante que detectamos al desarrollar esta nueva solución de administración de recompensas fue que podríamos aprovechar el componente actual de los servicios web de recompensas en la solución de BCS, aun cuando los servicios web no estaban diseñados ni optimizados para BCS. También pudimos aprovechar los objetos de datos de normas empresariales existentes y el código de validación dentro de nuestra solución de complemento de Excel. Como resultado, podemos entregar y demostrar la nueva solución en un período de tiempo relativamente corto.
Arquitectura de la solución
En la Figura 2 puede apreciar la arquitectura de la nueva solución. Como puede ver, los cambios en la arquitectura original se realizaron solo para el componente arquitectónico del cliente. En el diagrama, los cuadros verdes corresponden a componentes de BCS ya instalados en equipos de los usuarios cuando instalan Office 2010. Los cuadros azules, en tanto, son los componentes desarrollados para la nueva solución y los cuadros celestes son componentes de la herramienta actual de administración de recompensas.
Figura 2 Arquitectura de la nueva solución de recompensas
Cuando los ECT desarrollados para la nueva solución de recompensas se instalan en la máquina de un usuario, el proceso de sincronización de BCS (BCSSync.exe) inmediatamente invoca el modelo de entidad para recuperar los datos para cada ECT definido en el modelo a partir de los servicios web de recompensas externos. Los datos reales sincronizados se determinan según los permisos de acceso a los datos del usuario (obtenidos a través de los servicios web de seguridad del usuario). Este paso requiere que el usuario esté en línea para obtener acceso a los servicios web.
Los datos recuperados como registros de empleados para una organización se almacenan en una base de datos de SQL CE creada por el proceso de sincronización de BCS como la memoria caché local para el usuario. Los datos en SQL CE se cifran mediante el certificado del usuario y los datos se aseguran en el nivel de usuario.
El proceso de sincronización de BCS se ejecuta de manera periódica para sincronizar la memoria caché local del usuario con el servidor de recompensas para cualquier cambio realizado por el lado del servidor. El marco de BCS permite la capacidad para definir la frecuencia de sincronización para cada ECT de manera diferente. Esto significa que podemos definir una frecuencia de sincronización más larga (horas o días) para entidades que varían rara vez como las normas empresariales y una más corta(minutos u horas) para los datos de recompensa de los empleados que pueden cambiar con frecuencia durante el período de revisión.
Con los datos de los empleados, de las normas empresariales y de otro tipo de referencia almacenados en la memoria caché de la máquina del usuario, este puede iniciar la herramienta de administración de recompensas con solo iniciar Excel. El complemento de recompensa de Excel usa las API de BCS para recuperar datos de la base de datos de SQL CE y los vincula en una hoja de cálculo de Excel. Desde ese punto, el usuario puede ver los registros de los empleados y sus datos de recompensas en Excel. Este archivo Excel no es diferente de otros archivos Excel que crear o usa normalmente y el usuario puede emplear funciones de Excel nativas para manipular y analizar los datos.
Cuando el usuario realiza cambios en la hoja de cálculo para asignar o actualizar las recompensas de los empleados como porcentaje de aumento del salario por méritos, cantidad por ascenso o premios en acciones, las normas empresariales correspondientes se activan para validar y procesar estos cambios. Podemos lograr esto al enlazar el evento de cambio de valor de una celda de Excel con el código existente de la norma empresarial.
Además, los usuarios no pueden cambiar algunos datos de los empleados, como el número de empleado, el puesto de trabajo y la dirección de correo electrónico. Logramos este requisito al usar una función de bloqueo nativa de Excel.
Cuando el usuario está listo (en línea o sin conexión) para enviar los cambios al servidor de back-end, los cambios se envían a una cola local almacenada en la base de datos de SQL CE. El proceso de sincronización de BCS selecciona los cambios de a uno de la cola y los envía a los servicios web de recompensas de back-end. Si el usuario no está conectado o lo servicios web de back-end no están disponibles, el proceso de BCS volverá a intentar el cambio hasta que el usuario esté en línea o los servicios web estén disponibles.
Si el usuario no está listo para enviar los cambios al servidor de back-end y desea guardarlos como borrador, esto se administra como una operación normal de guardado de un archivo Excel.
Definición de los ECT
Tal como se señaló anteriormente, un primer paso importante para cualquier proyecto habilitado para BCS es crear los ECT para su solución. Diseñar ECT es el proceso de modelar las entidades de daros que usará en su solución de Office o SharePoint. La cantidad de ECT y la estructura de datos para cada ECT depende de la naturaleza de los datos de su aplicación, cómo se usan en la aplicación y las interfaces proporcionadas por sus sistemas externas.
Debido a que los datos para las entidades de ECT provienen de sistemas externos (los servicios web de recompensas, en nuestro caso), la manera más sencilla de modelar sus entidades es diseñarlas igual que los tipos devueltos desde sus sistemas externos. Esto implica ninguna asignación de datos desde una estructura a otra. Sin embargo, no siempre puede hacer esto, sobre todo cuando los servicios web externos devuelven tipos de datos complejos y tienen una jerarquía profunda. Este era el caso para el sistema de administración de recompensas.
Los servicios web de recompensas actuales devuelven una matriz de bytes serializada (para datos de empleados y normas empresariales) que debe deserializarse por el lado del cliente en tipos personalizados de System.Data.DataTable. Estos tipos de datos personalizados no son compatibles de manera predeterminada con BCS.
Nuestra implementación de ECT para el nuevo sistema de recompensas define una estructura de datos relativamente plana (con tipos de datos sencillos) para entidades de empleados y normas empresariales. Además convierte o asigna los datos de tablas de datos personalizadas (después de la deserialización) en la estructura plana de ECT. Cuando los usuarios actualizan los datos a través de los ECT, entonces convertimos los datos de vuelta en tipos de tablas de datos personalizados y enviamos los cambios a los servicios web de back-end.
Cada ECT debe tener al menos dos métodos definidos. El tiempo de ejecución de BCS invoca el método Finder para descargar todos los datos. En el caso del ECT de los empleados, devuelve todos los registros de los empleados a los que el usuario tiene permiso de acceso. Cuando un ECT se instala en una máquina cliente, el proceso de instalación crea una suscripción basada en el método Finder para el tiempo de ejecución de BCS a fin de sincronizar periódicamente el ECT.
El método SpecificFinder devuelve la instancia específica de datos (empleado) basada en el identificador de entidad (número de empleado). El tiempo de ejecución de BCS usa SpecificFinder para sincronizar la instancia de empleado con el servidor de back-end. En el caso de entidades de datos que los usuarios actualizan por el lado del cliente, como los registros de empleados, los ECT incluyen un método de actualización que el tiempo de ejecución de BCS puede invocar para enviar actualizaciones al servidor. De manera similar, si los usuarios necesitan crear nuevos registros de una entidad, se define un método de creación en el ECT. Las entidades de datos de referencia que los usuarios no cambiarán no necesitan la actualización o crean métodos para sus ECT.
Sus propias implementaciones de ECT, puede agregar cualquier lógica de negocio que necesite para validar o procesar los datos antes de invocar servicios web externos. Esta es una excelente opción de diseño con BCS que le permite colocar la lógica de negocio justo en sus ECT y ejecutarla tanto en el cliente como en el servidor.
Existen dos maneras en que puede diseñar y crear ECT. Si sus sistemas externos devuelven tipos de datos relativamente planos y fuertemente tipificados, puede usar SharePoint Designer para generar los ECT. SharePoint Designer genera ECT basados en interfaces de sistemas externos, contratos de operación y datos en el caso de los servicios web de Windows Communication Foundation (WCF). Sin embargo, en este momento, SharePoint Designer no admite tipos complejos ni personalizados como tablas de datos y conjuntos de datos personalizados.
El segundo enfoque y el más eficaz es usar Visual Studio para diseñar y crear ECT. Visual Studio 2010 incluye una plantilla de proyecto específicamente para crear modelos de entidad de BCS. Este es el enfoque que usamos en nuestra solución de recompensas.
Implementación e instalación de ECT
Para lograr que el sistema de administración de recompensas funcione, los modelos de ECT deben descargarse e instalarse en la máquina cliente. Microsoft Office y SharePoint 2010 proporcionan dos maneras para implementar los ECT. En la Figura 3 se muestra un proceso de implementación mediante SharePoint Workspace, el cual se instala en los equipos de los usuarios como parte de la instalación de Office 2010. En la Figura 4 se ilustra cómo funciona.
Figura 3 Proceso de implementación de ECT a través de SharePoint Workspace
Figura 4 Proceso de implementación de ECT a través de la herramienta de empaquetado de la solución de BCS
Primero, los ECT se publican desde Visual Studio a la tienda de metadatos de SharePoint Server (paso 1). Para que Visual Studio publique metadatos de ECT en la tienda de datos de SharePoint, se debe ejecutar en el mismo servidor en que se instaló SharePoint 2010.
A continuación, cree una lista externa para cada ECT publicado (paso 2). Puede crear la lista externa a través de la página principal de SharePoint desde cualquier equipo que se pueda conectar a SharePoint Server.
Después de crear la lista externa para un ECT, SharePoint ejecuta inmediatamente el ECT, lo cual se conecta con datos y los recupera de los sistemas externos y muestra los datos como contenido de lista en el sitio de SharePoint. Con este proceso de implementación, puede ver los datos devueltos desde su ECT en SharePoint Server, además de su aplicación de Office en el cliente. En algunas situaciones, esta es una característica deseable, pero no es obligatoria. La solución de administración de recompensas no usa esta característica porque no deseamos que datos confidenciales de recompensas de empleados se muestren a través de SharePoint.
Ahora descargue las listas externas creadas en SharePoint Server en el paso 2 en su máquina local (paso 3). Puede iniciar el proceso de descarga al conectar la página principal de SharePoint desde Internet Explorer y seleccionar Acciones del sitio | Sincronizar con SharePoint Workspace. Esto iniciará el programa SharePoint Workspace en la máquina cliente e iniciará la descarga de las listas externas una a la vez. Con la versión actual de Workspace 2010, el usuario tendrá que hacer clic en el botón Instalar para descargar cada lista externa.
Al descargar una lista externa, SharePoint Workspace instalará de manera automática el ECT (metadatos y ensamblaje) en la tienda de datos local de BCS (paso 4). Además, se crea una suscripción para el ECT instalado para que el tiempo de ejecución de BCS sincronice periódicamente los datos de ECT con los sistemas externos. La frecuencia predeterminada de sincronización de datos es de seis horas.
La solución de administración de recompensas usar un segundo proceso de implementación para instalar los ECT en las máquinas cliente de los usuarios (como se muestra en la Figura 4).
En este método de implementación, usamos la herramienta de empaquetado de la solución de BCS (code.msdn.microsoft.com/odcsps14bcspkgtool) y no hay ninguna lista externa involucrada en el proceso de implementación. Por tanto, no hay necesidad de la página principal de SharePoint ni SharePoint Workspace, aunque seguiremos usando la tienda de metadatos de SharePoint Server.
En este proceso de implementación, después de que los ECT se han publicado en la tienda de metadatos de SharePoint, usamos SharePoint Designer para exportar los ECT en un archivo modelo (.bdcm). Puede ejecutar SharePoint Designer en la máquina del servidor o en la máquina cliente y puede colocar el archivo modelo exportado en una carpeta compartida. La herramienta de empaquetado de la solución de BCS lee el archivo modelo y genera un paquete de instalación de Visual Studio Tools para Office (VSTO) que los usuarios pueden ejecutar.
Desde la perspectiva del usuario, este es un proceso de instalación simple, fácil y transparente. Los usuarios solo hacen clic una vez al ejecutar setup.exe para instalar todos los ECT exportados desde SharePoint Designer. La instalación iniciará inmediatamente BCSSync.exe para ejecutar los ECT y descargar los datos de ECT directamente desde los sistemas externos a la memoria caché de datos local de BCS.
El complemento de Excel
Tal como se describió anteriormente, rediseñamos el componente de aplicación existente de Windows Forms en un componente complementario de Excel y usamos Excel como la UI para administrar las recompensas de los empleados. El complemento de Excel realiza las funciones principales siguientes:
- Presenta registros de empleados así como orientación relacionada y estadísticas como una hoja de cálculo de Excel y un panel de tareas.
- Usa las API de BCS para recuperar datos de empleados y normas empresariales desde la memoria caché local de BCS, y escribe de vuelta cualquier cambio en la cola de actualizaciones local de BCS.
- Invoca la lógica de negocio existente cuando los usuarios realizan cambios en las recompensas de los empleados para asegurar que tales cambios cumplan con las instrucciones y los rangos mínimos/máximos correspondientes.
En la Figura 5 se muestra la nueva UI basada en Excel para la administración de recompensas. La mitad superior de la pantalla es una hoja de cálculo Excel que muestra los registros de los empleados para la organización de los usuarios. La mitad inferior de la pantalla es un panel de tareas que muestra las instrucciones para el empleado resaltado (fila seleccionada) y las estadísticas para la organización. Las instrucciones y estadísticas para las columnas seleccionadas aparecerán en la pantalla inferior.
Figura 5 Diseño de Excel para la solución de administración de recompensas
Esta interfaz sencilla y fácil de usar ayuda a los gerentes y al personal de RR.HH. a administrar de manera eficaz las recompensas de sus empleados. Realizarán todo su trabajo en una pantalla y seguirán viendo la imagen de las recompensas en general para sus organizaciones. Desde luego, pueden crear estadísticas y gráficos adicionales basados en datos de empleados de hoja de cálculo que usan funciones nativas de Excel como tablas y gráficos dinámicos.
Cuando el programa Excel se inicia, el complemento de Excel agrega una pestaña personalizada Recompensas en la barra de menú. Los usuarios hacen clic en la pestaña Recompensas y aparece una cinta con diversos botones para que los usuarios inicien y usen la solución de administración de recompensas.
Usar de las API de BCS
Desde luego, las API de BCS van al centro de cualquier solución basada en BCS. Repasemos algo de nuestro código de ejemplo para ilustrar el uso de las API de BCS.
Primero, echemos un vistazo a cierto código usado para recuperar todos los registros de los empleados desde la tienda de la memoria caché local (ver Figura 6).
Figura 6 Recuperación de registros de empleados
string entityNameSpace = "MSIT.HR.Rewards.BCS";
string entityName = "EmployeeDetails";
// Initialize and connect to BCS local cache
RemoteSharedFileBackedMetadataCatalog catalog =
new RemoteSharedFileBackedMetadataCatalog();
// Get the ECT for employee entity
IEntity entity = catalog.GetEntity(@entityNameSpace, entityName);
// Get the finder method defined for employee ECT
string methodName = entity.GetMethodInstance(
MethodInstanceType.Finder)[0].Value.Name;
IMethodInstance mi = entity.GetMethodInstance(
methodName, MethodInstanceType.Finder);
// Get external system instance
ILobSystemInstance LobSysteminstance =
entity.GetLobSystem().GetLobSystemInstances()[0].Value;
// Retrieves all instances of employee ECT
IEntityInstanceEnumerator instanceEnumerator =
entity.FindFiltered(entity.GetDefaultFinderFilters(),
mi, LobSysteminstance, OperationMode.CachedWithoutRefresh);
// Loop each employee and add it to Excel worksheet list object
while (instanceEnumerator.MoveNext()) {
... // Loop each instance of employee record and
// add it to Excel worksheet list object
}
IEntity es la interfaz principal de BCS para los ECT que define para su solución. IEntityInstance representa una instancia de datos específica para la entidad desde donde desea obtener datos. Cada ECT tiene un nombre de entidad único dentro de un espacio de nombres de entidades. Cada instancia de entidad se identifica por un Id. único que define cuando define el ECT. En este caso, es el número de empleado.
Puede actualizar un registro de empleado (o, más específicamente, una instancia de ECT de empleado) a través de un método de actualización de instancias de entidad de BCS. Esto crea una operación de actualización en la cola local de BCS. Así, habrá 10 operaciones en cola en la memoria caché local si realiza cambios en 10 registros de empleados. La sincronización de BCS procesará una operación a la vez, como:
// Query the employee instance you want to change
Identity identity = new Identity(employeeNumber);
IEntityInstance myEmployee =
entity.FindSpecific(identity, LobSysteminstance);
// Update the employee bonus amount
myEmployee["BonusAmount"] = 1000;
// Submit the changes to BCS local cache
myEmployee.Update();
El código en la Figura 7 muestra cómo consultar la memoria caché de BCS para todas las operaciones pendientes o fallidas debido a sistema externo no disponible, error y conflictos de datos.
Figura 7 En busca de operaciones pendientes o fallidas
// Initialize and connect to offline cache store
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISynchronizationManager syncManager =
offlineRuntime.GetSynchronizationManager();
IMetadataCatalog catalog =
offlineRuntime.GetMetadataCatalog();
// Get all current operations from local operation queue
IOperationCollection allOps = syncManager.GetOperations();
foreach (IOperation op in allOps) {
// ECT associated with the operation
IEntity entity = op.Entity;
// Query for operation status
string operationstatus = op.OperationStatus.ToString();
// Query for operation retry count
int retryCount = op.RetryCount;
// Get last exception message if operation errored out
string errMsg = op.LastException.Message;
// Retry the operation if status is pending or error
op.Retry();
// Decide if error is due to data conflict
if (errMsg.Contains("ConflicDetectedException"))
// Then the error is due to data conflict
}
ISynchronizationManager es la interfaz principal para el proceso de sincronización de entidades de BCS. Cada operación (IOperation) es un cambio en los datos de la entidad que procesará el tiempo de ejecución de BCS. Después del procesamiento, cada operación de actualización de datos tendrá un estado de Pendiente o En error. Si una operación se procesa correctamente, la operación se elimina de la cola y no podrá consultar la operación a través del administrador de sincronización.
Un estado Pendiente indica que la operación está pendiente debido a que el sistema externo no está disponible. BCS volverá a intentarlo de manera automática hasta que esté correcto o encuentre un error.
Un estado En error indica que la operación no se pudo procesar por los sistemas externos debido a un error de validación, un error de integridad de datos o un error de datos en conflicto.
Habrá un momento en que los usuarios desean actualizar explícitamente su memoria caché local desde los sistemas externos, en lugar de esperar a que el tiempo de ejecución de BCS realice la sincronización periódica. Así es como fuerza una actualización de datos de todos los ECT:
// Initialize and connect to offline cache
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISubscriptionManager subManager =
offlineRuntime.GetSubscriptionManager();
// Get all subscriptions
ISubscriptionCollection mysubs = subManager.GetSubscriptions();
IEnumerator<ISubscription> ie = mysubs.GetEnumerator();
while (ie.MoveNext()) {
ISubscription mySub = ie.Current;
mySub.RequestRefresh(true);
}
Tal como se mencionó anteriormente, la primera vez que un ECT se muestra e instala en la máquina de un usuario, el tiempo de ejecución de BCS crea una suscripción a los datos desde los sistemas externos en su tienda de datos local. El tiempo de ejecución de BCS usa la suscripción para sincronizar los datos de ECT con los sistemas externos.
En el código de ejemplo, ISubscriptionManager es la interfaz para obtener todas las suscripciones (ISubscription) creadas en la tienda de datos de BCS. Con un objeto de suscripción, puede hacer varias cosas, como cambiar la frecuencia de sincronización para el ECT, agregar parámetros de consulta adicionales, obtener el último estado de actualización, solicitar una actualización inmediatamente (como en el ejemplo) y obtener el número de instancias sincronizadas para el ECT.
Lecciones aprendidas
Durante el diseño, el desarrollo y la implementación de la nueva solución de administración de recompensas, obtuvimos mucha experiencia práctica con el desarrollo del complemento de Office y la implementación de BCS de SharePoint 2010. Estas son algunas de las conclusiones a las que llegamos en el camino:
Primero, pase todo el tiempo que pueda diseñando los ECT para su solución. El diseño de los ECT es clave para una solución de BCS satisfactoria. Los ECT afectan directamente el comportamiento del tiempo de ejecución de BCS y un ECT mal diseñado puede provocar que el tiempo de ejecución de BCS presente problemas o arroje excepciones fuera de la memoria.
Aprendimos esta lección de la manera difícil. Inicialmente diseñamos un gran ECT que devolvía todas las normas empresariales como una instancia única. La instancia única contenía una matriz de 40MB que provocaba que el tiempo de ejecución de BCS alcanzara su punto máximo en 600MB de uso de memoria cuando la matriz se deserializaba en objetos.
Para mitigar los problemas de uso de memoria, luego rediseñamos el gran ECT en un par de ECT separados basados en categorías de normas. Cada ECT de categoría devuelve un número de instancias de entidad igual al número real de normas. Con estos ECT nuevos y más centrados, el proceso de sincronización de BSC funciona de manera mucho más eficaz.
Otro procedimiento recomendado es usar una tipificación fuerte y una estructura relativamente plana tanto como sea posible para definir sus ECT. Si puede usar SharePoint Designer para generar los ECT, ahorrará mucho tiempo de desarrollo. Crear ECT en Visual Studio con muchos atributos de entidad le ofrece más flexibilidad, pero puede ser un proceso lento y tedioso.
Medite sus requisitos con relación a cuántos datos se pueden descargar y almacenar en la memoria caché en la máquina local de un usuario. Esto determina cómo implementará el método Finder para su ECT. Desde luego, los datos devueltos desde las llamadas de su sistema externo establecen el límite para el número de registros que puede descargar. Si el diseño de ECT necesita más datos que el límite, entonces los sistemas externos deberán cambiarse para cumplir su requisito.
En nuestra solución de recompensas, un gerente puede descargar y almacenar en la memoria caché los registros de los empleados para su organización únicamente. De esta manera, es probable que dos usuarios diferentes tengan dos conjuntos diferentes de datos de empleados descargados en su memoria caché local. Los servicios web de recompensas existentes autentican al usuario y devuelven solo los datos de los empleados a los que el usuario tiene permitido el acceso. En otras palabras, el filtrado de datos se realiza en los sistemas externos y la implementación de ECT no tiene que filtrar los datos basada en los permisos del usuario. Si este no es el caso para su solución, tendrá que considerar el diseño adicional y el tiempo de desarrollo para filtrar los datos de ECT para la memoria caché local.
En su implementación de ECT, administre las excepciones del sistema externo con cuidado. En algún punto, sus implementaciones de ECT para los métodos Finder y SpecificFinder tendrán que invocar métodos del sistema externo para recuperar datos. Tendrá que captar y administrar excepciones arrojadas desde los sistemas externos de su código. Sin embargo, tendrá que arrojar la excepción de vuelta al tiempo de ejecución de BCS después de controlarla. De lo contrario, el tiempo de ejecución de BCS pensará que la llamada a los sistemas externos fue satisfactoria, devolverá cero filas de datos y eliminará los datos que ya se encuentran en la memoria caché local. Definitivamente no le conviene que la memoria caché de datos locales se elimine a causa de una excepción al sistema externo.
Existen consideraciones adicionales en relación con el uso de bibliotecas de terceros en su implementación de ECT. En uno de nuestros ECT, tuvimos que hacer referencia a un ensamblaje desarrollado por otro grupo para llevar a cabo una lógica de negocio y transformación de datos adicionales. Durante la implementación del ECT, descubrimos que el ensamblaje al que se hizo referencia no se implementó en máquinas cliente como parte de la instalación de ECT. Por consiguiente, BCS no pudo ejecutar el ECT ni descargar los datos.
Al momento que escribo este artículo, estamos trabajando con el equipo de productos de BCS para diseñar una solución. La solución alternativa es agregar el ensamblaje a la memoria caché de ensamblaje global como parte de la instalación de VSTO.
Es muy importante probar y depurar sus ECT. Las ejecuta el tiempo de ejecución de BCS en segundo plano y no puede depurar los ECT desde Visual Studio cuando se ejecutan en máquinas de cliente. Nuestra recomendación es que pruebe y depure sus ECT por el lado del servidor al crear listas externas en SharePoint. Cuando ve y cambia el contenido de una lista externa en una página de lista de SharePoint, está ejecutando el código ECT asociado con la lista externa y puede depurar el ECT desde una instancia de Visual Studio que se ejecuta en el mismo servidor de SharePoint.
Por último, es vitalmente importante que comprenda el modo de operación de la entidad de las API de BCS. En la aplicación por parte del cliente que usa las API de BCS para manipular las instancias de entidad de ECT, hay cuatro modos de operación que puede usar para administrar los datos de ECT. A continuación, una descripción rápida de cómo funcionan:
- OperationMode.CacheWithoutRefresh: cuando se usa este modo de operación para la instancia de una entidad, BCS devuelve la instancia de entidad desde la memoria caché. Si los datos no se encuentran en la memoria caché, BCS la actualiza desde sistemas externos y devuelve la copia en caché. Si no se puede establecer contacto con los sistemas externos, BCS arroja una excepción.
- OperationMode.CacheWithImmedicateRefresh: con este modo de operación, BCS actualiza la instancia de entidad en la memoria caché primero desde el sistema externo y luego devuelve la copia en caché. Si no se puede establecer contacto con el sistema externo, BCS devolverá la copia en caché de todos modos. Si la instancia de entidad no se almacena en la memoria caché y no se puede establecer contacto con el sistema externo, BCS arroja una excepción.
- OperationMode.Offline: con el modo de operación sin conexión, nunca se establece contacto con los sistemas externos incluso si no hay datos en la memoria caché. BCS devuelve la instancia de entidad desde la memoria caché. Si no está ahí, BCS arroja una excepción.
- OperationMode.Online: en el caso del modo de operación en línea, BCS nunca usará los datos almacenados en la memoria caché local y siempre se pondrá en contacto con los sistemas externos para obtener una copia de la instancia de entidad. Si no se puede establecer contacto con el sistema externo, BCS arroja una excepción.
Conclusión
Microsoft Office y SharePoint 2010 con BCS proporcionan la base para implementar una solución simple, fácil de usar y eficaz para que las empresas administren los datos empresariales desde varios sistemas externos con UI de Office familiares. Esta base facilita los datos empresariales y la disponibilidad de proceso en cualquier parte y en cualquier momento, con lo cual aumenta la productividad de negocio.
La infraestructura de sincronización de BCS soluciona muchos problemas asociados con copias, cambios y conflictos de datos. Una de las ventajas de la sincronización de BCS sobre otros marcos de sincronización de datos es que BCS permite que sus soluciones incrusten una lógica empresarial y de validación de datos en el proceso de sincronización a través de implementaciones de ECT. Otro beneficio de BCS es la capacidad de sincronizar datos compuestos desde varios sistemas dispersos (nuevamente a través del diseño de ECT), en lugar de la sincronización de datos punto a punto que proporcionan muchos otros marcos de sincronización.
Ying Xiong es un destacado arquitecto del equipo de TI de Microsoft, a cargo de la arquitectura y el diseño de aplicaciones e integraciones empresariales al interior de Microsoft. Trabaja en diversas tecnologías de Microsoft para crear aplicaciones empresariales distribuidas. Puede ponerse en contacto con Xiong en yingx@microsoft.com.
Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Rolando Jimenez Salgado y Satish Thatte