Não farás COMMIT em user-exits
Não faças COMMIT dentro de user-exits. E garante também que rotinas que possas chamar a partir de user-exits não o fazem.
Não faças COMMIT dentro de user-exits. E garante também que rotinas que possas chamar a partir de user-exits não o fazem.
Claro que já conheces o botão “Modelo” no editor de ABAP que permite introduzir automaticamente modelos para módulos de função, chamadas a métodos e outros.
Mas o novo editor agora cresceu um bocadinho (já só está 10 anos atrasado em relação ao Eclipse em vez de 20) e já permite completar automaticamente alguns comandos através do atalho CTRL-SPACE.
Se um desenvolvimento necessitar de mais do que uma tabela de parametrização, considera agrupar as tuas vistas de manutenção num “cluster”. Assim será mais intuitivo mantê-las. Isto fará ainda mais sentido se umas dependerem de outras uma vez que na definição do “cluster” estas relações podem ser explicitadas.
Exemplo: Como encavalitar tabelas
Tenta seleccionar sempre apenas os campos que vais realmente usar. Escolher todos é um desperdício de recursos. Excepção feita ao uso das FM *_SINGLE_READ que, embora leiam os campos todos, fazem cache dos dados, sendo por isso ainda assim mais rápidos de usar quando usados múltiplas vezes com a mesma chave. Se queres apenas verificar que um registo existe, selecciona apenas um campo, e se possível aquele que estás a usar como critério, evitando assim declarares uma variável extra. Exemplo: SELECT KUNNR INTO V_KUNNR FROM KNA1 WHERE KUNNR = V_KUNNR. https://abapinho.com/2010/11/select-todos-os-campos/
Sempre que achares que um valor que estás a usar num programa pode mudar e não o puderes tornar um parâmetro de entrada ou do ecrã de seleccção, guarda-o numa tabela de constantes (ex: ZCONSTS). Esta tabela nunca deverá ser usada directamente. Em vez disso, cria uma classe ZCL_CONSTS que aceda a ela e usa sempre esta classe para obter as tuas constantes. Como é mostrado neste artigo: https://abapinho.com/2009/06/constantes/
Não caias na tentação de usar a T900 ou outras tabelas do género para este propósito. É certo que muita gente faz isso. Mas é feio, sujo e essas tabelas nem sequer têm uma chave adequada porque não foram pensadas para isso.
Quando alteras um objecto e o guardas numa ordem de transporte ele normalmente fica bloqueado. Dentro da ordem de transporte é podes bloquear objectos que não estejam já bloqueados que não estão já bloqueados noutra ordem. Mas, uma vez bloqueados, como é que se desbloqueiam?
Código que seja usado comummente deve estar disponível centralmente, se possível guardado em pacotes bem identificados (ex: ZFERRAMENTAS) para que seja facilmente encontrados e transportados.
Há muito código já disponível na Internet que permite executar várias funções comummente necessárias (ex: ABAP2XLSX). Adopta-o;
Para as tuas tarefas mais comuns, desenvolve ferramentas que possas reutilizar, juntando-as à biblioteca central;
Divulga a biblioteca entre os colegas do teu projecto para evitar que venham a perder tempo a criar código duplicado;
Truquezito catita: quando na SE38 quiseres meter uma palavra ou expressão entre parêntesis ou aspas, basta seleccioná-la e carregar em ( ou [ ou ‘. E imediatamente isto fica (isto) ou [isto] ou ‘isto’.
Obrigado Sérgio Fraga pela dica.
Se precisas de adaptar o conteúdo de um ficheiro com valores (CURR) tem sempre em consideração a parametrização do utilizador (USR01-DSCFM). Se precisares de converter um alfa-numérico num número, usa o FM MOVE_CHAR_TO_NUM. Se precisares de converter um número num alfa-numérico, usa WRITE curr TO str [CURRENCY waers].
Uma das únicas situações onde é inevitável é com SELECT-OPTIONS. Em todos os outros casos, declara explicitamente uma variável local com uma estrutura equivalente. Basicamente o comando TABLES cria variáveis globais obscuras que aumentam a ambiguidade do código. E variáveis globais devem ser evitadas na maior parte dos casos.