- Notas de versão
- Antes de começar
- Gerenciamento de acesso
- Introdução
- Integrações
- Como trabalhar com aplicativos de processo
- Como trabalhar com painéis e gráficos
- Como trabalhar com gráficos de processo
- Trabalhando com Descubra modelos de processo e Importar modelos BPMN
- Showing or hiding the menu
- Informações de contexto
- Exportar
- Filtros
- Envio de ideias de automação ao UiPath® Automation Hub
- Tags
- Datas de conclusão
- Comparar
- Verificação de conformidade
- Simulação de processos
- Análise de causa raiz
- Simulação de Potencial de Automação
- Iniciar um projeto do Task Mining a partir do Process Mining
- Triggering an automation from a process app
- Exibição de dados do processo
- Criação de aplicativos
- Carregamento de dados
- Transforming data
- Structure of transformations
- Tips for writing SQL
- Exportando e importando transformações
- Visualização dos logs de execução de dados
- Mesclando logs de evento
- Configuração de tags
- Configuração de datas de vencimento
- Configuração de campos para Potencial de automação
- Configuração da atividade: definição da ordem das atividades
- Disponibilização das transformações em painéis
- Modelos de dados
- Adicionar e editar processos
- Personalização de aplicativos de processo
- Publicação de aplicativos de processos
- Modelos de apps
- Notificações
- Recursos adicionais
Process Mining
Structure of transformations
models\ na seção Transformações de Transformações de dados é organizada de acordo com a estrutura das etapas de transformação.
Os modelos de aplicativos Log de evento e Processo personalizado têm uma estrutura de transformações de dados simplificada. Os aplicativos de processo criados com esses modelos de aplicativos não têm essa estrutura de pastas.
Na etapa Objetos, as tabelas de entrada são transformadas em tabelas de objetos. Cada objeto necessário para os eventos esperados deve ter sua própria tabela. Consulte Criação de um log de evento. Além disso, o objeto de suporte também pode ser definido aqui.
Invoices_input, Invoice_types_input e Customers_input são unidas para criar a tabela de objeto Faturas.
Siga estas diretrizes ao criar uma tabela de objetos.
- Há um campo de ID do objeto, que é exclusivo para cada registro de dados.
- Todos os campos do objeto necessários para a análise de dados estão presentes.
- Todos os campos do objeto têm nomes que são fáceis de entender.
Invoice_ID .
Nem todas as tabelas de entrada são transformadas em tabelas de objeto. Além disso, outras tabelas de entrada podem conter informações relevantes, como a tabela Customers, no exemplo. Pode ser conveniente defini-los na etapa Objetos como tabelas separadas, para que eles possam ser reutilizados nas transformações de dados.
Nesta etapa de transformação, as tabelas de eventos são criadas para cada objeto. Confira Criando um log de evento. Cada registro em uma tabela de evento representa um evento que ocorreu. Há dois cenários sobre como os dados são estruturados:
- Campos de carimbo de data/hora: campos em uma tabela de objeto com um carimbo de data/hora de um evento. Por exemplo, o campo
Invoice_createdem uma tabelaInvoices. - Log de transações: uma lista de eventos.
Com base em como os dados são estruturados, as transformações para criar as tabelas de eventos são diferentes.
Nesse cenário, os valores de um campo de carimbo de data/hora devem ser transformados em registros separados em uma tabela de eventos. O exemplo a seguir é uma tabela de faturas que contém três campos de carimbo de data/hora.
Cada campo de carimbo de data/hora é usado para criar uma tabela de eventos separada. Para cada registro que o campo carimbo de data/hora contém um valor, crie uma tabela com o ID da Nota Fiscal, o nome do evento (Atividade) e o carimbo de data/hora em que o evento ocorreu (Fim do evento).
Invoices_input table é dividido em Invoice_events_Create_invoice, Invoice_events_Delete_invoicee Invoices_events_Change_invoice_price.
Invoices_events.
Se os eventos forem armazenados em um log de transações, os eventos relevantes por objeto devem ser identificados. Crie uma tabela por objeto e armazene o ID do objeto correspondente, o nome do evento (Atividade) e o carimbo de data/hora em que o evento ocorreu (Fim do evento).
Os seguintes campos são obrigatórios em uma tabela de eventos. Todos os registros nas tabelas de eventos devem conter um valor para esses campos.
|
Campo |
Description |
|---|---|
|
ID do Objeto |
ID do objeto para o qual o evento acontece. Por exemplo, o ID da fatura. |
|
Atividade |
A atividade descreve qual ação ocorreu no objeto. |
|
Event end |
O campo de término do evento indica quando o evento específico foi concluído. Idealmente, este deve ser um campo de data e hora, em vez de uma data. |
[Activity] + _events para criar um arquivo de evento por atividade ou [Object] + _events para criar um arquivo de evento por objeto. Por exemplo, Purchase_order_created_events, Purchase_order_approved_events ou um arquivo com todas as atividades de ordem de compra combinadas Purchase_order_events.
Na última etapa de transformação, a lógica de negócios é adicionada conforme necessário para a análise de dados. Campos derivados adicionais podem ser adicionados a tabelas existentes aqui. Por exemplo, tempos de rendimento específicos ou campos booleanos usados em KPIs em painéis.
Tags e Due dates.
As tags são propriedades de objetos, que significam certas regras de negócios. As tags normalmente são adicionadas para facilitar a análise dessas regras de negócios. Por exemplo:
- Fatura paga e aprovada pela mesma pessoa.
- A aprovação da fatura demorou mais de 10 dias.
- Verifique a atividade da fatura ignorada.
Object ID e o Tag. Nem todos os objetos terão uma tag e alguns objetos podem ter várias tags. A ilustração a seguir mostra um exemplo de uma tabela de Tags.
Semelhante aos Eventos, várias tabelas de Tags podem estar presentes no modelo de dados.
Convenção de nomenclatura
[Tag] + _tags para criar um arquivo por tag ou [Object] + _tags para criar um arquivo por objeto. Por exemplo, Invoice_approved_and_paid_by_same_person_tags, Invoice_approval_too_late_tags ou um arquivo com todas as tags de fatura combinadas Invoice_tags.
As datas de vencimento representam prazos no processo. Estes são adicionados aos dados para analisar se as atividades são executadas a tempo para essas datas de vencimento ou não.
Cada registro na tabela de datas de conclusão representa uma data de conclusão para um determinado objeto. Alguns exemplos de datas de conclusão são:
- um prazo de pagamento para um pagamento.
- um prazo de aprovação para uma ordem de compra.
Object ID, Due date, Actual datee Expected date.
Semelhante a Eventos, várias tabelas de Datas de vencimento podem estar presentes no modelo de dados.
Convenções de Nomes
[Due date] + _due_dates para criar um arquivo por data de vencimento ou [Object] + _due_dates para criar um arquivo por objeto. Por exemplo, Payment_deadline_due_dates, Payment_deadline_with_discount_due_dates ou um arquivo com todas as datas de faturas combinadas Payment_due_dates.
