Design de Aplicações - Parte 11

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.