IBM System i（別名AS / 400）-グリーンスクリーンアプリケーションの自動テストの実行方法

こんにちは 私の名前はアントン・ボロビョフです。アルファ銀行では、集中型銀行システムのアプリケーション開発を担当しています。



この投稿では、グリーンスクリーンアプリケーションとは何か、それらが必要な理由、および自動テストをどのように行ったかについて、独自のソリューションを作成することで説明します。







AS / 400プラットフォーム（アプリケーションシステム/ 400）は1988年に誕生しました。 このプラットフォームの最初のOSはOS / 400で、後にi5 / OSに改名され、さらにIBM iに改名されました。 少し前、彼女は30歳の誕生日を祝いました。



IBM iオペレーティングシステムの下での開発の世界に突入すると、これは実際には古典的な意味での「レガシー」ではないことを理解しています。 これは異なる、まったく異なる環境であり、通常のWindowsまたはUnixシステムにほとんど似ていません。 このOSの主なタスクは、それが機能する機器で可能な限り生産的であることであり、ユーザーにとって便利ではありません。



私見、このOSはC ++コードを書くための非効率的なアプローチがどれほど効果的でないか（CPU損失の最大数十倍）、教科書で示されているアンチパターンのいくつかが効果的なコードのベストプラクティスであり、執筆日とソースのためにあなたを狂わせることができます1978年は問題なく組み立てられるだけでなく、設計どおりに機能します！ これらすべてにより、ソフトウェア開発への最新のアプローチを新たに見直すことができます。

はじめに

開発中のソフトウェアの品質を改善する問題は、各開発チームの心を刺激します。 Misys Equation自動バンキングシステムのモジュールのBack部分の開発と開発を担当するクレジットチームの1人も、この瞬間を回避していません。 このABSの特徴は次のとおりです。

• ABSの最初のバージョンは、CPF OS-「制御プログラム機能」の下で、前身のAS / 400-IBM System / 38プラットフォーム（1978年に登場）の下で機能しました。
• 20世紀の70年代から開発されており、出生前に書かれたコード（多くの古いコード）に出くわすことがあります。
• ABSを使用する機能は、IBM iとの緊密な統合によるものであり、IBM iの巨大な後方互換性のため、大ピラミッドの発掘で考古学者として働いているようです。

IBM i（ロゴ）



Misys ITP Integratorの技術パッケージ標準パッケージに従って、このABS（ABSオプション）のアプリケーションを開発しています。このパッケージでは、オプションはエンドユーザーとの端末対話用の対話型プログラムで構成され、バックグラウンド実行用にインストールされたインターフェイスを使用してAPIを実装する必要があると述べています。



IBM iオペレーティングシステムの下で開発されたこのような対話型プログラムは、歴史的にグリーンスクリーンアプリケーションと呼ばれ、このABSのユーザーが対話する唯一のUIです。

グリーンスクリーンアプリケーションとは何ですか？

簡単な答えは、次のようなアプリケーションです。







またはそう ：

なぜグリーンスクリーンアプリなのか？

歴史的に、AS / 400ファミリーの低およびミッドレンジシステムおよび他のIBMメインフレームで実行され、ユーザー入力を要求できる唯一の対話型アプリケーションは、グリーンスクリーンアプリケーションです。 IBM iオペレーティングシステム（およびその前身であるi5 / OSおよびAS400）でのインストール、管理、構成、および開発は、グリーンスクリーンアプリケーションのみを使用して実行されました（まだどこかで実行されています）。



緑色の画面のアプリケーションイメージには、24x80と27x132の2つのサイズと16の可能な色があります。 このスケール内で、このオペレーティングシステムの開発者とユーザーのほとんどの作業が実行されます。



このような画面サイズは、ビジネスコンピュータIBM System / 32、System / 34、System / 36、およびSystem / 38のローエンドおよびミッドレンジセグメントからAS400の先駆者に接続された「ワークステーション」の進化の結果です。 これらのワークステーションはターミナルと呼ばれ、キーボードとライトペンの形の追加機器を備えた金属ケースのスクリーンで構成されていました。 最初は、画面の2色のみがサポートされていました。緑色と明るい緑色です。そのため、確立されたフレーズ「緑色の画面アプリケーション」（英文学では緑色の画面アプリケーション）が使用されました。 1970年代には、サポートされている色の数が16に増えました。





5251ディスプレイステーションモデル11



最も一般的な端末オプションは、5251ディスプレイステーションモデル1（画面に960文字）およびモデル11（画面に1920文字）で、幅/奥行き/高さがそれぞれ530/400/400 mmに等しく、重量が34 kgでした。 モデル1の画面解像度は12x80、モデル11-24x80でした。 端末は、ホストシステムに直接接続されていました。



端末5251ディスプレイステーションモデル2（画面に960文字）およびモデル12（画面に1920文字）もあり、サイズは45 kgでした。 これらは、デスクトッププリンターまたは別のフロアプリンターを備えたモデル1（または11）端末の形式で、安価なクライアントからホストマシンへのアップストリーム接続自体を「転送」する可能性があるため、モデル1およびモデル11と区別されます。 したがって、モデル2と12はハブとして機能し、ホストマシンへの直接接続を必要とするデバイスからホストへの接続をプロキシし、大幅にコストがかかります。



5252デュアルディスプレイステーションシリーズの端末も、現代の素人には珍しいようです。





IBM System / 38 Equipment and Programsパンフレット（5252 Dual Display Station）のプロモーション画像



プリンターが接続された1つのターミナルキットの価格は、数千米ドルに達する可能性があります。



端末は、最大1 Mbpsの伝送速度の半二重モードのバストポロジを使用して、 ツインアキシャルケーブルを介してホストマシンに接続されました。 ツインアクシャルでサポートされる端末の最大数は最大6台です。ホストから最も離れた端末は、1500メートル以内の距離に配置する必要があります。



各端末の数は、インストール中に3つのスイッチによって設定されるため、バス内で一意のアドレスが決定されます。 既存の同軸ネットワークが存在する場合、二軸ケーブルから同軸ケーブルへのアダプターと、圧着用の適切なケーブル終端セットを使用することができます。 このような方式では、最大セグメント長が最大30メートルのバス上の2つのデバイスのみを接続できました。 接続されたデバイスの合計数は、モデルに応じて数十個から数十個まで変化しました。



デスクトップシステムとアクセスネットワークの開発により、かさばる端末はワークステーションに置き換えられ、サードパーティ企業のさまざまな拡張カードがホストマシンへのアクセス手段として使用され、ツインアクシャルを介した直接接続がサポートされました。 IBMが1984年にトークンリングテクノロジを開発した後、このインターフェイスを含め、マシンにアクセスするためのソフトウェアソリューションが登場しました。





ISAバスへの5250アダプター（メーカー不明）





Blackbox 5250アダプターカード（PC470C、PC471C、PC472C、PC473C、PC478C）



MS-DOSおよびMS Windowsのエミュレーターは、IBMおよびOpenSource実装（tn5250j.sourceforge.netなど）を含むサードパーティ製の両方から登場します。90年代半ばに、TCP / IPスタックが中世に登場しました。 -範囲およびローエンドのビジネスマシン。 新しいプロトコルを介したホストアクセスをサポートするために、IBMは5250シリーズターミナルエミュレータを開発しています。



ホストプロトコルを作成するために、IBMは開発中です

Telnetプロトコル拡張（RFC 854、RFC 855、RFC 856、RFC 860、RFC 885、RFC 1091、RFC 1205、RFC 1572、RFC 2877）、総称してTelnet5250（TN5250）と呼ばれ、ストリームの送受信プロセスを説明します標準Telnetプロトコルを介した5250データストリーム（5250データストリーム）。





IBM Client Access / 400 for Windows 3.1インストーラー

IBM 5250の特別な点は何ですか？

IBM 5250端末（および、それに応じてTN5250プロトコル）の機能は、 シンボル指向の通常の* nix端末とは対照的に、そのブロックの向きです。 これは、ホストが端末と通信する5250データフローがデータブロックで送信され、送信されたブロックのコンテキストのない別のシンボルが意味をなさないことを意味します。



たとえば、ホストマシンは、表示された静的情報が入力フィールドの属性と座標、およびこのブロック内のオフセットの表示とともに画面上にあるデータブロックを端末に送信し、ユーザー入力の結果をフィールドに書き込みます。 その後、ホストマシンは端末からのメッセージを予期し、ユーザー入力プロセスに参加しません。





IBM iホストRZKH.de（pub400.com）のログイン画面



さらに、ターミナルエミュレータのタスクは、マシンからのデータブロックを解釈し、ユーザー用の入力画面を形成することです。ユーザーには、許可されたフィールドに情報を入力する機会が与えられます。 また、ターミナルエミュレータのタスクには、ユーザーアクションへの反応が含まれます。 F1-F24キー（F13-F24はSHIFT + Fxを介してシミュレートされます）、Enter、Home、End、PageUp、PageDn、および最近のキーボードでは使用できないその他の特別なキーは、ホストキーと見なされます。 これは、このキーを押すと、入力フィールドからの情報と画面上のカーソル位置が以前に端末エミュレータで満たされたストリームバッファが、処理のためにホストに送信されることを意味します。





pub400.comでのWIreshark 5250データストリームログイン試行ダンプ



ホストはバッファを受信して​​解析し、入力結果は、さらにデータ検証のためにユーザーの応答を要求したプログラムに送信されます。アプリケーションは、押されたホストキーのコードを受信しながら動作し続けます。

なぜここで自動テストを行うのですか

1つの画面で最大80の異なるビジネスチェック（検証）が発生する可能性のある開発されたモジュールの何百もの画面をテストする必要に直面したときに、グリーンスクリーンアプリケーションの手動テストを自動化することを考えました。



チームが特に苦労したのは、独自のUIPathソリューションを除き、グリーンスクリーンの自動テストツールが2017年にほぼ完全になかったことです。 今日でも同様のソリューションはあまりありませんが、著者はHelpSystemsのAutomateとBlazeMeterのJMeter拡張機能を知っています（他の類似製品に関する情報を喜んで受け取ります）。

問題に関する最初の研究

銀行の職場にインストールされているTN5250端末の標準エミュレーターは、IBM Personal Communications for Windows 6.0（PCOMM 6.0）です。 同僚は、この製品には、さまざまなAPIの形で管理を自動化する定期的な手段があることを発見しました。

1. 高レベル言語アプリケーションプログラムインターフェイス（HLLAPI）。
2. 拡張HLLAPI;
3. Windows HLLAPI
4. ホストアクセスクライアントライブラリ（HACL）。

最初の3つのインターフェイスは最も古く、DOSおよび16ビットバージョンのWindowsからサポートされています。 EHLLAPIインターフェースでの作業は、次のプロトタイプに従って単一の関数を呼び出すことにより実現されます。

long hllapi (LPWORD, LPSTR, LPWORD, LPWORD);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、最初のパラメーターは実行されている関数の数値へのポインターであり、他の2つは呼び出されている関数に依存する引数であり、最後は関数の結果です。 つまり、接続ステータス「A」（エミュレーターのセッションには「A」から「Z」の範囲のラテン文字で番号が付けられています）を要求するには、次のコードを実行する必要があります（IBM文書から取得）。

  #include "hapi_c.h" struct HLDQuerySessionStatus QueryData; int Func, Len, Rc; long Rc; memset(QueryData, 0, sizeof(QueryData)); // Init buffer QueryData.qsst_shortname = 'A'; // Session to query Func = HA_QUERY_SESSION_STATUS; // Function number Len = sizeof(QueryData); // Len of buffer Rc = 0; // Unused on input hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI if (Rc != 0) { // Check return code // ...Error handling }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この方法で呼び出すことができる関数の数は約60です。



WinHLLAPIインターフェースは、ホストとの接続の確立、ホストからの切断、端末画面上のデータの変更などのイベントについて通知するために、非同期呼び出しのコールバック関数を登録できるいくつかの追加機能により、この機能をわずかに拡張します。



ホストアクセスクライアントライブラリ（HACL）インターフェイスは、「同じ名前の関数」を呼び出すのとは対照的に、オブジェクト指向のクラス階層のバリアントが提供され、ユーザーアクションを完全にシミュレートできるため、よりユーザーフレンドリーであるように見えました。





HACLエミュレータークラスライブラリクラス階層（C ++）



C ++、Java、LotusScript、およびWindows用のCOMオートメーションサーバー（Visual Basicおよび.NETに便利）用のHACL実装があります。

最初のプロトタイプ

5250データフロープロトコルは非常に複雑であり、IBMの有料有償資料へのリンクを備えた内部デバイスに関する情報は非常に少ないため、独自のエミュレーターの開発は非常に簡単で時間がかかることが明らかになりました。 これに関して、ミドルウェアレイヤーを使用するというアイデアが生まれました。これにより、特に「フィールドに値を入力する」、「画面の一部を標準と比較する」、または「ホストキーF22を押す」など、最低限必要な機能内でターミナルエミュレーターを制御できます。



以前HACLインターフェイスを使用していた同僚は、COMオブジェクトに安定性の問題があり、特定の数のコマンドが実行された後にハングする可能性があると主張しました（そしてStackOverflowの検索で確認しました）。 自動化サーバープロセスの再起動のみが役立ちました。 Javaバージョンの簡単な分析から、WrapperはJNIを介してC ++インターフェース上で使用されることがわかりました。 したがって、選択はC ++インターフェースに委ねられました。 対応するヘッダーファイルと.libファイルは、Personal Communications For Windows自体のインストールディレクトリにありました。



最初のプロトタイプはQt5に基づいており、QtScriptを介してJavaScriptコードを実行できました。 実行可能スクリプトの環境で、オブジェクトは少数のメソッドで登録され、ターミナルエミュレーターでコマンドが実行されているかのように実行できるようになりました（フィールドへの入力、ホストキーの押下、画面に表示される行の待機）。 ライブ「デモ」を実演し、ABS Equationからグリーンスクリーンアプリケーションを起動するためのユーザーケースをスクリプト化し、フィールドへの誤った入力に対するアプリケーションの反応をテストしました。 デモでは、プロトタイプが成功し、先に進むことができることが示されました。

隣人の外観

最初のプロトタイプのデモンストレーションに加えて、別の部門の同僚は、Ruby + Cucumber + Quick3270 + Rubyモジュール（ cheeze / te3270 ）の束をまとめました。 提案されたオプションでは、専用のCOMオブジェクト（HACLインターフェースと互換性がない）を介してDN32 Computing Quick3270ターミナルエミュレーターと対話するRubyモジュールを使用します。 これは、BDDスタイルの完全なグリーンスクリーンアプリケーションの自動テストソリューションであり、いくつかの事前の手順がありました。 しかし、提案されたソリューションでは、次のことに驚かされました。

1. IBM製ではなくサードパーティ製の有料エミュレーターを使用しました（すべてのエミュレーターの動作は少し異なりますが、銀行で使用されている標準的なエミュレーターで動作を確認する必要があります。エラーの価格は非常に高いです）。
2. Quick3270用のCucumberの手順の実装では、多数のスリープを使用してマシンからの応答を待ちました。
3. 自動化インターフェースを介したQuick3270の生産性は非常に低い（C ++インターフェースを介したプロトタイプでHACLを使用すると、はるかに動的に見えました）。

Quick3270ターミナルエミュレーター



プロトタイプに基づいて、CucumberをPersonal Communications for Windowsに接続し、エミュレーター画面でのアクション間のダウンタイムが最小になるようにステップを設計するために、独自の自動化サーバーを実装しようとすることにしました。



叙情的な余談 。 中規模およびエンタープライズビジネスレベルのシステムで既に解決されているはずの「レガシー」と思われるIBMには膨大な数の技術的問題があるにもかかわらず、既存の技術的ソリューションの適応と移転の妥当性は、単にプラットフォームに存在しない。 多くの場合、この不在はこのOSの機能そのものに関連しており、このスタックのソフトウェアの大幅な最適化を必要とするモダン* nix、WindowsまたはMacOS Xとは根本的に異なります。

自分の決断

独自のソリューションとして、以前に実証されたプロトタイプの開発として自動化サーバーを作成しました。 このサーバーは、RPCサーバー（Qt5 WebSocket）を介した消費者からの対話を自動化するコマンドを実行します。 企業のWindows OSイメージの一部であるPersonal Communications for Windowsと対話し、次のことを可能にします。

• ターミナルエミュレータセッションの開始/停止。
• スクリーンスクレイピンググリーンスクリーンを実行します。
• 画面上の入力フィールドを検索します。
• カーソルを制御し、キーストローク（ホストを含​​む）をシミュレートします。
• その他

オートメーションサーバーを起動する



ただし、HACL APIのすべての利点に対して、1つの欠点があります-組み込みのDB2 for i DBMSを操作する方法がわからず、テストスクリプトを実行する模擬環境を構築するために不可欠なコマンドの実行を許可しません。 RubyのDB2クライアントがIBMに存在する場合、リモートコマンドおよび分散プログラム呼び出しサーバーのクライアントは、 JTOpenライブラリの形式のJava専用です。JavaのIBM Toolbox for jt400のオープンソースバージョン） IBMは、同様の機能を備えた製品（特に、Windowsデータ転送、iSeriesからPC、PCからiSeries転送などのパーソナルコミュニケーション）の動作を分析することにより、IBM自身でこの問題の解決策を「覗き見」しました。 これらの製品は、実装によって、アプリケーションのバージョンに応じてIBM JRE 6または8を実行し、jt400ライブラリを使用することが判明しました。



自動化サーバーについては、同じことをすることにしました。 JNIは、IBM Personal Communications for Windowsに同梱されているIBM JVMを起動します。 特別なラッパーメソッドを使用して、外部からのRPCサーバーからのコマンドは、必要なjt400機能の呼び出しにプロキシすることにより実行されます。 後者にはDB2用のJDBCドライバーも含まれているため、それを使用してIBM i上のDBMSにアクセスすることにしました。



HACLを使用する場合、Oracle JVMを使用できないことに注意することが重要です。 ターミナルエミュレータセッションを実行する場合、仮想マシンのインスタンスを作成しようとするとクラッシュします。 同様に、HACLと対話するプロセスのアドレス空間でOracle JVMを実行すると、説明なしでHACLがハングします。



時間が経つにつれて、ソリューションはますます多くのジョブに実装されました。 Quick3270を使用したソリューションよりも高速に機能しました。 自動テストの回数が増えるにつれて、人気が高まりました。 ただし、操作中に追加の問題がありました。

1. 時々端末がフリーズします。
2. エミュレーターが起動するユーザーのデスクトップがブロックされているか、RDPセッションがブロックされている場合、ターミナルエミュレーターが起動を拒否するため、リグレッションスタンドで作業できません。
3. Windowsのみ
4. ツールのインストール、構成、および更新のための複雑な手順（msiパッケージ経由）。
5. 130回の自動テスト（約4000ステップ）の回帰サイクルには、7〜8時間かかりました。

何かする必要があります...

頻繁に使用されるステップのパフォーマンスのボトルネックを検索する、多数の自動テスト起動のトレースログを分析することにより、総回帰実行時間は4〜5時間に短縮されました。 しかし、自動化RPCサーバーの形でミドルウェアレイヤーをHACLインターフェイスと組み合わせて使用​​することは明らかでした。HACLインターフェイスには、システム全体の継続時間とともに蓄積する「フローティング」エラーもあり、ソリューションのパフォーマンスの改善には役立ちません。



一方、IBM Personal Communications for Windowsの代替として、ベンダーはIBM i Access-Client Solutionsと呼ばれるクロスプラットフォームソリューションを提供しています。





IBM i Access-クライアントソリューション



土曜日と日曜日の朝にコーヒーを飲みながら内部構造を分析したところ、そのコードベースはIBM Host on-Demand （IBM HOD）と呼ばれるIBMの別の製品に基づいていることがわかりました。 これは、Java 6で開発されたIBM iにアクセスするための本格的なソリューションであり、IBMマシンで使用されるさまざまな通信プロトコル（TN3270、TN5250、VTxxxなど）の完全な実装だけでなく、高レベルのJavaスイングUIコンポーネントも備えています。独自の端末エミュレーターをコンストラクターの形式で作成するために使用されます。コンストラクターは、乏しいIBMの資料から組み立てることができます IBM HODのより詳細な調査により、UIコンポーネントはHACLインターフェースのJava実装に基づいており、そのドキュメントは公開されています。 それらの動作は、C ++ HACLドキュメントとのわずかな違いと一致します。





IBM Host On-Demand（ロゴ）



次に、内部で使用するJavaライブラリを作成しました。これは、C ++ RPCオートメーションサーバーと同じインターフェイスを実装しますが、内部でIBM HODを使用します。 自動テスト手順の実行中のオーバーヘッドを削減するために、Rubyオプションに類似したすべての手順を再実装して、Ruby Cucumberからcucumber-jvmに移行しました。 RPCサーバーに似たソフトウェアインターフェイスが存在する場合、これは大したことではありません。特に、ステップ数自体の制御されない成長を抑制しようとし、この値が30単位の領域にあったことを考えると。

結果は何ですか

その結果、すべての自動テストを変更せずに操作性を実現し、作業速度が非常に高くなったため、ステップ間に人為的な遅延を導入する必要があったため、自動テストを開発するときにその作業を確認できます。そうしないと、UIが画面を最後まで描画する時間がありませんでした。



16,000ステップ以上の既存の180回の自動テストは、ステップ間の遅延が60ミリ秒であり、5時間30分に対して約30分かかりました。これは、回帰スタンドのパフォーマンスの11倍の増加に相当します。



結果はすべての期待を上回りました。 TN5250プロトコルの物理的な限界に近づいています。



現在まで、この決定は銀行全体に公表されており、他の都市の同僚も改善に参加しています。 最近の変更の中で、同僚はソリューションをJenkinsと統合し、テストバージョンでは、Xvfbを使用したLinuxサーバーでの起動のテストが完了し、自動テストを実行するパイロット操作の段階が開始されます。



最後まで読んでくれてありがとう！

すべて成功！



PS 2018年12月、次のIBMi Developer Conferenceが開催され、この記事のトピックに関するレポートが作成されました。



これまでは、銀行の従業員のみを対象に毎年会議を開催してきました。 2019年から、他の企業の参加者を招待します。 専門的および個人的なコミュニケーションの輪を広げ、感情、知識、経験を共有することは非常に興味深いです。