Introdução ao conector independente

O conector independente processa a comunicação entre o sistema de origem e o SAP Signavio Process Intelligence. Este conector pode ser usado se o sistema de origem não for coberto por um dos conectores padrão no SAP Signavio Process Intelligence (ou qualquer outro sistema de terceiros). Ele extrai dados do sistema de origem, transforma os mesmos no formato de log de eventos e, em seguida, é carregado para o Process Intelligence para ser analisado. 

No entanto, os scripts ETL precisam ser executados externamente (fora do SAP Signavio Process Intelligence), mas usam a API para enviar os dados para um processo dentro do sistema.

O conector consiste em vários componentes trabalhando em conjunto para conseguir isso. Isso inclui:

• Uma coleção de scripts SQL de extração e transformação
• Um arquivo de configuração no formato YAML
• Um banco de dados SQLite para garantir que os dados corretos sejam carregados sempre no caso de carregamentos regulares
• Uma aplicação Java para acionar a extração, transformação e carregamento reais

A lição a seguir descreverá como esses componentes funcionam em conjunto e podem ser implementados para servir o Process Intelligence com os dados necessários.

Vamos continuar a aprender mais sobre a funcionalidade em um exemplo da SAP.

O conector utiliza um usuário (de serviço) técnico da SAP para chamar dados do sistema fonte e armazená-los em um bucket S3.

O conector usa o Athena para gerar um arquivo de log de eventos a partir dos dados transformados do S3 e baixa esse arquivo.

O conector carrega o arquivo de log de eventos para a API do Process Intelligence.

Para que um ETL automatizado funcione, primeiro precisamos configurar um ambiente para que o conector seja executado no. Para isso, precisamos configurar a máquina virtual.

Selecione cada etapa abaixo para saber mais sobre a configuração.

Dependendo se a transformação de dados pode ser executada no sistema fonte, você pode ter que configurar um ambiente de staging dedicado. Na maioria dos casos, isso é muito mais rápido e mais adequado para mineração de processos. Isso também permite que você use vários sistemas fonte. 

No caso da AWS, é necessária uma conta com o S3 para armazenamento de dados e Athena para executar os scripts de transformação.

Assim que a configuração do ambiente estiver concluída, o conector precisa ser configurado para se adequar ao caso de utilização específico. Isso é feito no arquivo config.yaml fornecido pela SAP. Ele define as ações exigidas pelo conector e as configurações de conexão, extrações de tabela e configurações de coletor de eventos.  

Na lição, abordaremos esses parâmetros e forneceremos um exemplo simplificado no qual extrairemos dados de exemplo de um sistema da SAP e faremos a preparação para uma análise do processamento de ordens.

Primeiro, vejamos cada etapa para começar a configurar nosso conector. 

Agora que nossa conexão é estabelecida, a próxima etapa é definir a extração e os dados necessários. Vejamos os parâmetros necessários para carregamentos delta. Isso pode ser efetuado na tabela SyncConfigurations. Começamos com os parâmetros gerais para cada tabela que deve ser extraída. Saiba mais sobre cada etapa para configurar os parâmetros gerais de nossas tabelas. 

Agora que temos nosso sistema de origem e informações de extração, a próxima etapa é a transformação de nossos dados de origem no formato de log de eventos. Para isso, precisamos de 3 colunas (ID do caso, nome do evento, registro da hora) em eventCollectorConfigurations. Saiba mais sobre cada etapa em nossa Configuração de transformação. 

O conector pode ser iniciado como um aplicativo Java executando as informações abaixo no terminal. Primeiro, vá para o diretório de origem do conector e, em seguida, execute para começar.

java -jar signavio-connector.jar <command>

Comandos: 

• Com base na tabela SyncConfiguration:
  • extrai => os dados brutos da tabela do sistema fonte usando os scripts de extração definidos e os carrega para a área de staging onde serão gravados como tabelas brutas. Os nomes de tabela na área de staging serão dependentes dos fornecidos na tabela SyncConfiguration.
  • createschema => gera o esquema para as tabelas brutas 
  • transforma => otimiza o esquema de tabela bruta e consolida atualizações de linha caso existam alterações em linhas sobrepostas entre diferentes carregamentos delta. As atualizações nos dados já extraídos em um carregamento anterior serão reconhecidas com base nos parâmetros keyColumn e mostRecentRowColumn.
• Com base em eventCollectorConfiguration:
  • eventlog => cria o logoff do evento do sistema de staging com base nos scripts de transformação e o carrega no Process Intelligence.