Encadeamento de múltiplas transacções
Tipicamente, a execução de uma aplicação desenvolvida à medida regista mais que um único documento em SAP. Tipicamente isso implica mais que uma chamada transaccional.
O programador deve evitar que a execução tenha múltiplos commit’s mas nem sempre é possível ou porque a execução é por batch input ou porque a segunda acção precisa do commit da primeira acção. Nestes casos é necessário garantir o controlo e rastreabilidade dos erros ocorridos durante a gravação, quer seja recorrendo a funcionalidades de reprocessamento ou através de mecanismos que dêm ao utilizador a capacidade de intervir na ocorrência de um erro ou simplesmente um registo de log dos erros para posterior análise e correcção pela equipa de manutenção.
No caso do grupo PT este tipo de funcionalidades está já disponibilizado num desenvolvimento à medida, a máquina de estados.
Mas caso não exista, outros mecanismos podem ser preparados:
- A execução fica a cargo de uma cadeia de processos do XI;
- A execução fica a cargo de um ou mais IDOC’s;
- A execução fica a cargo de um workflow;
Cada um destes três mecanismos já tem funcionalidades para análise de erro e reprocessamento que podem ser aproveitadas. As seguintes opções são menos aconselhadas mas também possíveis em alguns cenários:
- Se execução é por batch-input
- Interromper a execução na ocorrência de um erro para utilizador tomar medidas correctivas;
- A execução regista em tabelas de log os dados da execução e os erros para que a equipa de manutenção resolva manualmente o problema e reprocesse.
Quando existe mais de um commit é necessário ter uma preocupação adicional. Quando o commit transaccional ocorre inicia-se a fase de atualização da transacção[1]. Até à conclusão da actualização V1 os objectos de bloqueio não são libertados, ou seja, após o commit é possível que o objecto esteja bloqueado no momento em que se pretende iniciar o segundo bloco transaccional. Em alguns casos isto significa que o programador deve controlar o fim do bloqueio antes de iniciar o bloco seguinte.
Ficam aqui duas sugestões para resolver os problemas de bloqueio. Se for uma chamada de BAPI use a instrução SET UPDATE TASK LOCAL[2] antes da chamada ao BAPI_COMMIT. Isso faz com que a execução apenas continue após a fase de actualização V1. Para chamadas de batch input use o parâmetro update da instrução CALL TRANSACTION … UPDATE 'L' com o mesmo objectivo.
Estes cenários devem prever sempre no programa uma funcionalidade de estorno que permita cancelar de forma simples todo o processo do inicio ao fim.
Output
O output para impressão ou para e-mail tem mecanismos próprios fora do âmbito deste documento. Se a execução for uma chamada standard então não é preciso preparar nada. Senão, sempre que possível usar um dos seguintes (por ordem de prioridade, ignorando alguns outputs mais específicos ou menos relevantes):
- Adobe Interactive Forms
- Smartforms
- SAPscript
[1] Ver help da SAP sobre LUW’s
[2] Ver documentação da SAP sobre a instrução. Basicamente significa que as tarefas na secção de actualização V1, onde se libertam os bloqueios, executam localmente e portanto o processamento só continua após completar o código desta secção.
