Quando chego a um projecto novo atribuem-me uma chave de desenvolvimento para cada sistema de desenvolvimento associado. Normalmente esta é-me enviada por e-mail. Normalmente perco-lhes o rasto.

Ainda que o SAP nos apareça como um todo, este é constituído por várias partes independentes interligadas. Há um pequeno programa standard que verifica se os relógios de cada uma destas partes estão correctos e sincronizados.

Provavelmente não será de grande utilidade no dia-a-dia. Mas não deixa de ser uma curiosidade engraçada.

O vídeo abaixo demonstra como é simples criar condições para facilmente injectar comandos ABAP em programas em produtivo. Ponderei sobre partilhar este vídeo pois o seu conteúdo pode ser usado para fins menos nobres. Mas, como já aconteceu no passado, acredito que é preferivel que isto seja divulgado pois é fundamental que os administradores de sistema estejam conscientes desta possibilidade e protejam os seus sistemas dela. Pois é algo verdadeiramente perigoso.

Criaste uma tabela e os seus ecrãs de manutenção como objectos locais.

Quando mais tarde te arrependeres e decidires transportar a tabela, como fazes para os transportar também os ecrãs de manutenção?

Transportar só o grupo de funções não chega, vai dar erro.

O Manelinho criou a transacção ZFB01 associada ao programa ZFB01 que faz lá umas coisas e depois faz CALL TRANSACTION à FB01. A seguir veio o Joãozinho e correu a transacção ZFB01.

Conseguiu começar a corrê-la porque tem permissões para a transacção ZFB01. Mas a meio teve um erro porque não tem permissões para a transacção FB01.

Tanto o Manelinho como o Joãozinho sabiam que os administradores de sistema nunca na vida deles darão ao Joãozinho autorizações para correr a FB01.

Quando chamas uma função por RFC tens de lhe dar a RFC DESTINATION do sistema remoto:

CALL FUNCTION ‘ZESPIRREI’
  DESTINATION ’sistema_longe_daqui’.

E se, por alguma razão, precisares que a função que corre no sistema remoto chame uma função no sistema original. Sabes fazê-lo?

O Nuno Morais desenvolveu uma ferramenta muito útil que permite comparar objectos entre sistemas e que funciona muito melhor do que a transacção SREPO. O Abapinho passa a ser o seu repositório oficial. Código no GitHub. Em breve, instruções. Até lá vai experimentando, é intuitivo. E se gostares ou tiveres sugestões deixa aqui um comentário. Obrigado Nuno por teres desenvolvido isto e por o partilhares com o mundo no Abapinho.

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?

No outro dia apareceram uma série de coisas espatifadas na nossa máquina de testes. De repente ninguém podia trabalhar na máquina. Na STMS encontrámos uma série de ordens de transporte indevidamente transportadas para lá. O utilizador que aparece associado a cada uma dessas ordens é o dono dela. Mas será que a culpa é dele? Não terá sido outra pessoa a fazer o transporte?

Como saber?

Aqui está uma funçãozinha fixe para obter alguns detalhes de um sistema remoto acessível por RFC: RFC_SYSTEM_INFO Não posso dar aqui nenhum exemplo porque estaria a revelar informação segreda importantíssima sobre o meu cliente que depois seria certamente utilizada pelos maus para fazerem espionagem industrial. Mas é fácil de testar na SE37. Obrigado kingofthebigmacs pela foto. O Abapinho saúda-vos.

Queres invocar uma função RFC noutro sistema mas, porque não és necrófago, só o queres fazer se ele estiver vivo. Precisas então de uma forma de saber se esse determinado sistema destino RFC está vivo. Como fazes? O Charles Santana faz assim: DATA: rfcdest TYPE rfcdest, ping_status TYPE /sdf/e2e_traffic_light_numeric. CALL FUNCTION '/SDF/RFC_CHECK' EXPORTING iv_destination = rfcdest iv_ping = 'X' iv_logon = 'X' iv_latency = 'X' IMPORTING ev_ping_status = ping_status. if lv_ping_status <> 1.

Espatifaste o sistema produtivo: fizeste uma alteração a um método de uma classe (ou a uma função, vá). Outra pessoa faz outra alteração a outro método da mesma classe (ou a outra função do mesmo grupo de funções, vá) e grava-a num transporte diferente. Quando transportas as tuas alterações para produtivo descobres que a classe (ou função, vá) agora tem um erro de sintaxe porque as alterações tinham dependências. Descobres também que agora, e até resolveres este problema, todos os teus colegas funcionais te odeiam.

Se precisas mesmo de aceder a um SAP e ninguém te deixa e não tens um computador onde o possas instalar ou não tens ciência ou paciência para o fazer, podes sempre alugar.

Já há uns tempos que o Abapinho não mexia com o fogo. Hoje mexerá. Porque hoje mostrará como executar comandos DOS na máquina local do utilizador. Quando tiveres terminado de ler este artigo estarás apto a formatar o disco rígido de todos os teus utilizadores. Lidar com o perigo ajuda-nos a tomar consciência do poder que temos e da responsabilidade que vem junto com ele. Querido leitor, segue a tua consciência.

O SAPlink é um programa Z que se instala no ambiente de desenvolvimento e que permite importar e exportar os mais variados tipos de objectos do Workbench.

Olha aqui exemplos de como o SAPlink pode ser usado:

• Transferir uma tabela de um sistema SAP para outro

• Partilhar uma classe na Internet

• Fazer um backup local de segurança de um conjunto de programas antes de fazer uma alteração perigosa

• Guardar um desenvolvimento no nosso repositório pessoal (no Evernote, claro) para o caso de vir a precisar dele mais tarde noutro projecto

• Etc.