O consumo de memória do TDF no HANA
Na geração dos relatórios SPED, alguns registros consomem grande quantidade de memória HANA para a sua execução completa. Se há um grande volume de dados e documentos (geralmente observado em operações com lançamentos contábeis e notas fiscais), o processamento acaba gerando picos de consumo de memória, que em casos extremos podem até levar ao cancelamento da execução.
E para endereçar este problema, foi construída a solução de SPLIT de registros para execução em lotes.
Execução de registros em lotes
O objetivo da solução é reduzir o consumo de memória através da divisão da execução do registro em lotes de dias.
A configuração deve ser feita diretamente no ambiente desejado, sem envolver o transporte de requests. A solução pode ser considerada como um tuning dos SPEDs, e deve ser configurada de acordo com a necessidade de cada ambiente e de cada registro do cliente.
View de configuração: /TMF/V_REG_SPLIT. Deve ser acessada através da SM30.
No exemplo acima, temos a configuração de SPLIT determinada para os registros I200 e I250 do relatório ECD, C100 e C175 do relatório EFD Contribuições. O modo de divisão de execução é DAYS (número de dias), e 5 é a quantidade de dias definida para cada divisão. Neste momento, apenas o modo de SPLIT por “dias” está disponível.
O número mínimo de dias é 1 e o número máximo é 27 dias. Você pode configurar para executar de 1 dia até 27 dias por lote, porém se o último lote tiver 1 dia apenas, ele será incluído na última execução. Dessa forma, uma possível execução do registro I200 do ECD para o mês de janeiro se desdobraria em 6 execuções. Quando qualquer valor diferente deste for preenchido, a configuração não surtirá efeito e o registro não será dividido em lotes na sua execução.
Como exemplo, consideremos a configuração acima para a divisão em lotes do registro I200. Data real da execução do I200: 01/01/2020 até 31/01/2020.
A regra de Split com 5 dias aplicada à query original gera 6 execuções:
- 01/01/2020 até 05/01/2020;
- 06/01/2020 até 10/01/2020;
- 11/01/2020 até 15/01/2020;
- 16/01/2020 até 20/01/2020;
- 21/01/2020 até 25/01/2020;
- 26/01/2020 até 31/01/2020.
A configuração ainda permite utilizar o parâmetro Empresa. Caso nenhuma empresa tenha sido informada, a configuração funcionará para todas as empresas. Se alguma empresa foi informada, aquela linha de configuração específica só funcionará para aquela empresa. É possível utilizar as configurações com e sem empresa, ao mesmo tempo, para o mesmo registro e a solução considerará a configuração da mais específica para a mais geral.
Os testes desta solução demonstraram uma redução de pico de uso de memória de 70% para a configuração em 5 dias. Então, se antes a execução do registro I200 consumia 100 mb de memória para rodar, agora espera-se que este registro utilize 30 mb.
Pode haver um aumento de tempo de execução, isso varia conforme o cenário de cada cliente, a quantidade de dias utilizada na configuração e o registro envolvido.
Trace Log foi atualizado para esta solução
O programa Trace Log foi atualizado para fazer a leitura de cada lote da execução do registro. O log descreverá a execução individual de cada lote, a query correspondente e os valores totais de tempo para o registro como um todo.
Para o registro I200, consideramos a configuração de 5 dias. O resultado a ser observado no log será assim:
Há uma separação entre o total do registro e os lotes de processamento. Abaixo, podemos ver as informações específicas do registro como um todo.
Não há query porque as queries executadas estão gravadas em cada lote específico.
Foram adicionadas no programa as seguintes informações:
- HANA_TIME – Tempo exclusivo da execução da HANA view.
- FORMT_TIME – Tempo exclusivo da formatação dos dados no ABAP para o arquivo final.
- PERST_TIME – Tempo exclusivo de persistência dos dados na tabela /TMF/D_SPED_FILE.
Os lotes possuirão as informações abaixo:
As informações são as mesmas do total, mas específicas para aquele lote. Os tempos são exclusivos de cada parte da execução. Dessa forma, se houver problemas com a execução de um determinado lote, é possível analisar apenas o lote com problemas.
Além dos parâmetros já mencionados, a query está registrada no lote. A configuração determina a divisão da execução em 5 dias. Assim, a query do lote 1 do exemplo descrito constará conforme vemos abaixo. As datas exclusivas do lote podem ser verificadas na query.
IMPORTANTE: Limitações da solução
A solução foi construída para funcionar através da execução de diversas queries para a composição do registro. Portanto, ela funcionará somente para os registros que trabalham com informações não consolidadas.
Registros como o I200 e o I250 do relatório ECD, assim como os registros C100 e C170 do relatório EFD ICMS IPI, não possuem nenhum tipo de consolidação ou cálculo envolvendo as datas de seleção do registro. Assim, estes registros funcionam sem alterações mesmo com a solução ativada.
Se a solução for ativada para registros com consolidação, como o registro J150 do ECD, por exemplo, o resultado do registro sairá incorreto e a solução não funcionará. Por isso, recomendamos a avaliação do registro, incluindo testes de execução e validação dos dados do registro quando houver a necessidade de utilizar a ferramenta de execução em lotes.
Esta solução está disponível para TDF na SAP Note 3055328 – [TDF SP15] Note 090: Enablement of Register Execution in Batches.
Gostaríamos muito de saber o seu feedback. Deixe seu comentário abaixo caso tenha alguma dúvida ou sugestão para um próximo post.
Além dos comentários, você pode entrar em contato conosco através da plataforma Customer Influence. Lá, você pode propor ideias para melhorar nosso produto, votar em outras ideias já lançadas e acompanhar ideias em implementação.
Também não se esqueça de seguir a tag SAP Tax Declaration Framework for Brazil aqui na SAP Community para ficar ligado nas últimas notícias sobre o TDF Add-on.
Um abraço e até a próxima,
Carolina Hefler
Time de Desenvolvimento do TDF/ACR BR
TDF: Configuration for the batch execution of registers
TDF memory consumption on HANA
In the generation of SPED reports, some registers consume a great amount of HANA memory for their entire execution. In case there is a massive volume of data and documents (generally seen in operations with accounting entries and fiscal documents – notas fiscais), the process may end up generating memory consumption peaks which, in extreme cases, can even lead to cancelling the execution.
In order to address this problem, we have come up with the register SPLIT solution for batch execution.
Batch execution of registers
The solution is intended to reduce memory consumption by splitting register batch execution in days.
The configuration is to be conducted directly in the desired environment, without involving request transports. We can consider the solution sort of a SPED register tuning, and it has to be configured according to the needs of each environment and of each of the customer’s register.
/TMF/V_REG_SPLIT configuration view. Access it via the SM30 transaction.
In the example above, we have the SPLIT configuration determined for registers I200 and I250 of the ECD report, C100 and C175 of the EFD Contribuições report. The execution split mode is DAYS (number of days), and 5 is the quantity of days defined for every split. Currently, only the DAYS SPLIT mode is available.
The number of days ranges from 1 to 27. You can configure the solution to execute from 1 to 27 days for each batch. However, if the last batch has only 1 day, it will be included in the previous execution. This way, a possible execution for the I200 register of the ECD report for the month of January would be divided in 6 executions. When any value out of this range is inserted, configuration won’t have any effect and the register will not be divided in batches for its execution. As an example, let’s consider the configuration above for the batch splitting of the I200 register. Real date of execution of the I200 register: From January 1st, 2020 to January 31st, 2020.
The Split rule of 5 days is applied to the original query and generates 6 executions:
- From January 1st, 2020 to January 5th, 2020;
- From January 6th, 2020 to January 10th, 2020;
- From January 11th, 2020 to January 15th, 2020;
- From January 16th, 2020 to January 20th, 2020;
- From January 21st, 2020 to January 25th, 2020;
- From January 26th, 2020 to January 31st, 2020;
The configuration still allows us to use the Company Code parameter. If no company code is informed, the configuration will work for all the companies. If any company code is informed, that line of configuration will work only for that company. It is possible to use configurations with and without the company code, at the same time and for the same register. The solution will, then, consider from the most specific configuration to the most general.
Testing of this solution demonstrated a 70% reduction of memory peak usage for the 5-day configuration. Thus, if the execution of the I200 register previously consumed 100 mb, it is now expected that this register use 30 mb.
There can be an increase in execution time. That will change according to each customer’s scenario, the number of days used in the configuration, and the register involved.
Trace Log updated for this solution
The Trace Log program has been updated to read each batch of register execution. The log will describe the individual execution of every batch, the corresponding query, and the total amount of time for the complete register.
For the I200 register, we have considered the 5-day configuration. The result to be observed in the log should be as follows:
There is a separation between the register total and the processing batches. Below, you can see specific information for the register as a whole.
There is no query since the executed queries are recorded for each specific batch.
Additional information was added to the program:
- HANA_TIME – Time specifically related to the HANA view execution.
- FORMT_TIME – Time specifically related to formatting data in ABAP to the final file.
- PERST_TIME – Time specifically related to the persistence of data in the /TMF/D_SPED_FILE table.
The information is the same as in the total results, but specific to that batch. Times are now exclusive to each part of the execution. Thus, if there is any problem with the execution of a certain batch, it will be possible to isolate the troublesome batch and analyze it.
Apart from the already mentioned parameters, QUERY is registered in the batch. Configuration determines splitting the executions for 5-day ranges. As such, batch 1 QUERY from the described example will be as seen below. Exclusive batch dates can be checked in the query.
IMPORTANT: Limitations of this solution
This solution was built to work through the execution of several queries to compose the register. Therefore, it will only work for registers that carry non-consolidated information.
Registers like the I200 and the I250 of the ECD report, as well as the C100 and the C170 of the EFD ICMS IPI report do not have any kind of consolidation or calculation involving the selection dates of the register. Consequently, these registers will work without changes, even with the solution being activated.
If the solution is activated for registers with consolidation, like the J150 of the ECD report, for instance, the result will be incorrect, and the solution will not work. This is the reason why we recommend evaluating the register, including execution tests and validation of register data when there is the need of using the batch execution tool.
This solution is available for TDF through SAP Note 3055328 – [TDF SP15] Note 090: Enablement of Register Execution in Batches.
We would love to have your feedback. Leave your comment below should you have should you have any question or suggestion for an upcoming post.
Apart from the comment section, you can also contact us through the Customer Influence platform, where you can propose ideas to improve our product, vote on previously released ideas and follow those ideas being currently implemented.
Follow the SAP Tax Declaration Framework for Brazil tag here at the SAP Community to keep updated with the latest news on the TDF Add-On.
See you next time,
Carolina Hefler
TDF/ACR BR Development Team
