Considerazioni sulle prestazioni delle funzionalità

Le attività dei Runbook possono inoltre essere considerate come dotate di due diversi tipi di codice: un codice di piattaforma e un codice di dominio. Il termine codice di dominio viene utilizzato per identificare il codice richiamato in un'attività del Runbook generalmente non associata al prodotto Orchestrator. Ad esempio, l'attività standard Richiama servizi Web conterrà il codice di piattaforma Orchestrator (l'"impianto" dell'attività), nonché il codice di dominio univoco per il richiamo di un servizio Web. Il codice di piattaforma sarà univoco ma simile per la maggior parte delle attività, poiché deriva da un framework comune. Tuttavia, le differenze nel codice di dominio per le varie attività potrebbero essere potenzialmente significative.

I Runbook Orchestrator sono progettati sostanzialmente per passare i dati tra gli elementi discreti del codice di dominio.

Sebbene non obbligatorio a livello tecnico, ogni attività utilizza in genere i dati pubblicati creati dalle precedenti attività del Runbook. L'utilizzo dei dati pubblicati da parte della specifica attività che li sottoscrive dipende interamente dal codice di dominio.

Tutte le attività del Runbook creano dati pubblicati, che vengono definiti dati pubblicati comuni. Il codice di dominio crea solitamente dei dati pubblicati, definiti dati pubblicati per attività specifiche. Analogamente al codice di dominio, anche questi dati saranno univoci per una determinata attività. Inoltre, non è necessario che il codice di dominio produca dati pubblicati.

I dati prodotti da una determinata attività possono contenere elementi di dati singoli o multivalore. Ad esempio, ogni attività produce un solo record di dati con valore singolo definiti dati pubblicati comuni. Il codice di dominio può produrre più record di dati multivalore.

La diramazione è un concetto fondamentale di Orchestrator. Una specifica attività del Runbook crea una diramazione se corrisponde all'origine di due o più collegamenti le cui condizioni di filtro indicano la presenza di dati da passare all'attività alla fine del collegamento. Quando viene richiamato per la prima volta, un Runbook è formato da un singolo thread. Quando il thread rileva un'attività del Runbook i cui collegamenti richiedono una diramazione, vengono creati dei thread aggiuntivi, uno per ogni diramazione. Ogni thread accetta come input i dati pubblicati dall'attività che ha creato la diramazione. Questi dati vengono nuovamente correlati alle attività precedenti nel Runbook (da qui la possibilità di sottoscrivere i dati pubblicati dalle attività precedenti).

L'esperienza dell'operatore si basa su due componenti: la console Orchestration e il servizio Web. La console Orchestration è un'applicazione Silverlight che dipende dal servizio Web per la connessione al database di Orchestrator. Il servizio Web è un'applicazione IIS che si connette al database. Pertanto, il servizio Web e la console Orchestration sono fortemente dipendenti dalle prestazioni del database di Orchestrator 2012.

Alcune parti del database di Orchestrator 2012 sono nuove per il prodotto e supportano direttamente il servizio Web. Tuttavia, parti del servizio Web dipendono dalla struttura del database legacy Opalis 6.3.

Inoltre, sebbene la console Orchestration dipenda dal servizio Web, dispone anche di una logica univoca per la propria funzione di interfaccia utente con specifiche caratteristiche in termini di prestazioni.