Manipulando Exceções

O Sterling Search Index possui alguns recursos integrados de tratamento de exceções.

Como o Order Service é implantado fora do sistem Sterling™ Order Management, é possível que surjam problemas com o tempo. Por exemplo, o Serviço de Pedidos pode estar fora do ar ou inacessível. Podem ocorrer erros de validação na pesquisa de pedidos ou problemas específicos do ` Elasticsearch `, como a indisponibilidade de alguns fragmentos do índice ou o fato de o nó “master” ainda não ter sido eleito. Isso pode resultar na falha das operações de indexação.

Isso levanta as seguintes considerações:

Como o Search Index Server é utilizado principalmente para agilizar as pesquisas e melhorar a visibilidade dos dados, sua indisponibilidade ou falhas no indexamento não devem causar nenhum impacto funcional. Por esse motivo, o Sterling Search Index foi projetado para ser suficientemente robusto a fim de contornar esses problemas e oferecer uma funcionalidade empresarial sem interrupções.
As atualizações de índice com falha ou perdidas precisam ser rastreadas e repetidas.
As atualizações de índice com falha devem ser comunicadas a você para que possa tomar medidas corretivas, se necessário.

Tratamento de atualizações de índice com falha ou perdidas

Conforme explicado resumidamente na seção anterior, YFS_Awaiting_Index o sistema armazena uma referência a cada tentativa de indexação, o que dá origem aos seguintes cenários:

JVM falha - Como a operação de atualização do índice é realizada de forma assíncrona por meio do PeriodicBatchIndexer serviço, se o ` JVM ` falhar ou for encerrado à força, algumas das atualizações serão perdidas.
Falhas intermitentes na indexação - A operação de indexação falha intermitentemente devido a problemas com o Servidor de Índice de Pesquisa, a rede e assim por diante.
Falhas recorrentes na indexação: devido a alguns problemas, a operação de indexação falha continuamente e de forma reproduzível.

Nos cenários 2 ou 3, você é notificado sobre a exceção. Dependendo do problema, talvez seja necessário tomar uma medida corretiva para resolvê-lo. Em qualquer um desses casos, os registros na tabela YFS_Awaiting_Index identificam o registro da entidade que precisa ser reindexado. A reindexação é realizada pelo agente SSI_DELAYED_SYNC , que é acionado automaticamente de forma periódica.

notificação de exceção

Qualquer exceção que ocorra durante uma operação de indexação deve ser notificada a você. Além dos cenários excepcionais já discutidos, o Sterling Search Index também possui outros mecanismos preventivos. Por exemplo, em caso de falhas contínuas no índice, ele desativa completamente a operação correspondente até que você tome medidas corretivas. Além disso, se alguma alteração tiver sido feita no modelo de estrutura do índice, o índice no Search Index Server poderá estar em um estado inconsistente, com dados antigos que não possuem os atributos agora adicionados ao modelo de estrutura. Essas decisões tomadas automaticamente pelo Sterling Search Index podem exigir que você tome medidas corretivas. No primeiro exemplo, é necessário resolver o problema subjacente e reativar a operação de indexação. No segundo caso, é preciso avaliar se o SSI_MASS_SYNC agente precisa ser executado. Se necessário, marque o índice para que fique em um estado sincronizado. Portanto, essas mensagens também precisam ser notificadas.

Essas exceções ou avisos podem ser classificados, em linhas gerais, da seguinte forma:

Mensagens de status do índice
Índice de avisos operacionais
Erros inesperados
problemas de conectividade

Observação: Algumas das exceções, principalmente aquelas que ocorrem durante o processo de criação do índice, são registradas sob o nome de ou IndexManager PeriodicBatchIndexer. Isso ocorre porque as operações de indexação não são realizadas pelo usuário que criou ou modificou o pedido no sistema, mas são acionadas a partir de classes Java com IndexManager o nome ou PeriodicBatchIndexer em uma thread separada no JVM

As exceções e avisos do Índice de Pesquisa Sterling são publicados de uma das seguintes formas:

Ao emitir um alerta
Ao criar um evento

emitindo alertas

Os alertas gerados pelo Sterling Search Index são semelhantes a quaisquer outros alertas gerados para exceções operacionais. Todas as exceções são registradas com ` ExceptionType=’IndexException’ ` e os avisos são registrados com ` ExceptionType=’Warning_Message’ `. Eles são criados na tabela YFS_Inbox no mesmo fragmento de banco de dados que o registro da entidade correspondente. Esses alertas não são direcionados a nenhum usuário nem a nenhuma fila de alertas, e não são consolidados.

Você pode listar os alertas na Consola de Alertas especificando o Tipo de Alerta como “ IndexException ” ou “Warning_Message”. Esses alertas podem não ser específicos da empresa; portanto, é melhor evitar o uso de “ ‘EnterpriseCode’ ” como critério de pesquisa.

Organização de eventos

As exceções operacionais e as transições de status do Sterling Search Index podem ser publicadas ativando-se o evento ON_FAILURE definido para a transação SSI_INDEX_NOTIFICATION, presente no Repositório de Tipos de Processo Gerais.

Se você ativar este evento, ele poderá publicar as informações conforme mostrado no modelo a seguir:

Index IndexName="" EnterpriseCode="" SearchWorking="" IndexWorking="" ErrorCode="" ErrorDescription="" Reason="" Comments="" ReferenceName="" ReferenceValue="" SearchCriteria=""> <StackTrace/> </Index>

Isso é configurável. O modelo de evento " SSI_INDEX_NOTIFICATION.ON_FAILURE.xml " está presente no<NSTALL_DIR>/repository/xapi/template/merged/event diretório.

Sterling Order Management O sistema não oferece nenhum manipulador de eventos, como condições, ações ou serviços, para acionar um processo quando esse evento é gerado. No entanto, ele oferece os seguintes atributos do criador de condições, que ajudam a criar uma condição para os dados publicados pelo evento.

Atributos do Construtor de Condição	Use este atributo para criar uma condição
EnterpriseCode	Para um artigo específico: EnterpriseCode
IndexName	Para um artigo específico: IndexName
IsIndexingWorking	Para acompanhar a transição do atributo ` IndexWorking `

Para personalizar os atributos do construtor de condições para outros atributos publicados pelo evento, utilize o recurso " {Enter Your Own Attribute} ".

Você pode definir ações para publicar os resultados do evento em um banco de dados, criar um alerta, enviar um e-mail e assim por diante. Você pode definir manipuladores de eventos definindo condições que determinam os tipos de ações a serem executadas quando esse evento for disparado.

A tabela a seguir descreve os atributos publicados para as exceções do Índice de Pesquisa Sterling:

Atributos	Descrição
IndexName	O nome do índice, por exemplo, Order.
EnterpriseCode	O valor `EnterpriseCode` publicado, se disponível no momento em que ocorreu uma exceção.
IndexWorking	Definir este valor como N indica que `IndexWorking` o sistema altera o valor para N e não é realizada nenhuma indexação adicional no índice.
ErrorCode	O código de erro correspondente ao erro. Você pode ver a descrição e a causa desses erros, bem como as ações necessárias para resolvê-los no sistema d Sterling Order Management.
ErrorDescription	A descrição do código de erro.
Motivo	Se for exibido um erro do Servidor de Índice de Pesquisa, este campo fornece informações detalhadas sobre a falha. Em caso de notificação, este campo exibe a mensagem de notificação.
Comentários	Fornece informações adicionais sobre o cenário, seja ele um cenário de exceção ou um cenário de notificação.
ReferenceName	Fornece informações adicionais. Normalmente, contém o nome da entidade de referência. Por exemplo, `YFS_ORDER_HEADER` ou `YFS_AWAITING_INDEX`.
ReferenceValue	Fornece informações adicionais. Normalmente, contém o valor da referência entityKey. Por exemplo, o valor de `OrderHeaderKey` ou `AwaitingIndexKey`. Isso indica que ocorreu uma exceção durante o processamento da chave correspondente.
StackTrace	O rastreamento completo da pilha da exceção. Isso não está presente no modelo fornecido pelo aplicativo para o `ON_FAILURE` evento. Você pode ampliar o modelo para incluir o rastreamento da pilha na saída do evento.