Tivoli Service Desk 6.0 Developer's Toolkit Interface Designer の手引き
このセクションでは以下のトピックについて説明されています:
TSD Script アプリケーションがホストとの対話を開始できるようにするためには、その前に アプリケーションを初期化しなければなりません。 次のように、EHLLAPI は確立した接続を 参照するためにハンドルを使用し、EHLLAPI タイプの変数を宣言します:
conn:EMUCONNECTION;
次に、ハンドルを特定の端末セッションと関連付けなければなりません。 セッションを関連付けるために使用する EHLLAPI コマンドは次の通りです:
EMUConnect(conn, 'A');
このコマンドでは、ハンドル conn が端末セッション A と関連付けられます。
すべての EHLLAPI コマンドは接続が指定されていることを必要とするので、インターフェース・アプリケーションが これらの接続を確立しなければなりません。
EHLLAPI は端末セッションへの複数の接続をサポートするので、インターフェース・アプリケーションは 次の例のようになる可能性があります:
変数 conn1:EMUCONNECTION; conn2:EMUCONNECTION; ACTIONS EMUConnect(conn1, 'A'); EMUConnect(conn2, 'B'); END;
TSD Script Interpreter はいろいろな属性をこれらの接続に関連付けます。 たとえば、 ある接続では監視時間制限が 1 秒に設定され、別の接続では 10 秒に設定される場合があります。 TSD Script Interpreter は、監視コマンドが出された時に指定された接続ハンドルから正しい 時間制限を取り出します。
キーを押すことによって、何かを実行するようにホストに信号を送ります。たとえば、 データの編集時にフィールドを消去したい場合があります。 そのためには、ERASE_EOF (フィールドの 終わりまで消去) という名前の制御キーを押します。
ホストから要求された処理が複雑であっても、データの処理依頼は Enter (キー) を
押すのと同じくらい簡単に行なうことができます。
EHLLAPI には、データを制御キーを経由してホストに送信するコマンドが備わっています。
このコマンドは制御キーを表す整数コードを受け入れます。 また TSD Script は、整数の
簡略記号としての働きをする組み込み (標準装備の) 定数をもっています。 Enter (キー) を
押すためのコードは次の通りです:
EMUPressKey(conn, $EMUEnter);
アプリケーションが処理のためのデータをホストに処理依頼する時には常に、アプリケーションが ホストからの応答を待機する経過時間の期間があります。 これは、インターフェースがこれらの期間を 一時停止したり、その期間の終わりまで待機することができるようにするために必要なことです。 これらの期間を監視と呼びます。
これらの監視を実行するための機能をアプリケーションに与えるために設計された TSD Script コマンド がいくつかあります。 これらのコマンドの 1 つが出されると、アプリケーションは条件が満たされるか、 あるいは監視時間制限が満了するまで一時停止します。 監視コマンドの戻りコードは、どんなアクションが取ら れたかを示します。
アプリケーションが待機しなければならない条件は、状態によって異なります。 一般的には、アプリケーションは入力禁止標識が消えるまで待機します。 他の監視には 次のものがあります:
たとえば、入力禁止標識が消えるまでアプリケーションが待機するようにしたい場合には、 次のコマンドを出すことができます:
EMUWaitForNoX(conn);
EMUWaitForNoX コマンドの使用時には、メインフレーム・アプリケーションでの X 標識の使用に特に注意しなければなりません。 一部のアプリケーションでは、 X が"バウンス"することができます。これは X が瞬間的に消えた後で、 再び数秒間現れることを意味します。
EMUWaitForNoX コマンドは安定時間と呼ばれる任意指定パラメーターを もっています。 安定時間は、TSD Script Interpreter によって監視が正常に完了したと判断される前に、 X が働いていなければならない時間の長さを指定します。 安定時間を指定しない場合には、 デフォルト値として 500 ミリ秒が使用されます。
任意指定の安定時間を 1 秒に設定した直前のコマンドは次の例のようになります:
EMUWaitForNoX(conn, 1000);
監視コマンドを指定する秘けつは、ユーザーに可能な限り多くの情報を提供するように 監視コマンドを設定することです。 たとえば、名前およびアドレスの入力を求めて、ユーザーが Enter (実行) キーを押してデータを処理することを期待するメインフレーム・アプリケーションを 使用する場合などです。
このような例の場合の監視コマンドは次のようになります:
rc := EMUWaitForStringAt(conn, 'ADD OPERATION SUCCESSFUL',11,11);
Enter (キー) を押した後で、OIA (操作員情報域) に X が瞬間的に現れて、 次に入力操作が正常に実行されたことを述べるメッセージが 11,11 の位置に現れます。たとえば、次の通りです:
MSG000695 追加操作が正常に実行されました
直前の戻りコードは、操作が完了して挿入が正常に実行されたことを示します。 監視が失敗したことを戻りコードが示している場合には、コードを検査して、メインフレームが まだ処理中かどうか、あるいは挿入が失敗したかどうかを調べなければなりません。 この追加の コードはエラー状態のもとでのみ実行されることに注意してください。
次のコードを使用した場合は:
rc :=EMUWaitForNoX(conn);
ホストが終了したことだけが分かります。コードは正常を伝えるメッセージについてさらに 検査しなければならず、コマンドのすべてのインスタンスについて検査を実行しなければなりません。
両方のコード・セグメントが同じ量の検査を必要とするとしても、最初のメソッドの方が 正常な処理を能率的に実行します。
エラーがない限り追加の検査は行なわれません。結果として、正常なアクション (この方が望ましい) は そうでないアクションより速く実行されます。
データの入力および編集については、EHLLAPI には数多くの機能が備わっています。 それらには次のことを実行するコマンドが含まれます:
ユーザーが現行のホスト・カーソル位置に文字列を入力するような状態の場合には、 次の例に示すようなサンプル・コマンドがあります:
EMUTypeIn(conn, 'HELLO WORLD');
ホストがキーストロークを許可していない領域にホスト・カーソルがある時には、 TypeIn コマンドを実行することができないことに注意することが 重要です。
一連のコマンドがしばしば使用されるので、その順序を置き換えるための特殊な TSD Script コマンドが実装されています。 このコマンドは、ユーザーが提供した 文字列を入力する前に ERASE_EOF を押します。 このコマンドは次の例のようになります:
EMUClrTypeIn(conn, 'HELLO WORLD');
ほとんどのアプリケーションでは、画面上のフィールドをタブ移動したり、あるいは 矢印キーを使用することができます。 一般的には、すべてのフィールドを使用しない限り、 フィールド間をタブ移動する方が速いです。 この場合には、フィールド間を直接移動する ためのカーソル移動コマンドの使用を考えてください。
各フィールドの最大長を検討しなければなりません。 カーソルがホスト画面上の無効な 位置にある時に EHLLAPI インターフェースが入力を試みた場合には、ホストは、「リセット」 が押されるまでキーボードをロックします。 この問題を避けるためには、入力されるデータが 受け入れフィールドより短いこと、あるいは EMUTypeIn または EMUClrTypeIn コマンドに対して短縮形の長さを指定していることを確認してください。
ほとんどのメインフレーム・アプリケーションはデータ入力アプリケーションであるので、 多くの EHLLAPI スクリプトは、次のような繰り返される単純な操作で構成されます。
これらの順序はしばしば使用されるので、反復操作を実行するための高水準機能が 実装されています。 これらの機能はマップと呼ばれます。マップすなわちマップ機能により、 ホスト位置を TSD Script レコード・フィールドに対応付けることができます。
アプリケーションはすべてのフィールドに入力するために、1 つの TSD Script コマンド EMUMapUpload を呼び出すことができます。 TSD Script Interpreter は マップ・ファイル・エントリーを、より単純な一連の EHLLAPI コマンドを処理するより速く 処理します。 もちろん、マップ・ファイルにはいくつかのオーバーヘッドがインストールされています。 一般的な経験法則として、画面上に 5 つまたは 6 つ以上のフィールドがある場合には、 マップ・ファイルの使用を考慮すべきです。 詳細については、"マップ・ファイルとマップ・ユーティリティー" を参照してください。
読み取りコマンドの使用は送信コマンドの使用ほど複雑ではありません。 第 1 に、 読み取り操作ではホスト・カーソルの位置は無関係です。 第 2 に、アプリケーションは ホスト画面上の任意の場所からデータを読み取ることができます。
最も簡単な形式では、読み取りコマンドは次の例のようになります:
EMUFillBuffer(conn, inString, 行, 列, 長さ);
このコマンドは行、列で始まる長さ文字を読み取り、結果の値を変数 inString に 入れます。
画面からデータ・フィールドを読み取る予定がある場合には、読み取りたい各フィールドの 最大長を知っておく必要があります。 フィールド全体の長さを調べるためには、ホスト・アプリケーション は新規データに備えてすべてのデータ・フィールドを消去しなければなりません。 一般的には、 空のフィールドは下線で埋められ、これによって各フィールドの最大長を知ることができます。
送信コマンドと同様に、1 画面のデータをダウンロードするためのマップ・コマンドがあります。
EMUMapDownload によって、ホスト画面から多くのフィールドを読み取り、 それらの値を TSD Script レコード変数のフィールドに入れることができます。
ホスト画面全体 (あるいは画面の一部の長方形部分) を取り込んでそれを テキスト・ファイルに保管したい場合があります。 その典型的な例は、 アプリケーションが認識できない画面に出会った場合です。
可能な限り多くのオカレンスを記録するために、アプリケーションは現行画面を テキスト・ファイルに取り込んで、この問題についてのアラートを送信します。 この問題を調査する担当者は、ファイルを使用して問題の断片をつなぎ合わせ、 アプリケーションがどのようにしてその画面に至ったかを確かめます。 TSD Script は 画面をファイルに切り抜きするための EMUOutFile コマンドを備えています。
一般的には、ユーザーはインターフェースで何をしたいかを理解しています。 このセクションは、インターフェースの作成を開始する前にインターフェースの仕様を 強化するのに役立つよう設計されています。
インターフェース設計の第 1 ステップは、インターフェースが作成されるアプリケーション についてユーザーが精通することです。
次の方法を正確に理解できるまで、ターゲット・アプリケーションについて学習しなければなりません:
さらに、アプリケーションの "すみずみ" まで学習しなければなりません。
作業時に、特定のアクションを実行するのに必要なステップに留意してください。 これらのステップは最終的にはインターフェース・コードとなります。
"隠れた" 要件を探してください。 アプリケーションが処理しなければならない データのタイプを分析します。 コール / Problem Management の場合には、インターフェースが オープンな問題を高優先順位で処理するようにすることができ、一方閉じた問題は さらに "時間の許す限り" の優先順位をもっています。
会社 (または部門) の業務規則をインターフェースにハードコーディングする前に、それらの ルールを理解してください。これらのルールが現行の状態にまだ適用されているかどうかを判別しな ければなりません。 インターフェースを設計する前に、これらの問題を判別し、解決してください。
使用される画面を識別する方法があることを確認してください。 メインフレーム・アプリケーションは 通常、画面上のどこかに識別子をもっています。 インターフェース・コードはデータ入力を行なう前に、 正しい画面が表示されていることをチェックします (エラー・ルーチンを呼び出すことができ、それが ない場合は終了します)。 これは将来の問題の追跡可能性を提供するための簡単で効果的な方法です。
並行性は、インターフェースの作成前にアドレス指定しなければならないもう 1 つの問題です。 "同じ" データが含まれている 2 つのシステムがある状態では常に、同じデータ・オブジェクトが 両方のシステムで同時に変更される機会があります。
最初に、アプリケーションがそのようなオカレンスをどのようにして検出するかを決めます。 通常の方法は、上書きされるレコードの更新日時をチェックすることです。
2 番目に、"衝突" を検出した時にどうするかを決めます。このアクションは、 ターゲット・レコードをフラット・ファイルに取り込んで、誰かアドミニストレーターにアラームを送信する のと同じくらい簡単です。 おそらく、レコードの "所有者" は変更を行なう他のどの ユーザーよりも優先順位をもつなどの業務規則が適用されます。
インターフェースを設計する時には、トップダウン・メソッド (全般から特定に進む) を 使用するほうが一般的により効果的です。 しかし、インターフェースを実装する時には、通常は ボトムアップ・メソッドを使用する方がより良い方法です。 このメソッドを使用して、 インターフェースの最もアトミックな作業単位を識別し実装します。 その後で、各断片を個別に テストします。 その後で、これらの断片は高水準機能を実行するモジュールのコンポーネントとなる ことができます。
次の手順は、機能のテストについてさらに学習するために役立ちます。
すべてのルーチンを個々にテストしなければなりません。 可視の出力をもっていないルーチンは、 TSD Script Debugger を使用して結果を見ることができます。 そうでない場合は、結果を表示する ためのイベント・グループを作成する必要があります。
データを照会するルーチンをテストする時には、SQL テーブルのロック回数をできるだけ 少なくすることをお勧めします。 取り出しおよびアップロード・サイクルをループするために SQLSelect を使用すると、必要以上に、あるいは許容以上に長時間テーブル をロックすることになります。
すべてのルーチンをテストした後で、メインルーチンのステップをテストすることができます。 メインルーチンはおそらく何らかの初期設定を実行する必要があります。たとえば、次のことです:
注意: 1 つのルーチン・コンポーネントを別のものに挿入する位置に注意してください。 ルーチン・コンポーネントが常に識別できる画面上でホスト・アプリケーションを終了するようにしてください。
1 つのルーチン・コンポーネントの中のかぎとなる障害が処理における適切な暗示となるように、 メインルーチンを構成してください。 換言すれば、1 つのルーチン・コンポーネントが回復不能な 障害があったことを指示した場合には、メインルーチンは処理を続行すべきではありません。
インターフェース・アプリケーションは常にエラー処理を念頭に置いて作成しなければなりません。 インターフェース操作時には多くのイベントが起こることがあります。
検出されたエラーのタイプに応じて、エラー処理にはいくつかのオプションがあります。 オプションは次の通りです:
最良の方法は上記のオプションを組み合わせることです。 ユーザーに通知して関連情報を記録する 汎用エラー処理ルーチンをインストールすることができます。 このルーチンは、最も回復可能なエラー を処理するために、後から変更することができます。 回復不能エラーは常にユーザーに対して アラームを出します。
Tivoli Service Desk 6.0 Developer's Toolkit レガシー API の手引き