Processos em Andamento ou Por Hora

O diagrama a seguir mostra as dependências entre os processos em batch em andamento ou por hora.

Ao longo do dia, você provavelmente executará trabalhos para trazer dados de medição e evento de vários sistemas de medição ou head-end e outros sistemas externos. Para acompanhar isso, você deve considerar a execução do Processamento de Sincronização de Dados Mestre em Andamento, Processamento de Comando e Processamento de Medição Inicial.

Os mnemônicos nas caixas se referem aos processos batch individuais descritos anteriormente. Quando uma caixa contém vários processos, eles devem ser executados em sequência.

Observação:

Sem dependências. Como você pode ver, não há dependências entre as caixas (o que significa que elas podem ser executadas paralelamente).

Ao longo do dia, você provavelmente vai querer executar trabalhos para trazer dados de medição e evento de vários sistemas de medição/head-end e outros sistemas externos. Para acompanhar isso, você deve considerar a execução dos seguintes processos em batch:

  • Processamento de Sincronização de Dados Mestre em Andamento

    Com a implantação do Oracle Utilities Customer to Meter, a sincronização de dados é usada para manter determinados objetos sincronizados. Consulte a seção de Integração C2Mpara obter mais detalhes. A limpeza dos registros de tabela intermediária de sincronização com erro durante a execução de D1-SIOER pode ser necessária.

  • Processamento de Comando

    Se estiver usando o Oracle Utilities Smart Grid Gateway para processar comandos de dispositivo, é importante manter as comunicações que fluem de e para medidores inteligentes para fornecer a imagem mais precisa do estado de um determinado medidor. Isso incluiria:

    • Repetindo comunicações de entrada com erro (D1-ICERR)

    • Repetindo comunicações de saída com erro (D1-OCERR)

    • Processando comunicações de saída aguardando uma resposta (D1-OCWT) para ver se elas devem expirar.

    • Processando atividades de solicitação de comando com erro (D1-CRERR) e aquelas que estão aguardando (D1-CRWT)

    Observação: os objetos de negócios do pacote base para atividades de comunicação e comando são projetados para interceptar quaisquer erros de processamento encontrados e fazer a transição do objeto para um estado de Erro. Para lidar com erros inesperados que não podem ser capturados, o que pode deixar atividades de comunicação/comando em estados não monitorados, as implementações podem optar por configurar seus próprios controles batch com base nos controles batch D1-ACTVY e D1-COMM fornecidos, restringindo registros processados pelo objeto de negócios ou objeto de manutenção, conforme necessário

  • Processamento de Medição Inicial

    Para o processamento de medição inicial, os seguintes processos em batch devem ser programados continuamente de acordo com os requisitos de negócios:

    • Processamento de medições iniciais no estado pendente (D1-IMD).

    • Processando os pré-implantadores de medidas iniciais com erro (D1-IMDSD).

    • Processamento de medições iniciais no estado de exceção (D1-GNIMD).

    Esses processos também são destacados no fluxo de Processos Noturnos para refletir a necessidade de trazer o máximo possível de dados de medição antes da execução do faturamento, tanto dados atualizados de medidores de relatórios atrasados quanto leituras corrigidas do sistema head-end.

  • Processamento de Evento

    O pacote base é configurado de forma que os eventos do dispositivo sejam processados imediatamente após o recebimento, uma vez que podem precisar ser enviados a algum outro aplicativo, como um sistema de indisponibilidade de serviço. Isso pode ser alterado configurando um processo de monitor no objeto de negócios de evento do dispositivo para interromper registros em um estado especificado e, em seguida, usar um processo em batch para processar os eventos de uma só vez. Além desse tipo de processamento orientado a batch para eventos, outro processamento de evento pode incluir:

    • Reprocessando evento de dispositivo "seeders" com erro (D1-DVEVS)

    • Processando todos os eventos do dispositivo que podem vir como pares (D1-DEVPR)

    • Retirar eventos do dispositivo para processamento se eles tiverem parado em qualquer estado (D1-DVEVT)

    Se os eventos do dispositivo estiverem configurados para serem impedidos de serem enviados para aplicativos downstream, como impedir que eventos de indisponibilidade de serviço "flicker" (um evento de indisponibilidade de serviço e um evento de restauração recebido em sucessão rápida) sejam enviados, o monitoramento de eventos do dispositivo (D1-DEVPR e D1-DVEVT) deverá ser configurado para ser executado periodicamente a fim de garantir a transmissão oportuna dos eventos.