Tivoli Service Desk 6.0 Developer's Toolkit - Guia do Criador de Interface

Capítulo 2: Conceitos do EHLLAPI

Retornar ao Índice


Introdução

Visão Geral

Esta seção abrange os seguintes tópicos:

Como inicializar conexões

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.

Aplicativos de interface para múltiplas conexões

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.

Teclas de controle

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);

Vigilâncias

Definição

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.

Comandos de vigilância

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);

Tempo de estabelecimento

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);

Especificação da condição de vigilância efetiva

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.

Como Enviar Dados

Visão Geral

Há vários recursos fornecidos pelo EHLLAPI para digitar e editar dados. Estes incluem comandos para:

Como mover o cursor do host

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.

Como limpar campos

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');

Como mover entre campos

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.

Como mapear funções

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."

Como Ler Dados

Introdução

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.

Como ler campos de dados

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.

Funções de mapa

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.

Como capturar uma tela do host

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.

Como Gravar uma Interface

Introdução

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.

Projetar emissões

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.

Requisitos

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".

Regras comerciais

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.

Identificadores de telas

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

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.

Como codificar e testar

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.

  1. Configure uma rotina pequena que:
  2. Obtenha a tela do host apropriada na sua sessão do terminal.
  3. Execute a rotina shell.
  4. Certifique-se de que a função termine na tela onde ela começou.

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.

Tratamento de Erro

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

Retornar ao Índice

Copyright