Criando tipos de evento

Este tópico fornece diretrizes para criar tipos de evento. Um tipo de evento define os eventos publicados pela origem do evento ou consumidos pelo coletor de eventos. Na experiência de desenvolvimento, eles são especificados como tipos primitivos únicos, como classes .NET Framework ou structs e definem os dados (carga) que são associados a cada evento no fluxo de eventos. Os tipos de evento são usados nos seguintes estágios de desenvolvimento:

1. Gravando um adaptador com tipo. Um adaptador com tipo usa o tipo de evento como um parâmetro genérico de forma que a estrutura apropriada seja inicializada ao criar novos objetos de evento a serem enfileirados.

2. Gravando um modelo de consulta. Um modelo de consulta é especificado em LINQ sobre um objeto CepStream, cuja definição se baseia em um tipo de evento.

Para obter mais informações sobre eventos e fluxos de eventos, consulte Conceitos do servidor StreamInsight.

Determinar a estrutura do evento

Quando a carga do evento (ou seja, o número de campos na carga e seus tipos) é fixa e conhecida previamente, é possível criar um adaptador com tipo. Com um adaptador com tipo, todas as instâncias do adaptador produzem o mesmo formato de carga fixo. Esse costuma ser o caso para fontes de eventos com uma estrutura de dados fixa.

Ao criar um adaptador tipado, você definirá um struct ou uma classe .NET que representa a carga fixa, ou usará um tipo primitivo caso a carga do evento possa ser representada por um único campo. Ao usar structs ou classes, você pode usar campos e propriedades públicos como campos de carga. Campos e propriedades particulares, além de métodos de classe, são ignorados e não podem ser usados no tipo de evento. Você usa essa declaração de tipo de evento para preencher o tipo de evento no adaptador de entrada e obter o resultado do tipo de evento com tipo no adaptador de saída. O exemplo a seguir define um tipo de evento simples que tem dois campos de carga, V1 e V2, do tipo int.

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

Outro exemplo mostra como usar um tipo evento aninhado:

    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; }
    }

Um adaptador não tipado é útil quando você quer que o mesmo adaptador de uma origem específica ou coletor seja configurável de forma que possa tratar vários tipos de evento. O formato de carga do evento para esses tipos de evento é fornecido ao adaptador como parte de uma especificação de configuração quando o adaptador é associado à consulta. Um exemplo desse cenário é um arquivo .csv que contém vários campos. O conjunto exato de campos que constituem uma carga deve ser determinado pelo designer da consulta (e não pelo desenvolvedor que está compilando o adaptador) apenas no momento da associação e da criação de uma instância da consulta. Outro exemplo é um adaptador para tabelas SQL, em que o tipo dos eventos produzidos depende do esquema da tabela ou da consulta emitida em relação à tabela. Para obter mais informações, consulte Criando adaptadores de entrada e saída.

A especificação de um modelo de consulta se baseia em um objeto CepStream com um tipo de evento específico, que precisa ser conhecido no momento de criação. Objetos intermediários CepStream ao longo da especificação do modelo de consulta podem conter novos tipos que são definidos implicitamente em cláusulas do projeto ("select" em LINQ), usando expressões de membro init.

Requisitos de campo de carga

Ao criar tipos de evento, considere os requisitos de campo de carga e funcionalidade a seguir.

• Uma estrutura de evento não pode ter uma estrutura de carga vazia. É necessário pelo menos um campo.

• Os tipos aninhados e os tipos escalares e elementares do .NET Framework podem ser usados nos campos de carga. Consulte a seção 'Tipos de dados com suporte' a seguir.

• Os campos não podem ser modificados através de atributos personalizados.

• Os tipos de evento no servidor StreamInsight são uma lista ordenada de campos, e não structs .NET, que não impõem uma ordem em seus campos. A ordem dos campos de evento são importantes para os adaptadores não tipados. Esses adaptadores acessam campos por ordinal porque os campos não são conhecidos no tempo de design do adaptador. Como uma convenção padrão, uma estrutura .NET, usada como um tipo de evento, ordena seus campos de acordo com a ordem lexicográfica de seus nomes. 

• A nulidade do campo é inferida. Por exemplo, int? permitirá valor nulo, mas int não permitirá. Os tipos String e byte[] sempre permitem valor nulo.

• O tamanho padrão de byte[] é 512.

• O comprimento máximo de campos de cadeia de caracteres é associado apenas pelo tamanho de página de todo o evento, que é de 16 kbytes.

Tamanho do evento

Não há limitações explícitas quanto ao número de campos a serem definidos no tipo de evento. O número de campos depende do tipo de cada campo, do seu tamanho e de sua possibilidade de nulidade.

O tamanho da página do evento no servidor StreamInsight é 16K. Como um evento não pode ocupar várias páginas, 16K menos alguma sobrecarga é o tamanho de evento máximo eficaz (incluindo os campos de carga e de carimbo de data/hora). Além da sobrecarga fixa incorrida pelo cabeçalho da página, pelo cabeçalho do evento e por campos do sistema como o carimbo de data/hora, a nulidade é adicionada à sobrecarga variável na ordem de N/8 ajustados para um limite superior.

Para maximizar a utilização da página de evento, recomendamos as seguintes diretrizes:

• Evite campos anuláveis.

• Minimize o uso de campos string e byte[].

• Mantenha os tempos de vida de eventos apenas enquanto necessários para a semântica do respectivo cenário, para que a memória necessária para o estado do evento possa ser liberada de forma mais eficiente no mecanismo

Capacidade de descoberta de tipos de evento

Depois da criação de um tipo de evento, a próxima etapa será garantir sua capacidade de descoberta pelos projetos dependentes. Observe que o ambiente de .NET proporciona aos desenvolvedores a capacidade compilar módulos de uma maneira acoplada, distribuída, enviando-os como assemblies. Esses assemblies podem ser aglutinados para compilar um aplicativo integrado, que é testado e implantado para produção.

Lembre-se de que uma consulta executável do StreamInsight é o resultado da associação com êxito de um modelo de consulta com instâncias dos adaptadores de entrada e de saída, com base em tipos de evento correspondentes à entrada e saída da consulta. Dependendo do ambiente de desenvolvimento, talvez seja necessário permitir o acesso de outras pessoas ao tipo de evento. Por exemplo, o desenvolvedor do adaptador e o desenvolvedor da consulta talvez precisem trabalhar em seus respectivos módulos de maneira independente. Considere os seguintes cenários para capacidade de descoberta de tipo de evento:

• Se o desenvolvedor do adaptador for o publicador do tipo de evento, o desenvolvedor do adaptador poderá gravar o adaptador usando a API gerenciada do StreamInsight e enviar o assembly .NET. Outros desenvolvedores podem refletir sobre o assembly .NET usando ildasm.exe ou referenciando a DLL dentro do projeto Visual Studio, e determinar o tipo de evento. Usando esse método, o acesso ao servidor StreamInsight não é obrigatório para acessar o tipo de evento.

• Se o administrador do servidor StreamInsight for o publicador do tipo de evento, o administrador ou o desenvolvedor poderá implantar o tipo de evento no servidor StreamInsight. Assim, um desenvolvedor da consulta com acesso ao servidor StreamInsight pode usar as chamadas de API do modelo de objeto aplicável para inspecionar itens de metadados e determinar o tipo de evento. O desenvolvedor do adaptador também pode escrever um adaptador tipado que dê suporte a esse tipo de evento.

• Se o desenvolvedor do adaptador e o desenvolvedor da consulta estiverem efetivamente desconectados - (cada um trabalhando com sua própria representação de um tipo de evento em comum), a validação de uma correspondência entre seus respectivos tipos de evento ocorrerá no momento da associação da consulta. A associação terá êxito se houver uma correspondência.

• Se o desenvolvedor de consultas não tiver acesso ao assembly de adaptador ou ao servidor StreamInsight no qual o adaptador está registrado, o desenvolvedor poderá determinar o tipo de evento referenciando a literatura do produto para o adaptador, ou através de conhecimento comum de protocolos de transferência de dados específicos desse domínio (por exemplo, FIX (Financial Information Exchange) ou RMDS (Reuters Market Data System) em comércio financeiro).

Tipos de dados com suporte

No StreamInsight, cada campo de evento e expressão tem um tipo de dados específico. O StreamInsight oferece suporte aos tipos de dados a seguir. As cargas de evento também podem conter tipos aninhados, que são compostos por esses tipos de dados.

1 não inclui o tipo anulável.

Durante o desenvolvimento do adaptador, carimbos de data/hora de evento são especificados usando o tipo DataTimeOffset. Contudo, apenas o tipo DateTime tem suporte na definição dos campos de carga de tipo de evento. Em cenários nos quais você importa dados de tipo DateTimeOffset para um campo de evento, converta os dados em DateTime de tipo UTC. Por exemplo, um campo de carga pode ser preenchido a partir de um banco de dados do SQL Server, ou copiando os campos de carimbo de data/hora de evento em campos de carga para computação.

Consulte também

Conceitos

Criando adaptadores de entrada e saída

Conceitos do servidor StreamInsight

Exemplo ponta a ponta do StreamInsight