Como você sabe, a SAP oferece uma gama completa de software tanto para manter dados transacionais quanto para processar esses dados em sistemas de análise e relatórios. Em particular, a plataforma SAP Business Warehouse (SAP BW) é um kit de ferramentas para armazenar e analisar dados com amplos recursos técnicos. Apesar de todas as suas vantagens objetivas, o sistema SAP BW tem uma desvantagem significativa. Este é um alto custo de armazenamento e processamento de dados, especialmente perceptível ao usar SAP BW baseado em nuvem no Hana.
E se você começar a usar algum produto não SAP e de preferência um produto OpenSource como armazenamento? Nós do X5 Retail Group escolhemos o GreenPlum. Isso, é claro, resolve a questão do custo, mas, ao mesmo tempo, surgem imediatamente problemas que foram resolvidos quase por padrão ao usar o SAP BW.
Em particular, como recuperar dados de sistemas de origem, que são principalmente soluções SAP?
HR Metrics foi o primeiro projeto em que foi necessário resolver este problema. Nosso objetivo era criar um repositório de dados de RH e construir relatórios analíticos na área de trabalho com colaboradores. Neste caso, a principal fonte de dados é o sistema transacional SAP HCM, no qual são realizadas todas as atividades pessoais, organizacionais e salariais.
Extração de dados
No SAP BW existem extratores de dados padrão para sistemas SAP. Esses extratores podem coletar automaticamente os dados necessários, monitorar sua integridade e determinar deltas de alterações. Aqui, por exemplo, está a fonte de dados padrão para atributos de funcionários 0EMPLOYEE_ATTR:
O resultado da extração de dados para um funcionário:
Se necessário, esse extrator pode ser modificado para atender às suas próprias necessidades ou pode ser criado seu próprio extrator.
A primeira ideia que surgiu foi a possibilidade de reaproveitá-los. Infelizmente, isso acabou sendo uma tarefa impossível. A maior parte da lógica é implementada no lado do SAP BW e não foi possível separar sem problemas o extrator na origem do SAP BW.
Tornou-se óbvio que precisaríamos desenvolver nosso próprio mecanismo para extrair dados de sistemas SAP.
Estrutura de armazenamento de dados no SAP HCM
Para compreender os requisitos de tal mecanismo, primeiro precisamos determinar quais dados precisamos.
A maioria dos dados no SAP HCM é armazenada em tabelas SQL simples. Com base nesses dados, os aplicativos SAP visualizam estruturas organizacionais, funcionários e outras informações de RH para o usuário. Por exemplo, esta é a aparência da estrutura organizacional no SAP HCM:
Fisicamente, essa árvore é armazenada em duas tabelas - nos objetos hrp1000 e nas conexões entre esses objetos no hrp1001.
Objetos “Departamento 1” e “Escritório 1”:
Relação entre objetos:
Pode haver um grande número de tipos de objetos e tipos de conexões entre eles. Existem conexões padrão entre objetos e conexões personalizadas para suas necessidades específicas. Por exemplo, a relação padrão B012 entre uma unidade organizacional e um cargo de tempo integral indica o chefe de um departamento.
Exibição do gerente no SAP:
Armazenamento em uma tabela de banco de dados:
Os dados dos funcionários são armazenados em tabelas pa*. Por exemplo, os dados sobre eventos de pessoal de um funcionário são armazenados na tabela pa0000
Decidimos que o GreenPlum pegará dados “brutos”, ou seja, basta copiá-los das tabelas SAP. E diretamente no GreenPlum eles serão processados e convertidos em objetos físicos (por exemplo, Departamento ou Funcionário) e métricas (por exemplo, número médio de funcionários).
Foram definidas cerca de 70 tabelas cujos dados deverão ser transferidos para o GreenPlum. Depois disso, começamos a elaborar um método para transmitir esses dados.
A SAP oferece um número bastante grande de mecanismos de integração. Mas a maneira mais fácil é proibir o acesso direto ao banco de dados devido a restrições de licenciamento. Assim, todos os fluxos de integração devem ser implementados no nível do servidor de aplicação.
O próximo problema foi a falta de dados sobre registros excluídos no banco de dados SAP. Quando você exclui uma linha do banco de dados, ela é excluída fisicamente. Aqueles. não foi possível a formação de um delta de mudança com base no tempo de mudança.
É claro que o SAP HCM possui mecanismos para registrar alterações de dados. Por exemplo, para transferência posterior para sistemas destinatários, existem ponteiros de alteração que registram quaisquer alterações e com base nos quais é formado um Idoc (um objeto para transferência para sistemas externos).
Exemplo de IDoc para modificação do infotipo 0302 para um empregado com número pessoal 1251445:
Ou mantendo registros de alterações de dados na tabela DBTABLOG.
Um exemplo de log para exclusão de um registro com a chave QK53216375 da tabela hrp1000:
Mas esses mecanismos não estão disponíveis para todos os dados necessários e seu processamento no nível do servidor de aplicativos pode consumir muitos recursos. Portanto, habilitar massivamente o log em todas as tabelas necessárias pode levar a uma degradação perceptível do desempenho do sistema.
O próximo grande problema foram as tabelas agrupadas. Os dados de estimativa de tempo e folha de pagamento na versão RDBMS do SAP HCM são armazenados como um conjunto de tabelas lógicas para cada funcionário para cada cálculo. Essas tabelas lógicas são armazenadas como dados binários na tabela pcl2.
Cluster da folha de pagamento:
Os dados de tabelas clusterizadas não podem ser considerados um comando SQL, mas requerem o uso de macros SAP HCM ou módulos funcionais especiais. Conseqüentemente, a velocidade de leitura de tais tabelas será bastante baixa. Por outro lado, esses clusters armazenam dados que são necessários apenas uma vez por mês – folha de pagamento final e estimativa de tempo. Portanto, a velocidade neste caso não é tão crítica.
Avaliando opções para formar um delta de alterações de dados, decidimos considerar também a opção de descarregamento completo. A opção de transferir gigabytes de dados inalterados entre sistemas todos os dias pode não parecer boa. No entanto, também tem uma série de vantagens - não há necessidade de implementar o delta no lado da fonte e implementar a incorporação deste delta no lado do receptor. Conseqüentemente, o custo e o tempo de implementação são reduzidos e a confiabilidade da integração aumenta. Ao mesmo tempo, foi determinado que quase todas as alterações no SAP HR ocorrem num horizonte de três meses antes da data atual. Assim, optou-se por um download completo diário dos dados do SAP HR N meses antes da data atual e um download completo mensal. O parâmetro N depende da tabela específica
e varia de 1 a 15.
O seguinte esquema foi proposto para extração de dados:
O sistema externo gera uma solicitação e a envia ao SAP HCM, onde essa solicitação é verificada quanto à integridade dos dados e permissões de acesso às tabelas. Se a verificação for bem-sucedida, o SAP HCM executa um programa que coleta os dados necessários e os transfere para a solução de integração Fuse. O Fuse determina o tópico necessário no Kafka e transfere os dados para lá. Em seguida, os dados do Kafka são transferidos para o Stage Area GP.
Nesta cadeia, estamos interessados na questão da extração de dados do SAP HCM. Vejamos isso com mais detalhes.
Diagrama de interação SAP HCM-FUSE.
O sistema externo determina a hora da última solicitação bem-sucedida ao SAP.
O processo pode ser iniciado por um cronômetro ou outro evento, incluindo a definição de um tempo limite para aguardar uma resposta com dados do SAP e iniciar uma solicitação repetida. Em seguida, ele gera uma solicitação delta e a envia ao SAP.
Os dados da solicitação são enviados ao corpo em formato json.
Método http: POST.
Exemplo de solicitação:
O serviço SAP monitora a solicitação quanto à integridade, conformidade com a estrutura SAP atual e disponibilidade de permissão de acesso à tabela solicitada.
Em caso de erros, o serviço retorna uma resposta com o código e a descrição adequados. Se o controle for bem-sucedido, ele cria um processo em segundo plano para gerar uma amostra, gera e retorna de forma síncrona um ID de sessão exclusivo.
Em caso de erro, o sistema externo registra no log. Em caso de resposta bem-sucedida, transmite o id da sessão e o nome da tabela para a qual foi feita a solicitação.
O sistema externo registra a sessão atual como aberta. Caso existam outras sessões para esta tabela, elas serão fechadas com um aviso registrado.
A tarefa em segundo plano SAP gera um cursor com base nos parâmetros especificados e um pacote de dados do tamanho especificado. O tamanho do lote é o número máximo de registros que um processo lê do banco de dados. Por padrão, é assumido igual a 2000. Se houver mais registros na amostra do banco de dados do que o tamanho do pacote utilizado, após a transmissão do primeiro pacote, o próximo bloco é formado com o deslocamento correspondente e o número do pacote incrementado. Os números são incrementados em 1 e enviados estritamente sequencialmente.
Em seguida, o SAP passa o pacote como entrada para o serviço web do sistema externo. E o sistema realiza controles no pacote recebido. Uma sessão com o id recebido deverá estar cadastrada no sistema e deverá estar em status aberto. Se o número do pacote for > 1, o sistema deverá registrar o recebimento bem-sucedido do pacote anterior (package_id-1).
Se o controle for bem-sucedido, o sistema externo analisa e salva os dados da tabela.
Além disso, se o sinalizador final estiver presente no pacote e a serialização tiver sido bem-sucedida, o módulo de integração será notificado sobre a conclusão bem-sucedida do processamento da sessão e o módulo atualizará o status da sessão.
No caso de um erro de controle/análise, o erro é registrado e os pacotes desta sessão serão rejeitados pelo sistema externo.
Da mesma forma, no caso oposto, quando o sistema externo retorna um erro, ele é registrado e a transmissão do pacote é interrompida.
Para solicitar dados do lado SAP HСM, foi implementado um serviço de integração. O serviço é implementado no framework ICF (SAP Internet Communication Framework - ). Permite consultar dados do sistema SAP HCM usando tabelas específicas. Ao criar uma solicitação de dados, é possível especificar uma lista de campos específicos e parâmetros de filtragem para obter os dados necessários. Ao mesmo tempo, a implementação do serviço não implica qualquer lógica de negócio. Algoritmos para cálculo de delta, parâmetros de consulta, monitoramento de integridade, etc. também são implementados no lado do sistema externo.
Este mecanismo permite coletar e transmitir todos os dados necessários em poucas horas. Esta velocidade está quase aceitável, por isso consideramos esta solução como temporária, o que permitiu suprir a necessidade de uma ferramenta de extração no projeto.
No cenário alvo, para resolver o problema de extração de dados, estão sendo exploradas opções de utilização de sistemas CDC como Oracle Golden Gate ou ferramentas ETL como SAP DS.
Fonte: habr.com