Consideraciones sobre el rendimiento de características

A pesar de la gran varianza en su diseño y complejidad visual, los runbooks son simples. Los runbooks básicamente hacen tres cosas: ejecutar actividades, administrar datos publicados y rama.

Funciones de la característica de Orchestrator

Además, las actividades de los Runbooks tienen dos tipos de código distintos: código de plataforma y código de dominio. El término código de dominio se utiliza para identificar al código que se llama en una actividad de Runbook normalmente no asociada con el producto Orchestrator en sí. Por ejemplo, la actividad estándar Invoke Web Service contendría código de plataforma de Orchestrator (la canalización de la actividad) y el código de dominio único para invocar un servicio web. El código de la plataforma será único pero similar para la mayoría de las actividades, ya que se crea a partir de un marco común. Sin embargo, es posible que existan importantes variaciones en el código de dominio de las distintas actividades.

En general, los Runbooks de Orchestrator están diseñados para pasar datos entre elementos discretos de código de dominio.

Aunque técnicamente no siempre es así, en general todas las actividades consumen datos publicados por actividades de Runbooks anteriores. Las acciones que realiza una actividad determinada con los datos publicados a los que se suscribe depende en su totalidad del código de dominio.

Todas las actividades de los Runbooks crean datos publicados, que también se conocen como Datos publicados comunes. El código de dominio normalmente crea datos publicados, que suelen denominarse Datos publicados según la actividad. Estos datos tendrán el mismo carácter de exclusivos para una actividad determinada como el propio código de dominio. Además, no es necesario que el código de dominio genere datos publicados.

Los datos que produce una actividad determinada pueden contener elementos de datos de valor único o múltiple. Por ejemplo, cada actividad produce un único registro de datos de valor único que se conocen como datos publicados comunes. El código de dominio puede producir varios registros de datos de valor múltiple.

La bifurcación es un concepto fundamental para Orchestrator. Una actividad de runbook determinada creará una rama si es el origen de dos o más vínculos cuyas condiciones de filtro indican que hay datos para pasar a la actividad al final del vínculo. Cuando se invoca un runbook por primera vez, consta de un único subproceso. Cuando dicho subproceso encuentra una actividad de Runbook cuyos vínculos requieren una bifurcación, se crean subprocesos adicionales, uno para cada bifurcación. Cada subproceso toma como entrada los datos publicados de la actividad que creó la bifurcación. Estos datos se correlacionan con las actividades anteriores del runbook (por lo tanto, la capacidad de suscribirse a datos publicados de actividades anteriores).

La experiencia del operador se basa en dos componentes: la consola de orquestación (nueva) y la API web. La consola de orquestación es una aplicación Angular que depende de la API web para su conexión a la base de datos de Orchestrator. La API web es una aplicación IIS que se conecta a la base de datos. Por lo tanto, la API web y la consola de orquestación dependen del rendimiento de la base de datos de Orchestrator.

Las partes de la base de datos de Orchestrator son nuevas en el producto y admiten directamente la API web. Sin embargo, los componentes del servicio web dependen de la antigua estructura de base de datos Opalis 6.3.

Además, aunque la consola de orquestación depende de la API web, también tiene lógica única para su función como una interfaz de usuario que tendrá sus propias características de rendimiento.