El cumplimiento de ciertas recomendaciones durante el desarrollo de diversos componentes de los complementos de Orchestrator contribuye a una mejor calidad de los complementos.

Tabla 1. Recomendaciones útiles para la implementación de complementos

Componente

Elemento

Descripción

General

Acceso a API de terceros

Los complementos deberían proporcionar métodos simplificados para acceder a API de terceros siempre que sea posible.

Interfaz

Los complementos deberían proporcionar una interfaz estándar para los usuarios, aunque la API no lo haga.

Acción

Objetos de creación de scripts

Debería crear acciones para cada creación, modificación, eliminación y los demás métodos disponibles para un objeto de creación de scripts.

Descripción

La descripción de una acción debería describir qué hace la acción, no cómo funciona.

Creación de scripts

Al usar la creación de scripts para obtener las propiedades o métodos de un objeto, puede comprobar si el valor del objeto es distinto de null o undefined.

En desuso

Si una acción está en desuso, la instrucción comment o throw debería indicar la acción de reemplazo; o la acción debería llamar a una nueva acción de reemplazo para que no fallen las soluciones basadas en la versión en desuso.

Flujo de trabajo

Operaciones de interfaz de usuario en la tecnología orquestada

Debería crear un flujo de trabajo para cada operación disponible en la interfaz de usuario de la tecnología orquestada.

Descripción

La descripción de un flujo de trabajo debería describir qué hace el flujo, no cómo funciona.

Propiedad de presentación mandatory input

Debe configurar la propiedad mandatory input para todas las entradas de flujo de trabajo obligatorias.

Propiedad de presentación default value

Si desarrolla un flujo de trabajo que configura una entidad, la presentación del flujo de trabajo debería cargar los valores de configuración predeterminados para esta entidad. Por ejemplo, si desarrolla un flujo de trabajo denominado Configuración de host, la presentación del flujo de trabajo debe cargar los valores predeterminados de la configuración de host.

Propiedad de presentación Show in inventory

Debe configurar la propiedad Show in inventory para tener flujos de trabajo contextuales en objetos de inventario.

Propiedad de presentación specify a root parameter

Debería usar esta propiedad en flujos de trabajo cuando no sea necesario examinar el inventario desde la raíz del árbol.

Validación de flujos de trabajo

Debe validar los flujos de trabajo y corregir todos los errores.

Creación de objetos

Todos los flujos de trabajo que crean un objeto nuevo deberían devolver este como parámetro de salida.

En desuso

Si se deja de usar un flujo de trabajo, las instrucciones comment o throw deberían indicar el flujo de trabajo de reemplazo; o el flujo de trabajo debería llamar a un nuevo flujo de trabajo de reemplazo para que no fallen las soluciones basadas en la versión en desuso.

Inventario

Desconexión de host

Si el inventario contiene una conexión a un host y este deja de estar disponible, debería indicar que el host se ha desconectado. Puede hacerlo asignando otro nombre al objeto raíz, añadiéndole - disconnected, o quitando el árbol de objetos debajo de este, como lo hace el complemento de vCloud Director.

Propiedad Select value as list

Un objeto de inventario debe estar seleccionable como treeview o como list.

Administrador de host

Si el complemento implementa un objeto host para el sistema de origen, debería existir un objeto raíz hostmanager principal con propiedades para agregar, quitar y editar propiedades de host.

Obtener o actualizar objetos

Si hay un servicio de consultas en ejecución en la tecnología orquestada, debería usarlo para obtener varios objetos.

Detección de objetos secundarios

Si tiene que recuperar objetos secundarios uno por uno, el proceso de recuperación debe ser de tipo multiproceso y no bloqueable por un solo error.

Cambio de objetos de Orchestrator

Todos los flujos de trabajo que pueden cambiar el estado de un elemento en el inventario deben actualizar este para evitar que haya objetos desincronizados.

Cambio de objetos externos

Puede usar un mecanismo de notificación de cambios producidos en la tecnología orquestada como resultado de operaciones realizadas fuera de Orchestrator. Si esas operaciones provocan la desaparición de objetos de la tecnología orquestada, tendrá que actualizar el inventario según corresponda, para evitar fallos o pérdidas de datos. Por ejemplo, si una máquina virtual se elimina de vCenter Server, el complemento de vCenter Server actualiza el inventario para quitar el objeto de la máquina virtual eliminada.

Objeto de buscador

Los objetos de buscador deberían tener propiedades utilizables para diversos objetos. Estas propiedades son las que suelen estar presentes en la interfaz de usuario.

Objeto de creación de scripts

Implementación

Se debe implementar el método equals para asegurar el funcionamiento de la operación == en el mismo objeto, ya que en ciertos casos podría haber dos instancias de un objeto.

Propiedades de objetos de complementos

Los objetos que tienen objetos principales deberían implementar una propiedad parent.

Propiedades de objetos de complementos

Los objetos que tienen objetos secundarios deberían implementar métodos GET que devuelvan matrices de objetos secundarios.

Objetos de inventario

Los objetos de inventario deberían admitir búsquedas con Server.find.

Todos los objetos de inventario deberían ser serializables para poder usarse como atributos de entrada o salida de un flujo de trabajo.

Constructor y métodos

En la mayoría de los casos, los objetos de scripts deberían tener un constructor o ser devueltos por otros métodos o atributos de objeto.

ID de objeto

Los objetos con un ID emitido por un sistema externo deberían usar un ID interno para asegurar que no hay duplicaciones de ID al orquestar más de un servidor.

Buscar objetos

Los métodos search o find deberían implementar un filtro para encontrar el nombre o ID especificado, en lugar de todos los objetos. Por ejemplo, el servidor de Orchestrator tiene un método Server.FindForId que permite encontrar un objeto de complemento por su ID. Para ello, el método se debe implementar para cada objeto localizable en el complemento.

Activador

De ser posible, debería haber activadores disponibles para objetos cambiantes, de modo que se activen políticas de Orchestrator al producirse diversos eventos. Por ejemplo, para determinar cuándo se agrega, enciende, apaga, etc. una máquina virtual, Orchestrator puede supervisar un activador o un evento en el complemento de vCenter del objeto Datacenter.

Propiedades de objetos

Los objetos que residen en otros complementos deberían tener propiedades que faciliten la conversión de un objeto de complemento a otro. Por ejemplo, los objetos de máquina virtual deben tener un moref (ID de referencia de objeto administrado).

Administrador de sesión

Si se va a conectar a un servidor remoto que puede tener otra sesión, el complemento debería implementar una sesión compartida y una sesión por usuario.

Activador

Activador

Todos los métodos de bloqueo y operaciones largas deberían poder iniciarse de forma asincrónica con una tarea devuelta, y generar un evento de activador al completarse.

Enumeraciones

Enumeraciones

Las enumeraciones para un tipo determinado deberían tener un objeto de inventario que permita seleccionar entre los diversos valores de la enumeración.

Registro

registros

Los métodos deberían implementar distintos niveles de registro.

Control de versiones

Versión de complemento

La versión de complemento debería ser acorde con los estándares y actualizarse junto con el complemento.

documentación de las API

Métodos

Los métodos descritos en la documentación de API nunca deberían devolver la excepción no xyz method / property para un objeto. Deberían devolver null cuando no hay propiedades disponibles y documentarse con detalles cuando estas propiedades no están disponibles.

vso.xml

Todos los objetos, métodos y propiedades deben documentarse en vso.xml.