Considérations relatives aux performances des fonctionnalités

En outre, les activités de Runbook peuvent être considérées comme ayant deux types de code : le code de plate-forme et le code de domaine. Le terme code de domaine désigne le code appelé au sein d'une activité Runbook et qui n'est généralement pas associé au produit Orchestrator même. Par exemple, l'activité standard Appeler le service Web contient du code de plate-forme Orchestrator (qui constitue la « plomberie » de l'activité) ainsi que du code de domaine unique pour l'appel d'un service Web. Le code de plate-forme est unique mais similaire pour la plupart des activités, dans la mesure où il est construit à partir d'une infrastructure commune. Cependant, il existe potentiellement une variation importante du code de domaine pour différentes activités.

Les Runbook Orchestrator sont essentiellement conçus pour transmettre des données entre des éléments distincts du code de domaine.

Bien que cela ne soit pas obligatoire techniquement, chaque activité consomme généralement les données publiées créées par des activités de Runbook précédentes. Ce que fait une activité donnée avec les données publiées auxquelles elle s'inscrit dépend entièrement du code de domaine.

Toutes les activités de Runbook créent des données publiées, que l'on appelle des données publiées communes. Le code de domaine crée généralement des données publiées, que l'on appelle des Données publiées spécifiques aux activités. Ces données sont aussi uniques à une activité donnée, tout comme le code de domaine. En outre, il n'est pas obligatoire que le code de domaine produise des données publiées.

Les données produites par une activité donnée peuvent contenir des éléments de données à valeur unique ou à valeurs multiples. Par exemple, chaque activité produit un seul enregistrement de données à valeur unique appelé données publiées communes. Le code de domaine peut produire plusieurs enregistrements avec des données à valeurs multiples.

La création de branche est un concept fondamental pour Orchestrator. Une activité de Runbook donnée crée une branche si celle-ci constitue l'origine de deux liens ou plus dont les conditions de filtre indiquent la présence de données à transmettre à l'activité à l'extrémité du lien. Lors du premier appel d'un Runbook, celui-ci consiste en un thread unique. Lorsque ce thread rencontre une activité de Runbook dont les liens nécessitent une branche, des threads supplémentaires sont créés, un pour chaque branche. Chaque thread prend comme entrée les données publiées à partir de l'activité qui a créé la branche. Ces données sont corrélées aux activités préalables du Runbook (d'où la possibilité de s'abonner à des données publiées à partir d'activités précédentes).

L'intervention de l'opérateur s'appuie sur deux composants : la console Orchestration et le service Web. La console Orchestration est une application Silverlight qui dépend du service Web pour sa connexion à la base de données Orchestrator. Le service Web est une application IIS qui se connecte à la base de données. Par conséquent, la console Orchestration et le service Web dépendent fortement des performances de la base de données Orchestrator 2012.

Certaines parties de la base de données Orchestrator 2012 sont des nouveautés du produit et prennent directement en charge le service Web. Toutefois, certaines parties du service Web dépendent de la structure de la base de données héritée d'Opalis 6.3.

En outre, même si la console Orchestration dépend du service Web, elle possède aussi une logique unique à sa fonction d'interface utilisateur dotée de ses propres caractéristiques en termes de performances.