A Hora do Pesadelo: Transporte de Requests

Fala moçada! Meu primeiro post do ano, e é claro que eu quero começar desejando um excelente 2015, com muita paz, saúde, sucesso e muito debug pra vocês! ♥
Bom, agora vamos aos trabalhos…
Imagine a seguinte situação: faltam dois dias para o Go-live e você precisa verificar a lista de transporte de requests. Então você descobre que existem centenas de requests, com milhares de objetos. Logo no começo da lista você percebe que está uma bagunça. Dependências entre requests que não estão na lista, alguns transportes “não são mais necessários”, mas as mudanças não foram revertidas no ambiente, alguns transportes emergenciais já foram feitos para produção, e assim vai… E mesmo depois de tudo isso, quando os transportes foram finalmente liberados, surge aquele erro que causa tristeza e depressão:

ENCERRADO COM CÓDIGO DE RETORNO:           ===> 8 <===.

Pois é, meu caro amigo zumbi, isso também já tirou o sono de muita gente.  É impossível muito difícil garantir que todas as requests serão transportadas para a produção sem problemas, e quanto maior a lista, maiores são as chances de erros. Limpar toda a bagunça demora muito tempo e é muito chato. O que fazer então? A dica mais valiosa que eu dou é:

“SEJA ORGANIZADO”

Isso mesmo! A maioria dos problemas podem ser evitados se você ficar bem atento ao criar a lista de transportes e organizá-los corretamente antes de liberá-los. Mas ninguém é perfeito, não é mesmo?

Se você não é tão organizado assim e se atrapalha com as dependências, a dica que eu vou dar agora pode te ajudar.

Acesse a transação SE03 (Transport Organizer) e selecione a opção “Exibir/modificar atributos da ordem” na pasta “Administração”:

Crie um novo atributo que você vai usar para gravar o número da request que deve ser transportada antes:

Agora, se você criar/ alterar uma request (transação SE01), na aba “Caracts.”, o atributo que você acabou de criar pode ser preenchido no campo “Atributo” e o número da request no campo “Valor”:

Pronto! Agora quando você (ou qualquer outra pessoa) for liberar a request para transporte, pode verificar quais são as requests que devem ser liberadas primeiro através do atributo que você criou. Mas… e se alguém esquecer de verificar antes de liberar? Você pode automatizar esse processo implementando o método “CHECK_BEFORE_RELEASE” da BADI “CTS_REQUEST_CHECK”. Basicamente, fazemos uma validação se as requests relacionadas ao atributo já foram liberadas.

Mas os problemas não são apenas em relação à ordem de transporte. Podem existir outros problemas, como por exemplo, outros projetos que utilizam o mesmo objeto ou versões diferentes entre os ambientes de produção e desenvolvimento. Você precisa estar sempre atento para essas situações.

Como regra geral, User- Exits devem sempre ser transportados separadamente. A mesma regra se aplica para elementos DDIC que podem ou serão usados ​​em vários objetos.

Outras considerações que devemos fazer: o grupo de função precisa ser transportado ou apenas a função? A classe completa deverá ser transportada ou apenas a implementação do método? O programa completo (incluindo textos e documentação) deverá ser transportado ou apenas o código do relatório? Manter a lista de transporte limpa e simples pode evitar uma dor de cabeça mais tarde. 😉

Vou listar aqui alguns erros comuns que podem acontecer nos transportes:

• Perda de funcionalidade na produção (se um transporte mais recente é sobrescrito);
• Transportar código para produção que ainda não foi testado;
• Objetos dependentes de elementos DDIC (Data Dictionary) que estão em desenvolvimento, mas não em produção (gerando DUMPs).

Agora, imagina um projeto que durou mais de um ano, onde vários desenvolvedores trabalharam nele e cada um fez uma lista de transportes. E adivinha quem vai verificar a lista inteira? VOCÊ, claro! Mas calma! Antes que você vire um zumbi comedor de cérebro, vou te mostrar algumas ferramentas que podem te ajudar um pouco nessa difícil missão.

Para fazer o acompanhamento das requests, eu acho bem legal esse programa: Transport Trace. É um relatório ALV que mostra os status das requests e o progresso dos transportes. Se você tem uma lista enorme de requests para monitorar, eu recomendo!

Na minha busca pelo SCN encontrei esse programa que verifica se algum objeto está faltando no transporte. Fiz um teste bem simples, onde criei uma tabela em uma request e o elemento de dados local. Executei o programa analisando a request e ele detectou o erro sem problemas.

Uma outra ferramenta que eu testei foi a ZTCT – Transport Checking Tool (disponível AQUI), que faz uma análise mais elaborada, como por exemplo, as versões dos objetos.

Atenção: esses programas não detectam erros complexos, mas podem te ajudar a analisar a lista de transporte.

E o Transporte de Cópias?

Isso veio para ajudar (e muito) o nosso lado. Se você ainda não sabe o que é, se liga.

Vamos imaginar um sistema padrão com 3 ambientes: Desenvolvimento (DEV) – Qualidade (QAS) – e Produção (PRD). Normalmente, todo seu trabalho é feito no ambiente de DEV e quando você libera a request para transporte, o sistema assume que será transportado para QAS e depois para PRD. Mas no mundo real sabemos que não é bem assim, pois nem todos os transportes irão para PRD devido à correção de bugs, mudanças de escopo, etc.

Por esta razão foi criado o Transporte de Cópias. Um transporte de cópias vai passar a versão mais recente do objeto de DEV para QAS, mas não vai assumir que será transportado para PRD. Portando ele transporta uma cópia do objeto e assume que seu destino final é QAS.

Também por esse motivo você precisará criar apenas uma única request e fazer quantos transportes de cópias forem necessários para testes em QAS. Você só precisará liberar a request quando quiser realmente transportar para PRD. Dessa forma reduzimos a quantidade de transportes desnecessários e a criação de várias requests para o mesmo objeto. Lembre-se de que quanto maior o número de transportes, mais dependências você deverá verificar e, portanto, maiores os riscos de importação de transportes para produção.

Resumindo…

No final das contas, o verdadeiro truque é ter cuidado desde o início. Verifique antes de liberar as requests no ambiente de desenvolvimento. Organize-as corretamente e tente pensar no futuro. Isso pode evitar um monte de problemas. E para fazer isso, uma ferramenta de verificação de transporte pode vir a calhar. Sempre tenha em mente que a responsabilidade pelos transportes são dos desenvolvedores que criaram os objetos e que tem uma ideia melhor do que foi alterado e porquê.

E se você conhece outra ferramenta ou tem algumas dicas para organizar a lista de transporte, compartilha aí com a gente! Valeuuuuuuuuuu galera!  🙂