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 Events filter.

Veja o exemplo abaixo.

Filtro de casos

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

Filtro de eventos

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 ocorrem antes de 01/01/2016 são removidos. O painel Resultado 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 Casos em sua condição onde. 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 15 registros são excluídos, o que corresponde aos 15 valores falsos no 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 haja campos definidos no AppOne, que não correspondam diretamente a um dos campos em seu arquivo de dados de entrada. Nesse caso, você deve criar uma expressão para esse 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 um atributo desse tipo no UiPath Process Mining, é necessário primeiro fazer uma expressão que calcule os valores corretos e, em seguida, 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:

Recomenda-se dar à nova expressão o mesmo nome do atributo original.

Consulte a ilustração abaixo para obter um exemplo de como remover o prefixo CREA_ 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 seguir essas etapas na tabela de onde o atributo incorreto e a nova expressão se originam.

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 de caso e selecione Disponibilidade - Pública no menu de contexto para alterar a disponibilidade para Pública.

Etapa 2: trocar UIDs

Para substituir o atributo incorreto em todos os lugares 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 os 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 (ver exemplo abaixo). O atributo incorreto só deve ser referenciado pela nossa 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 tiver sido bem-sucedida e as referências apontarem para os atributos corretos, é recomendável definir a disponibilidade do atributo original como Privado. Dessa forma, ele não pode ser usado em outras tabelas, como as tabelas Preprocessing e Base . Veja a ilustração abaixo para os dois atributos de ID do caso após a troca e o atributo original definido como privado.