Tivoli Service Desk 6.0 Developer's Toolkit - Guia do Criador de Interface
Esta seção abrange os seguintes tópicos:
Antes que o seu aplicativo do TSD Script possa começar a interagir com o host, o aplicativo deve ser inicializado. O EHLLAPI utiliza um identificador para se referir à conexão que estabeleceu e declara uma variável do tipo EHLLAPI, como a que segue:
conn:EMUCONNECTION;
A seguir, o identificador deve ser associado a uma sessão de terminal específica. O comando EHLLAPI utilizado para associar a sessão é:
EMUConnect(conn, 'A');
Neste comando, o identificador conn é associado à sessão A do terminal.
Devido ao fato de todos os comandos EHLLAPI exigirem que uma conexão seja especificada, um aplicativo de interface deve estabelecer essas conexões.
O EHLLAPI suporta múltiplas conexões para sessões do terminal, então um aplicativo da interface pode ser parecido com o exemplo a seguir:
VARIABLES conn1:EMUCONNECTION; conn2:EMUCONNECTION; ACTIONS EMUConnect(conn1, 'A'); EMUConnect(conn2, 'B'); END;
O Interpretador do TSD Script associa vários atributos a estas conexões. Por exemplo, em uma conexão o limite de tempo de vigilância pode ser definido para um segundo e em outra ele pode ser definido para 10 segundos. O Interpretador do TSD Script obtém o limite de tempo correto do identificador de conexão especificado quando o comando de vigilância foi emitido.
Pressionar uma tecla avisa ao host para fazer alguma coisa. Por exemplo, ao editar dados, você pode querer limpar um campo. Para fazer isso, você pressiona a tecla de controle denominada ERASE_EOF (apagar até o fim do campo).
Mesmo quando o processamento requerido do host é complexo, submeter os dados pode ser
tão simples quanto pressionar ENTER.
O EHLLAPI fornece um comando para enviar dados através de teclas de controle para o host. O comando aceita
códigos inteiros que representam teclas de controle. O TSD Script também tem constantes internas que
servem como mnemônicos para os inteiros. O código para pressionar ENTER é mostrado aqui:
EMUPressKey(conn, $EMUEnter);
Toda vez que um aplicativo submete dados ao host para processamento, há um período de tempo decorrido quando o aplicativo aguarda uma resposta do host. É necessário que uma interface consiga parar e aguardar estes períodos. Estes períodos são chamados vigilâncias.
Há vários comandos do TSD Script designados para dar aos aplicativos a capacidade para executar estas vigilâncias. Quando um destes comandos é emitido, o aplicativo pára até que a condição seja satisfeita ou até que o limite de tempo de vigilância tenha expirado. Os códigos de retorno dos comandos de vigilância indicam quais ações foram tomadas.
As condições em que um aplicativo deve aguardar dependem da situação. Geralmente, um aplicativo aguarda o inibidor de entrada desaparecer. Outras vigilâncias podem incluir:
Por exemplo, se desejar que um aplicativo aguarde até que o inibidor de entrada desapareça, você poderá emitir o comando:
EMUWaitForNoX(conn);
Quando você utiliza o comando EMUWaitForNoX, é necessário prestar atenção especial na utilização do aplicativo do mainframe do indicador X. Alguns aplicativos permitem que o X "pisque," o que significa que o X desaparece momentaneamente e, em seguida, reaparece por mais alguns segundos.
O comando EMUWaitForNoX tem um parâmetro opcional conhecido como settle time. O tempo de estabelecimento especifica quanto tempo o X deve ficar desativado antes do Interpretador do TSD Script supor que a vigilância foi concluída com êxito. Nos casos em que o tempo de estabelecimento não é especificado, é utilizado um padrão de 500 milissegundos.
O comando anterior com um tempo de estabelecimento opcional de um segundo poderia ser parecido com o exemplo abaixo:
EMUWaitForNoX(conn, 1000);
A chave para especificar um comando de vigilância é definir o comando de vigilância para dar ao usuário o máximo de informações possível. Por exemplo, suponha que você utilize um aplicativo de mainframe que solicita um nome e um endereço e espera que você pressione a tecla ENTER para processar os dados.
O comando de vigilância para tal exemplo poderia ser:
rc := EMUWaitForStringAt(conn, 'ADD OPERATION SUCCESSFUL',11,11);
Após pressionar ENTER, o X aparece por um momento na OIA e, em seguida, aparece uma mensagem na localização 11,11 afirmando o sucesso da operação de entrada, por exemplo:
MSG000695 ADD OPERATION SUCCESSFUL
O código de retorno anterior indica que a operação foi concluída e a inserção foi bem-sucedida. Se o código de retorno indicar que a vigilância falhou, o código deverá ser verificado para ver se o mainframe ainda está processando ou se a inserção falhou. Note que este código adicional executa apenas em condições de erro.
Se você utilizar:
rc :=EMUWaitForNoX(conn);
você sabe apenas que o host foi concluído. O código deve verificar ainda uma mensagem de êxito e a verificação deve ser executada para cada exemplo do comando.
Apesar de ambos os segmentos de código exigirem a mesma quantidade de verificação, o primeiro método faz com que o processamento bem-sucedido seja mais fluente.
Não ocorre verificação adicional a não ser que haja um erro. Como um resultado, as ações bem-sucedidas (que são esperadas com mais freqüência) são executadas com mais rapidez que as ações sem êxito.
Há vários recursos fornecidos pelo EHLLAPI para digitar e editar dados. Estes incluem comandos para:
Para situações em que os usuários digitam uma cadeia na posição atual do cursor do host, o exemplo a seguir mostra um comando de amostra:
EMUTypeIn(conn, 'HELLO WORLD');
É importante notar que não é possível executar um comando TypeIn quando o cursor do host está em uma área onde o host não permite digitação.
Uma seqüência de comandos é utilizada com tanta freqüência que um comando especial do TSD Script foi implementado para substituir a seqüência. Este comando pressiona ERASE_EOF antes de digitar a cadeia fornecida. O comando seria parecido com o exemplo a seguir:
EMUClrTypeIn(conn, 'HELLO WORLD');
A maioria dos aplicativos permite fazer tabulação entre campos em uma tela ou utilizar as teclas de setas. No geral, a tabulação entre campos é mais rápida a não ser que você não esteja utilizando cada campo. Nesse caso, considere a utilização de um comando para mover o cursor para ir diretamente entre os campos.
Você deve revisar o comprimento máximo de cada campo. Se a interface do EHLLAPI tentar digitar quando o cursor estiver em uma posição inválida na tela do host, o host travará o teclado até que RESET seja pressionado. Para evitar este problema, certifique-se de que os dados a serem digitados sejam menores que o campo de recepção ou que você forneceu um comprimento de truncamento para o comando EMUTypeIn ou EMUClrTypeIn.
Devido ao fato da maioria dos aplicativos de mainframe serem aplicativos de entrada de dados, muitos scripts do EHLLAPI consistem em operações simples repetidas:
Estas seqüências são utilizadas com tanta freqüência que funções de alto nível foram implementadas para executar as operações repetitivas. Estas funções são conhecidas como mapas. Os mapas, ou funções de mapeamento, permitem relacionar posições do host com campos de registro do TSD Script.
Um aplicativo pode chamar um comando do TSD Script, EMUMapUpload, para preencher todos os campos. O Interpretador do TSD Script processa entradas de arquivos de mapas muito mais rapidamente do que processa a seqüência de comandos mais simples do EHLLAPI. Há, naturalmente, alguma sobrecarga introduzida para os arquivos de mapas. Como um método prático geral, você deverá considerar um arquivo de mapa se tiver mais de cinco ou seis campos em uma tela. Para obter mais informações, consulte "Arquivos de Mapas e o Utilitário de Mapa."
Utilizar comandos de leitura é mais fácil que utilizar comandos de envio. Primeiro, a posição do cursor do host não é pertinente em uma operação de leitura. Segundo, um aplicativo pode ler dados de qualquer lugar na tela do host.
Na forma mais simples, um comando de leitura é parecido com o exemplo a seguir:
EMUFillBuffer(conn, inString, row, column, length);
Este comando lê caracteres de comprimento iniciando na linha, coluna e coloca o valor resultante na variável inString.
Se você planeja ler campos de dados de uma tela, é necessário saber o comprimento máximo de cada campo que deseja ler. Para ver o comprimento total dos campos, o aplicativo do host deve limpar todos os campos de dados na preparação para novos dados. Geralmente, os campos vazios são preenchidos com sublinhados, o que permite ver o comprimento máximo de cada campo.
Como os comandos de envio, há um comando de mapa para fazer download de uma tela de dados.
EMUMapDownload permite ler muitos campos de uma tela do host e colocar seus valores nos campos de uma variável de registro do TSD Script.
Podem haver situações em que você queira capturar uma tela inteira do host (ou alguma parte retangular dela) e armazená-la em um arquivo de texto. O cenário mais provável para isto é quando seu aplicativo encontra uma tela que ele não reconhece.
Para registrar o máximo possível da ocorrência, o aplicativo captura a tela atual para um arquivo de texto e envia um alerta sobre o problema. A pessoa que investiga o problema utiliza o arquivo para reunir o incidente e verificar como o aplicativo foi para essa tela. O TSD Script fornece o comando EMUOutFile para recortar a tela para um arquivo.
Geralmente, você tem uma compreensão do que deseja que uma interface faça. Esta seção é projetada para auxiliar no aperfeiçoamento de especificações da interface antes de você começar a gravar uma interface.
A primeira etapa para projetar uma interface é garantir que você esteja familiarizado com o aplicativo para o qual a interface é gravada.
Você deve trabalhar com o aplicativo de destino até saber exatamente como:
Além disso, você deve conhecer as "entradas e saídas" do aplicativo.
Conforme você trabalha, mantenha anotações sobre as etapas necessárias para executar ações específicas. Estas etapas eventualmente tornam-se o seu código de interface.
Procure os requisitos "ocultos". Analise os tipos de dados com os quais o seu aplicativo deve trabalhar. No caso de gerenciamento de chamada/problema, você pode desejar que a interface trate os problemas abertos com a maior prioridade, enquanto os problemas fechados têm mais de uma prioridade "como o tempo permite".
Entenda as regras comerciais que a sua empresa (ou departamento) utiliza - antes de aplicar o código permanente a estas regras em uma interface, você deve determinar se elas ainda se aplicam à situação atual. Determine e resolva essas emissões antes de projetar a sua interface.
Certifique-se de ter uma forma para identificar as telas que são utilizadas. Os aplicativos de mainframe, geralmente, têm um identificador em algum lugar na tela. O código de interface deve verificar se a tela correta é exibida (ela pode chamar uma rotina de erro e sair se não for) antes de fazer uma entrada de dados. Esta é uma forma simples e efetiva de fornecer um bom rastreamento de problemas no futuro.
Concorrência é outra emissão que deve ser endereçada antes de uma interface ser gravada. Em qualquer situação em que você tenha dois sistemas contendo os "mesmos" dados, há uma oportunidade para que o mesmo objeto de dados seja alterado nos dois sistemas de uma só vez.
Primeiro, decida como o seu aplicativo detecta tal ocorrência. O método usual é verificar a data e a hora da atualização em um registro que está para ser sobreposto.
Segundo, determine o que deve ocorrer na detecção de uma "colisão." Esta ação poderia ser tão simples quanto capturar o registro de destino para um arquivo simples e enviar um alarme a algum administrador humano. Talvez haja uma regra comercial que se aplique, como o "proprietário" do registro vindo antes de qualquer outro usuário que faz alterações.
Quando você projeta uma interface, geralmente é mais eficiente utilizar um método de cima para baixo (vai do geral para o específico). Entretanto, ao implementar uma interface, geralmente é melhor utilizar um método de baixo para cima. Com este método, você identifica e implementa as unidades de trabalho mais atômicas para a interface. Você, então, testa cada parte individualmente. Estas partes podem se tornar, então, componentes de um módulo que executa uma função de nível mais alto.
O procedimento a seguir ajuda você a aprender mais sobre como testar uma função.
Você deve testar todas as rotinas individualmente. As rotinas que não têm saída visível podem utilizar o Depurador do TSD Script para ver os resultados. Caso contrário, é necessário gravar um grupo de eventos para exibir os resultados.
Quando você testa rotinas que consultam dados, recomenda-se que você trave tabelas do SQL o menos possível. Utilizar o SQLSelect para fazer um loop através de uma busca e ciclo de upload trava as tabelas mais que o necessário ou aceitável.
Após testar todas as rotinas, as etapas para a rotina principal podem ser testadas. A rotina principal provavelmente precisa de alguma inicialização, o que pode incluir:
Cuidado: Preste atenção aos lugares onde você pluga um componente da rotina em outro. Certifique-se de que os componentes da rotina sempre deixem o aplicativo do host em uma tela conhecida.
Estruture as rotinas principais para que uma falha de tecla em um componente da rotina tenha implicações apropriadas no processamento. Em outras palavras, a rotina principal não deve tentar continuar se um componente da rotina indicar que houve uma falha irrecuperável.
Os aplicativos da interface sempre devem ser gravados com o tratamento de erro em mente. Há muitos eventos que podem ocorrer durante a operação da interface.
Há várias opções para tratar de erros, dependendo do tipo de erro detectado. As opções incluem:
A melhor abordagem é uma combinação das opções anteriores. Você pode instalar uma rotina geral de tratamento de erro que notifica um usuário e registra as informações relevantes. A rotina pode ser modificada posteriormente para identificar a maioria dos erros recuperáveis. Os erros irrecuperáveis sempre resultam em um alarme para o usuário.
Tivoli Service Desk 6.0 Developer's Toolkit - Guia de APIs Existentes