Al implementar un complemento puede aplicar diversos enfoques, como usar objetos de caché y objetos en el fondo, clonar objetos, etc. De esa forma se puede mejorar el rendimiento de los complementos, evitar problemas de simultaneidad y mejorar la respuesta del cliente de Orchestrator.

Objetos de caché

El complemento puede interactuar con un servicio remoto, y esta interacción la proporcionan los objetos locales que representan a objetos remotos en el lado de servicio. Para lograr un buen rendimiento del complemento así como una buena respuesta de la interfaz de usuario de Orchestrator, puede poner en caché los objetos locales, en lugar de tener que obtenerlos de un servicio remoto cada vez que se requieren. Puede decidir el ámbito de la memoria caché, por ejemplo: una caché para todos los clientes del complemento, una por cada usuario del complemento y una por cada usuario del servicio de terceros. Al implementar el mecanismo de caché, se integra con la interfaz del complemento para encontrar e invalidar objetos.

Usar objetos en el fondo

Si tiene que mostrar listas de objetos largas en el inventario del complemento y no tiene un método rápido para recuperar esos objetos, puede usar objetos en el fondo. Para ello puede, por ejemplo, tener objetos con dos estados: fake y loaded. Teniendo en cuenta que los objetos fake son muy fáciles de crear y proporcionan la información mínima que mostrar en el inventario (por ejemplo, el nombre y el ID), sería posible devolver siempre objetos fake, y cuando se necesita toda la información (el objeto real), la entidad que lo requiere o el complemento pueden llamar a un método load automáticamente para obtener el objeto real. Incluso puede configurar el proceso de carga de objetos para que se inicie automáticamente después de que se devuelvan los objetos falsos, para prever las acciones de la entidad que los usa.

Clonar objetos para evitar problemas de simultaneidad

Si usa una caché para su complemento, tiene que clonar objetos. Puede haber efectos imprevistos si usa una caché que siempre devuelve la misma instancia de un objeto para cada entidad que lo solicita. Por ejemplo, la entidad A solicita el objeto O, y la entidad visualiza el objeto en el inventario con todos sus atributos. Al mismo tiempo, la entidad B solicita el objeto O también y la entidad A ejecuta un flujo de trabajo que empieza a cambiar los atributos del objeto O. Al final de la ejecución, el flujo de trabajo llama al método update del objeto para actualizar el objeto en el lado del servidor. Si las entidades A y B obtienen la misma instancia del objeto O, la entidad A ve en el inventario todos los cambios que realice la entidad B, incluso antes de que los cambios se validen en el lado del servidor. Si la ejecución se realiza correctamente, no debería haber problemas; pero si la ejecución falla, no se revertirán los atributos del objeto O para la entidad A. De ocurrir eso, si la caché (las operaciones de find en el complemento) devuelve un clon del objeto en lugar de la misma instancia continuamente, cada entidad ve y modifica su propia copia, y se evitan problemas de simultaneidad, al menos dentro de Orchestrator.

Notificar cambios a otros

Se pueden producir problemas si se usa una caché mientras se clonan objetos. El problema más grave es que el objeto que usa vistas de entidad podría no ser la versión más reciente disponible. Por ejemplo, si una entidad muestra el inventario, los objetos se cargan una vez pero, al mismo tiempo, si otra entidad está cambiando objetos, la primera entidad no ve esos cambios. Para evitar este problema puede usar los métodos PluginWatcher y IPluginPublisher de la API de complemento de Orchestrator para notificar que algo ha cambiado para permitir que otras instancias de clientes de Orchestrator vean los cambios. Esto también es aplicable a una sola instancia del cliente de Orchestrator cuando los cambios de un objeto del inventario afectan a otros objetos del inventario y también es necesario notificarlos. Las operaciones que más tienden a usar notificaciones son las de añadir, actualizar y eliminar objetos cuando estos, o algunas de sus propiedades, aparecen en el inventario.

Activar la localización de cualquier objeto en cualquier momento

Debe implementar el método find de la interfaz IPluginFactory para encontrar objetos solo por tipo e ID. El método find se puede llamar directamente después del reinicio de Orchestrator y la reanudación de un flujo de trabajo.

Simular un servicio de consultas si no existe uno

El cliente de Orchestrator puede requerir consultas para algunos objetos en casos específicos o que se muestren no en estructura de árbol sino como listas o tablas, por ejemplo. Esto significa que el complemento debe poder realizar consultas de conjuntos de objetos en cualquier momento. Si la tecnología de terceros ofrece un servicio de consultas, tendrá que adaptarse a usar este servicio. De no hacerlo así, tal vez pueda simular este tipo de servicio, aunque podría ser una solución más compleja o de rendimiento inferior.

Los métodos de búsqueda no deberían devolver excepciones de tiempo de ejecución

Los métodos de la interfaz IPluginFactory que implementan las búsquedas dentro del complemento no deberían devolver excepciones de tiempo de ejecución, ni controladas ni no controladas. Esto podría causar extraños fallos de error de validación error de validación durante la ejecución de un flujo de trabajo. Por ejemplo, entre dos nodos de un flujo de trabajo, se llama al método find si una salida del primer nodo es una entrada del segundo nodo. En ese momento, si el objeto no se encuentra por haberse producido una excepción de tiempo de ejecución, puede que lo único que obtenga en el cliente de Orchestrator sea un error de validación. Después de eso, obtendrá más o menos información en los archivos de registro dependiendo de cómo registra excepciones el complemento.