Scripts Globais

Este tópico explica o conceito de scripts globais do ClearQuest.

Você pode utilizar scripts globais para definir funções comuns que podem ser chamadas a partir de qualquer gancho no esquema. Os scripts globais são como uma biblioteca de sub-rotinas; o software Rational ClearQuest não os chama diretamente.

Os scripts globais são úteis quando você possui vários tipos de registro que chamam o mesmo código de gancho. Eles permitem centralizar a manutenção do código de gancho e evitar a cópia do código de gancho em vários locais. Por exemplo, o script global incluído no pacote do Rational ClearQuest Email permite que várias ações enviem notificação chamando um script global.

A única forma de executar um script global é chamá-lo a partir de um outro script. No final, entretanto, uma chamada a um script global deve ser rastreada para uma chamada a um gancho baseado em registro, como gancho de campo, gancho de ação ou script de registro. Como as chamadas de um script global podem sempre ser rastreadas para um gancho com base no registro, cada script global é fornecido com um objeto de entidade implícito que é transmitido para o gancho com base no registro que originou a chamada.

Você pode gravar scripts utilizando o VBScript e o Perl, mas um tipo de linguagem não pode chamar um outro tipo de linguagem. Ao gravar um script global, grave-o na mesma linguagem que o script que o chama.

Utilize funções apenas em um gancho global, pois todo código em um script global é executado a menos que ele esteja em uma função.

Para obter informações adicionais, consulte Gravando Scripts e Contexto Operacional para Utilizar Scripts.

Para obter exemplos de scripts relevantes, consulte Exemplo de Script Global.

Utilizando Sub-rotinas para Scripts Globais

Para Perl, as variáveis $entity e $session são variáveis globais que tornam-se ativas quando um gancho é executado. Estas variáveis são definidas no tempo de execução e podem ser utilizadas no código do script global. Entretanto, essas variáveis não são utilizadas para chamar os métodos de objetos Entity ou Session no contexto de um script global.

Se o código do script global utiliza estas variáveis para chamar um método (tais como, $entity->GetSession), a validação do esquema falha porque $session e $entity não são definidos até o tempo de execução. Por exemplo, esse código fora de uma sub-rotina global falha porque você não pode chamar o método em um valor indefinido ($session).
$info = $session->GetProductInfo();
Não é suficiente colocar a chamada $session em uma sub-rotina global. Por exemplo, o código a seguir falha pelo mesmo motivo porque ele tenta resolver $productInfo no tempo de compilação:
$productInfo = GetProductInfo();
   sub GetProductInfo
   {
       return $session->GetProductInfo();
   }

Em vez de utilizar variáveis globais como $productInfo, chame GetProductInfo() para recuperar o valor.

Durante a execução de ganchos Perl, $session está sempre configurado para a sessão atual. Entretanto, para um melhor desempenho, evite a definição de variáveis globais sensíveis aos dados do objeto Session ou Entity; em vez disso, grave funções de acessador globais (por exemplo, GetUserLoginName()) para recuperar os valores.

Clonagem de Script Global

Os scripts globais são projetados para serem utilizados como uma coleta global de sub-rotinas que podem ser chamadas a partir de outros ganchos (como ganchos de controle de acesso, ganchos de inicialização e ganchos de validação). Para permitir isso, todo código de script global é incluído como parte do código Perl utilizado para toda execução de gancho. Entretanto, o código de script global pode incluir instruções que estejam fora do escopo da sub-rotina (no escopo do arquivo).

A partir da versão 7.0.1, está disponível um novo aprimoramento do gancho Perl que clona scripts globais. Quando este aprimoramento é ativado, um ambiente de gancho Perl é criado; todo o código do script global é compilado e, em seguida, clonado para criar novos ambientes de gancho. O processo de clonagem evita a recompilação do código e permite que os ambientes de ganchos compartilhem uma árvore de análise. A clonagem de scripts economiza tempo e memória para cada ambiente de gancho Perl, o que fornece melhor desempenho (com melhoras significativas para o Rational ClearQuest Web).

Os desenvolvedores de esquemas devem considerar como utilizar a clonagem ao gravar scripts globais. Se a clonagem estiver ativada para ganchos globais, as instruções do escopo do arquivo nos scripts globais são executadas apenas uma vez. Então, os resultados são clonados para os interpretadores Perl subsequentes. Se a clonagem estiver desativada, este código é executado sempre que o ambiente de gancho for criado (uma vez por ação de registro e uma vez a cada chamada do script de registro).

Para evitar confusão sobre a execução do código de configuração nos scripts globais clonados, mova o código de configuração que está no escopo do arquivo para uma sub-rotina e utilize uma variável global our inserida especialmente no escopo para verificar o status da configuração. Você pode garantir que o código da configuração seja sempre executado, pelo menos, uma vez em cada ambiente de gancho e evitar múltiplas execuções. Esta sub-rotina de configuração pode ser chamada a partir de qualquer gancho que requer que a configuração seja concluída. Exemplo:
  our $run_once;
   sub DoSetup
   {
       return if defined($run_once);
       $run_once = 1;
       # executar a configuração aqui
   }
sub Defect_Initialization {
 DoSetup();
 # …
 # …
 #reconfiguração do código Defect_Initialization….
 # …
 }

Neste exemplo de código, a variável $run_once não é definida quando o ambiente de gancho é criado. Quando ele é clonado, esta variável ainda está indefinida. Quando os ganchos executam pela primeira vez e chamam DoSetup(), o código de configuração é executado.

Nota: O clone de script global Perl requer que qualquer biblioteca Perl chamada pelo código tenha encadeamento seguro. Por exemplo,
use Win32::OLE;
não deve ser utilizado em código de gancho clonado (mas pode ser utilizado em código de gancho não clonado, incluindo ganchos de ações, de campos e de registros). O Win32::OLE não é thread-safe, mas pode ser usado fora de um ambiente multiencadeado do ClearQuest Web. Por exemplo, é possível utilizar
require Win32::OLE; import Win32::OLE;
no script global para impedir que o módulo Win32::OLE seja clonado, mas o módulo não deve ser usado em esquemas que sejam usados com o Rational ClearQuest Web.
Atenção: A IBM® não pode garantir que um módulo Perl seja thread-safe, porque os módulos Perl não estão sob controle da IBM. Para obter mais informações sobre segurança de encadeamento, consulte a documentação do Perl disponível em http://www.perl.org.

Feedback