Limpando dados de entrada

Limpando dados de entrada

Quando os dados são carregados no Conector Básico, é possível que o conjunto de dados contenha casos e eventos incorretos ou irrelevantes. O Conector Básico contém dois filtros que podem ser usados para remover esses casos e eventos, o Cases filter e o Events filter.

Veja o exemplo abaixo.

Filtro de casos

O filtro Casos se aplica a todos os casos na tabela Cases_input e geralmente é usado para remover casos duplicados ou deixar de fora determinados tipos de caso. No exemplo abaixo são filtrados os casos com valor negativo. O painel de resultados mostra que 15 casos serão filtrados com base nessa definição.

Filtro de eventos

O filtro Eventos se aplica a todos os eventos na tabela Events_input e geralmente é usado para deixar de fora certas atividades ou para filtrar eventos antes de uma data específica. O filtro Eventos sempre faz referência ao filtro Casos para remover eventos em que o caso foi filtrado no filtro Casos. No exemplo abaixo, os eventos ocorridos antes de 01/01/2016 são removidos. O painel de resultados mostra que isso resulta na remoção de 72.191 eventos.

Aplicando o filtro

Por padrão, Cases filter e Events filter são aplicados na junção das tabelas Cases_preprocessing e Events_preprocessing . Por isso basta alterar apenas os próprios filtros. A configuração garante que as tabelas de pré-processamento contenham apenas dados de acordo com a definição do filtro.

Clique duas vezes na tabela Cases_preprocessing ou Events_preprocessing para inspecionar como o filtro é aplicado.

Cases_preprocessing

A junção da tabela Cases_preprocessing aplica o filtro Cases em sua condição where. Como resultado, a tabela contém todos os dados contidos na tabela Cases_input , exceto os registros filtrados pelo filtro Casos. O exemplo abaixo mostra que foram excluídos 15 registros, que correspondem aos 15 valores falsos do próprio filtro Casos .

Events_preprocessing

O Filtro de eventos aplica-se a todos os eventos na tabela Events_input e, frequentemente, é usado para deixar de fora certas atividades ou para filtrar eventos antes de uma data específica. O Filtro de eventos sempre faz referência ao Filtro de casos para remover eventos nos quais o caso foi filtrado no Filtro de casos. No exemplo abaixo, eventos que ocorreram antes de 01/01/2016 são removidos. O painel Resultado mostra que isso resulta na remoção de 72 191 eventos.

Substituindo atributos

Em vez de ter atributos em seu conjunto de dados que não existem no Conector Básico, também é possível que existam campos definidos no AppOne, que não correspondem diretamente a um dos campos em seu arquivo de dados de entrada. Neste caso, você deve criar uma expressão para este campo no Conector Básico.

Em alguns casos, você pode não querer remover o registro inteiro, mas simplesmente corrigir os valores do atributo incorreto.

Para corrigir tal atributo no UiPath Process Mining, é necessário primeiro fazer uma expressão que calcule os valores corretos e depois substituir o atributo incorreto pela nova expressão.

Corrigindo o valor do atributo

Para corrigir o atributo, crie uma nova expressão que calcule os valores corretos. Crie esta expressão na mesma tabela em que o atributo incorreto se origina.

Por exemplo, o atributo Case ID está disponível nas tabelas Cases_preprocessing e Cases_base , mas se origina em Cases_input. Portanto, a nova expressão para corrigi-la também deve ser calculada em Cases_input.

Observação: é recomendável dar à nova expressão o mesmo nome do atributo original.

Consulte a ilustração abaixo para obter um exemplo de como remover o prefixo CORE_ de Case ID na tabela Cases_input .

Substituindo o atributo

Os atributos das tabelas no Conector Básico são usados em diferentes expressões em todo o conector. Portanto, não é possível simplesmente excluir o atributo incorreto, mas ele precisa ser substituído pela nova expressão. As etapas abaixo explicam como substituir um atributo.

Observação: é importante realizar essas etapas na tabela de origem do atributo incorreto e da nova expressão.

Etapa 1: definir a disponibilidade da nova expressão

Para substituir um atributo, a disponibilidade de ambos os atributos precisa ser a mesma. Os dois atributos de ID do caso na figura abaixo têm disponibilidades diferentes.

Clique com o botão direito do mouse na segunda expressão de ID do caso e selecione Disponibilidade - Público no menu de contexto para alterar a disponibilidade para Público.

Etapa 2: trocar UIDs

Para substituir o atributo incorreto em todos os locais onde ele é usado no Conector pela nova expressão, os UIDs de ambos os atributos precisam ser trocados. Ao trocar os UIDs, o software substitui todas as referências ao atributo original por referências à nova expressão e vice-versa. Para trocar UIDs, selecione ambos os atributos, clique com o botão direito do mouse e selecione Avançado - Trocar UIDs no menu de contexto. Veja a ilustração abaixo.

Observação:

• O UID é um ID de software interno e não o ID mostrado no editor de expressão. Depois de trocar os UIDs, o nome e o ID do atributo ou expressão não serão alterados.
• Caso a troca dos UIDs não seja feita na tabela de origem do atributo original e da nova expressão, um aviso é exibido e a troca não é executada na tabela original. Você pode desfazer as alterações usando CTRL + Z e substituir o atributo na tabela correta.

Etapa 3: verifique as referências

Para verificar se a troca foi bem-sucedida, verifique as referências de cada um dos atributos. Todas as referências que costumavam apontar para o atributo original agora devem apontar para a nova expressão (veja o exemplo abaixo). O atributo incorreto só deve ser referenciado por nossa própria nova expressão. Para verificar as referências, selecione um atributo, clique com o botão direito do mouse e selecione Avançado - Mostrar referências no menu de contexto.

fantasmas

Um fantasma é um atributo que ficou indisponível, embora ainda esteja sendo usado no conector. Um aviso é exibido quando um fantasma é criado. Um fantasma é indicado pelo ícone. Nunca exclua um fantasma que ainda tenha referências apontando para ele. Desfaça as alterações usando CTRL+Z até que o fantasma seja substituído pelo atributo real. Avalie quais etapas deram errado durante a substituição do atributo e repita se necessário.

Etapa 4: definir a disponibilidade do atributo original

Se a troca foi bem-sucedida e as referências apontam para os atributos corretos, é recomendável definir a disponibilidade do atributo original como Private. Desta forma, não pode ser utilizado em outras tabelas como as tabelas Preprocessing e Base . Consulte a ilustração abaixo para os dois atributos de ID do caso após a troca e o atributo original definido como privado.