Comunicação por evento entre programas
2014-12-22
Na mitologia grega a forma de comunicação mais frequentemente utilizada pelos deuses para comunicar com os mortais era o estupro. Estupravam por dá cá aquela palha.
O mais parecido que temos com estupro no ABAP é o comando SUBMIT, que é também a forma mais comum de comunicação entre dois programas.
Mas há formas menos brutas de um programa comunicar com outro. Recorrendo a um evento, por exemplo.
Presumamos que tens um programa chamado ZEUS (em rigor seria ZEUS_TOURO, mas OK) que quer comunicar com outro chamado ZEUROPA.
- Na transacção SM62 crias o evento com um nome tipo Z*. Chamemos-lhe ZAS! Uma vez criado podes encontrá-lo perto do fim da longa lista de eventos, junto dos restantes eventos criados pelo cliente;
- Se carregares no botão direito podes fazer uma data de coisas com ele. Uma delas é transportá-lo, ou seja, adicioná-lo a uma ordem de transporte;
- No programa ZEUS, no sítio onde houver vontade de invocar a ZEUROPA, mete o seguinte código:
CALL FUNCTION 'BP_EVENT_RAISE' EXPORTING eventid = 'ZAS' EXCEPTIONS BAD_EVENTID = 1 EVENTID_DOES_NOT_EXIST = 2 EVENTID_MISSING = 3 RAISE_FAILED = 4 OTHERS = 5 - Na transacção SM36 cia um job ZEUS_ZAS_EUROPA com um único passo, a execução (salvo seja) da ZEUROPA;
- Nas condições de execução do job escolhe a opção “após evento” e escolhe o evento ZAS. Grava.
Pronto.
Ao correres o programa ZEUS,
Ele lança o evento ZAS,
Que espoleta o job ZEUS_ZAS_EUROPA,
Que executa (salvo seja) a ZEUROPA.
O Abapinho saúda-vos.
23 de dezembro de 2014 às 16:48
Bom dia.
Gostaria de registrar minha opnião contra o uso de eventos.
1- Fica mais difícil para debugar o ZEUROPA;
2- Fica mais difícil para encontrar todos os pontos de chamada para o ZEUROPA
3- Não sei se é possível passar parâmetros para o ZEUROPA
4- Como o ZEUS irá ter conhecimento de que o ZEUROPA terminou a execução?
5- Alguém pode, inadvertidamente, cancelar o job
26 de dezembro de 2014 às 20:19
Olá Diogo,
Concordo que os eventos de sistema são um bocado toscos e os argumentos que apresentas são válidos mas não considero que sejam argumentos contra o uso de eventos. São antes limitações intrínsecas destes.
Os eventos não são adequados a todas as situações. Mas há determinadas circunstâncias em que são a melhor (ou mesmo a única) solução.
Os eventos são um dos mecanismos ideais para fazer programas “loosely coupled”, como se diz em inglês, que não sei dizer em português. A programação GUI moderna, por exemplo, é intrinsecamente “loosely coupled” e amplamente baseada em eventos. Sofre de algumas das desvantagens que apontas mas não é por isso que o uso de eventos não é a melhor opção e não recorrer eles seria bem mais limitativo.
O exemplo que dei é meramente ilustrativo. Mas repara: basta que no momento do desenvolvimento do ZEUS não se saiba ainda quem este vai chamar ou não se querer pré-defini-lo para ter de recorrer a um evento por forma a manter os dois independentes. Amanhã pode substituir-se o ZEUROPA pelo ZASIA ou pelo ZAMERICA sem ter de alterar um única linha do ZEUS. Aliás, amanhã o ZEUS pode inclusive espoletar os três ao mesmo tempo.
Quanto às desvantagens que apontaste:
1. Verdade;
2. Verdade;
3. Não é possível, mas só é uma desvantagem se for preciso passar parâmetros;
4. Não é uma desvantagem se o ZEUS não precisar de o saber;
5. Não me parece que seja relevante. Alguém pode inadvertidamente matar um processo qualquer também :)
Na programação OO uma classe pode também publicar e subscrever eventos para criar ligações “loosely coupled” entre métodos. Neste caso o ABAP é mais sofisticado e permite fazer “where used” e tornar o debug mais simples. Quando possível utilizar eventos OO é claramente preferível a utilizar os toscos eventos de sistema.