Création de types d'événements

Cette rubrique fournit des instructions permettant de créer des types d'événements. Un type d'événement définit les événements publiés par la source de l'événement ou consommés par le récepteur d'événements. Dans le cadre du développement, ils sont spécifiés en tant que types primitifs uniques, comme les classes .NET Framework, ou comme structures, et définissent les données (charge utile) associées à chaque événement dans le flux d'événements. Les types d'événement sont utilisés dans les étapes de développement suivantes :

1. Écriture d'un adaptateur typé. Un adaptateur typé utilise le type d'événement comme un paramètre générique afin que la structure appropriée soit initialisée lors de la création d'objets d'événement à mettre en file d'attente.

2. Écriture d'un modèle de requête. Un modèle de requête est spécifié dans LINQ sur un objet CepStream, dont la définition est basée sur un type d'événement.

Pour plus d'informations sur les événements et les flux d'événements, consultez Concepts du serveur StreamInsight.

Déterminer la structure de l'événement

Lorsque la charge utile de l'événement (autrement dit, le nombre de champs dans la charge utile et leurs types) est fixe et connue d'avance, vous pouvez créer un adaptateur typé. Avec un adaptateur typé, toutes les instances de l'adaptateur produisent le même format de charge utile fixe. C'est en général le cas pour les sources d'événement avec une structure de données fixe.

Lorsque vous créez un adaptateur typé, vous définissez une classe ou une structure .NET qui représente la charge utile fixe ou vous utilisez un type primitif si la charge utile d'événement peut être représentée par un seul champ. En cas d'utilisation de structures ou de classes, vous ne pouvez utiliser que des champs et propriétés publics comme champs de charge utile. Les champs privés et les propriétés, ainsi que les méthodes de classe sont ignorés et ne peuvent pas être utilisés dans le type d'événement. Vous utilisez cette déclaration de type d'événement pour remplir le type d'événement dans l'adaptateur d'entrée et pour obtenir le résultat du type d'événement typé dans l'adaptateur de sortie. L'exemple suivant définit un type d'événement simple qui a deux champs de charge utile, V1 et V2, de type int.

    public class MyPayload
    {
        public int V1 { get; set; }
        public int V2 { get; set; }
    }

Un autre exemple illustre l'utilisation d'un type d'événement imbriqué :

    public class ComplexPayload
    {
        public ValueType Value { get; set; }
        public bool Status  { get; set; }
    }

    public class ValueType
    {
        public double Value { get; set; }
        public int Quality  { get; set; }
    }

Un adaptateur non typé est utile lorsque vous souhaitez que le même adaptateur soit configurable pour une source ou un récepteur spécifique afin qu'il puisse gérer plusieurs types d'événements. Le format de la charge utile de ces types d'événements est fourni à l'adaptateur dans le cadre d'une spécification de configuration lorsque l'adaptateur est lié à la requête. Un fichier .csf qui contient un nombre variable de champs est un exemple d'un tel scénario. Le jeu exact de champs qui composent une charge utile peut être déterminé uniquement par le concepteur de requêtes (et non pas par le développeur qui génère l'adaptateur) au moment de la liaison et de l'instanciation de la requête. Un adaptateur pour les tables SQL, où le type des événements produits dépend du schéma de la table ou de la requête émise par rapport à la table, constitue un autre exemple. Pour plus d'informations, consultez Création d'adaptateurs d'entrée et de sortie.

La spécification d'un modèle de requête est basée sur un objet CepStream avec un type d'événement spécifique, qui doit être connu au moment de la conception. Les objets CepStream intermédiaires, ainsi que la spécification du modèle de la requête, peuvent contenir des types nouveaux définis implicitement dans les clauses du projet (« select » dans LINQ), à l'aide de l'expression de membre init.

Spécifications des champs de charge utile

Lorsque vous créez des types d'événements, tenez compte des spécifications requises pour les champs de charge utile et des fonctionnalités suivantes :

• Une structure d'événement ne peut pas avoir de structure de charge utile vide. Au moins un champ est requis.

• Les types .NET Framework scalaires et élémentaires et les types imbriqués peuvent être utilisés pour les champs de charge utile. Consultez la section « Types de données pris en charge » qui suit.

• Les champs ne peuvent pas être modifiés à l'aide d'attributs personnalisés.

• Les types d'événements sur le serveur StreamInsight sont une liste triée de champs plutôt que des structures .NET, qui n'imposent pas d'ordre au niveau des champs. L'ordre des champs d'événement devient important pour les adaptateurs non typés. Ces adaptateurs accèdent aux champs par ordinal parce que les champs ne sont pas connus au moment de la conception des adaptateurs. Par convention, une structure .NET, utilisée comme un type d'événement, classe ses champs d'après l'ordre lexicographique de leurs noms. 

• La possibilité de valeur NULL du champ est déduite. Par exemple, int? est Nullable contrairement à int. Les types String et byte[] sont toujours Nullable.

• La taille par défaut de byte[] est 512.

• La longueur maximale des champs de type String dépend uniquement de la taille de page pour l'événement entier, soit 16 kilo-octets.

Taille de l'événement

Il n'y a aucune limitation explicite du nombre des champs qui peuvent être définis dans le type d'événement. Le nombre de champs dépend du type des champs individuels, de leur taille et de leur capacité à contenir une valeur NULL.

La taille de la page d'événement dans le serveur StreamInsight est de 16 Ko. Étant donné qu'un événement ne peut pas couvrir plusieurs pages, la taille de 16 Ko, moins quelques surdébits, est la taille d'événement maximale efficace (incluant les champs de charge utile et d'horodateur). En plus des surdébits fixes concernant l'en-tête de page, l'en-tête d'événement et les champs système tels que l'horodateur, l'acceptation des valeurs NULL vient s'ajouter au surdébit variable dans un ordre de grandeur de N/8 ajusté à la limite supérieure.

Pour maximiser l'utilisation de la page d'événement, nous vous recommandons de suivre les instructions suivantes :

• Évitez les champs nullables.

• Minimisez l'utilisation des champs string et byte[].

• Conservez les durées de vie d'événement uniquement telles que requises par la sémantique du scénario respectif, afin que la mémoire nécessaire à l'état d'événement puisse être libérée plus efficacement dans le moteur.

Détectabilité des types d'événement

Une fois un type d'événement créé, l'étape suivante consiste à vérifier sa détectabilité par les projets dépendants. Notez que l'environnement .NET permet aux développeurs de construire des modules de façon faiblement couplée et distribuée, et de les fournir en tant qu'assemblys. Ces assemblys peuvent ensuite être regroupés pour générer une application intégrée, peuvent être testés et peuvent être déployés en production.

N'oubliez pas qu'une requête StreamInsight exécutable est le résultat de la liaison réussie d'un modèle de requête avec les instances des adaptateurs d'entrée et de sortie, selon les types d'événements correspondants, à l'entrée et à la sortie de la requête. Vous devrez peut-être fournir l'accès au type d'événement aux autres utilisateurs, selon l'environnement de développement. Par exemple, le développeur d'adaptateurs et le développeur de requêtes devront peut-être travailler indépendamment sur leurs modules respectifs. Examinez les scénarios suivants pour la détectabilité du type d'événement :

• Si le développeur d'adaptateurs est le serveur de publication du type d'événement, il peut écrire l'adaptateur à l'aide de l'API géré StreamInsight et fournir l'assembly .NET. D'autres développeurs peuvent refléter l'assembly .NET en utilisant ildasm.exe ou en référençant la DLL à partir du projet Visual Studio, et déterminer le type d'événement. Avec cette méthode, l'accès au serveur StreamInsight n'est pas requis pour accéder au type d'événement.

• Si l'administrateur de serveur StreamInsight est le serveur de publication du type d'événement, l'administrateur ou le développeur peut déployer le type d'événement sur le serveur StreamInsight. Un développeur de requêtes qui a accès au serveur StreamInsight peut utiliser ensuite les appels d'API du modèle objet applicables pour inspecter des éléments de métadonnées et déterminer le type d'événement. Le développeur d'adaptateurs peut également écrire un adaptateur typé qui prend en charge ce type d'événement.

• Si le développeur d'adaptateurs et le développeur de requêtes sont déconnectés (chacun utilisant sa propre représentation d'un type d'événement commun), la validation d'une correspondance entre leurs types d'événements respectifs se produira au moment de la liaison de la requête. La liaison sera réussie s'il existe une correspondance.

• Si le développeur de requête n'a aucun accès à l'assembly d'adaptateur ou au serveur StreamInsight dans lequel l'adaptateur est enregistré, il peut déterminer le type d'événement en se référant à la documentation du produit pour l'adaptateur, ou en consultant une base de connaissances commune de protocoles de transfert de données spécifiques au domaine (par exemple, Financial Information Exchange (FIX) ou Reuters Market Data System (RMDS) pour la finance).

Types de données pris en charge

Dans StreamInsight, chaque champ d'événement et chaque expression appartient à un type de données spécifique. StreamInsight prend en charge les types de données suivants. Les charges utiles des événement peuvent également contenir des types imbriqués qui sont composés de ces types de données.

1 N'inclut pas le type Nullable.

Lors du développement de l'adaptateur, les horodateurs d'événement sont spécifiés à l'aide du type DataTimeOffset. Toutefois, seul le type DateTime est pris en charge dans la définition des champs de charge utile du type d'événement. Dans les scénarios dans lesquels vous importez des données de type DateTimeOffset dans un champ d'événement, vous devez convertir les données en DateTime de type UTC. Par exemple, un champ de charge utile peut être rempli à partir d'une base de données SQL Server, ou en copiant les champs d'horodateur de l'événement dans des champs de charge utile pour le calcul.

Voir aussi

Concepts

Création d'adaptateurs d'entrée et de sortie

Concepts du serveur StreamInsight

Exemple StreamInsight de bout en bout