IBM System i (auch bekannt als AS / 400) - Wie wir automatische Tests für Green-Screen-Anwendungen durchgeführt haben

Hallo! Mein Name ist Anton Vorobyov, ich bin bei der Alfa Bank für die Entwicklung von Anwendungen für ein zentrales Bankensystem verantwortlich.

In diesem Beitrag werde ich Ihnen erklären, was Green-Screen-Anwendungen sind, warum sie benötigt werden und wie wir Autotests für sie durchgeführt haben, indem wir eine eigene Lösung dafür schreiben, mit der wir Autotests um das 11-fache beschleunigen konnten.



Die AS / 400-Plattform (Application System / 400) wurde 1988 geboren. Das erste Betriebssystem für diese Plattform ist OS / 400, das später in i5 / OS und später in IBM i umbenannt wurde. Vor nicht allzu langer Zeit feierte sie ihren dreißigsten Geburtstag.

Wenn Sie unter dem IBM i-Betriebssystem in die Welt der Entwicklung eintauchen, verstehen Sie, dass dies im klassischen Sinne des Wortes kein „Vermächtnis“ ist. Dies ist eine andere, völlig andere Umgebung, die den üblichen Windows- oder Unix-Systemen wenig ähnlich ist. Die Hauptaufgabe dieses Betriebssystems besteht darin, auf den Geräten, mit denen es arbeitet, so produktiv wie möglich zu sein und für den Benutzer nicht bequem zu sein.

Meiner Meinung nach kann dieses Betriebssystem Sie verrückt machen, wie unwirksam die üblichen Ansätze zum Schreiben von C ++ - Code sind (bis zu zehnmal CPU-Verlust), dass einige in Lehrbüchern gezeigte Antimuster die beste Vorgehensweise für effektiven Code sind und die Quelle mit dem Datum des Schreibens für 1978 nicht nur problemlos montieren, sondern auch wie geplant arbeiten! All dies lässt uns einen neuen Blick auf moderne Ansätze der Softwareentwicklung werfen.

Einführung

Das Problem der Verbesserung der Qualität der in der Entwicklung befindlichen Software erregt die Köpfe jedes Entwicklungsteams. Eines unserer Kredit-Teams, dessen Aufgabe es ist, den Back-Teil des Moduls für das automatisierte Bankensystem Misys Equation zu entwickeln, hat diesen Moment ebenfalls nicht umgangen. Die Besonderheit dieses ABS ist, dass:

• Die ersten Versionen des ABS arbeiteten unter dem Vorgänger AS / 400 - der IBM System / 38-Plattform (erschienen 1978) unter dem CPF-Betriebssystem „Control Program Facility“.
• Es wurde seit den 70er Jahren des 20. Jahrhunderts entwickelt, und Sie können auf Code stoßen, der vor Ihrer Geburt geschrieben wurde (viel alter Code).
• Die Merkmale der Arbeit mit ABS beruhen auf der engen Integration mit IBM i, und aufgrund der kolossalen Abwärtskompatibilität mit letzterem scheinen Sie als Archäologe an den Ausgrabungen der Großen Pyramide zu arbeiten.

IBM i (Logo)

Die Entwicklung von Anwendungen für dieses ABS (ABS-Optionen) erfolgt gemäß dem Standard des technischen Pakets des Misys ITP Integrator, der vorsieht, dass die Option aus einem interaktiven Programm für die Terminalinteraktion mit dem Endbenutzer bestehen und die API über die installierte Schnittstelle für die Hintergrundausführung implementieren soll .

Solche interaktiven Programme, die unter dem Betriebssystem IBM i entwickelt wurden, werden in der Vergangenheit als Green-Screen-Anwendungen bezeichnet und sind die einzige Benutzeroberfläche, mit der der Benutzer dieses ABS interagiert.

Was ist eine Green Screen-Anwendung?

Die einfache Antwort ist eine Anwendung, die so aussieht:



Oder so :

Warum Green Screen Apps?

In der Vergangenheit waren Greenscreen-Anwendungen die einzigen interaktiven Anwendungen, die auf Systemen mit niedriger und mittlerer Reichweite der AS / 400-Familie und anderen IBM-Mainframes ausgeführt wurden, mit denen Sie Benutzereingaben anfordern konnten. Installation, Administration, Konfiguration und Entwicklung auf dem IBM i-Betriebssystem (und seinen Vorgängern i5 / OS und AS400) wurden (und werden noch irgendwo durchgeführt) ausschließlich mit Green-Screen-Anwendungen durchgeführt.

Das Green-Screen-Anwendungsbild hat zwei Größen - 24 x 80 und 27 x 132 Zeichen und 16 mögliche Farben. Innerhalb dieser Skala wird der größte Teil der Arbeit von Entwicklern und Benutzern dieses Betriebssystems ausgeführt.

Solche Bildschirmgrößen sind das Ergebnis der Entwicklung von „Workstations“, die mit den AS400-Vorläufern aus den unteren und mittleren Segmenten der Geschäftscomputer IBM System / 32, System / 34, System / 36 und System / 38 verbunden waren. Diese Workstations wurden als Terminals bezeichnet und bestanden aus einem Bildschirm in einem Metallgehäuse mit Tastatur und zusätzlicher Ausrüstung in Form eines Lichtstifts. Anfangs wurden nur zwei Bildschirmfarben unterstützt - Grün und Hellgrün, weshalb der etablierte Ausdruck „Green-Screen-Anwendung“ (Green-Screen-Anwendung in der englischen Literatur) verwendet wurde. In den 1970er Jahren stieg die Anzahl der unterstützten Farben auf 16.


5251 Anzeigestation Modell 11

Die gebräuchlichsten Terminaloptionen waren 5251 Display Station Modell 1 (960 Zeichen auf dem Bildschirm) und Modell 11 (1920 Zeichen auf dem Bildschirm) mit den Abmessungen Breite / Tiefe / Höhe von 530/400/400 mm und einem Gewicht von 34 kg. Die Bildschirmauflösung von Modell 1 betrug 12 x 80, Modell 11 - 24 x 80. Das Terminal wurde direkt mit dem Hostsystem verbunden.

Die Terminals 5251 Display Station Modell 2 (960 Zeichen auf dem Bildschirm) und Modell 12 (1920 Zeichen auf dem Bildschirm) mit großen Abmessungen und einem Gewicht von 45 kg waren ebenfalls weit verbreitet. Sie unterscheiden sich von Modell 1 und Modell 11 durch die Möglichkeit, die Upstream-Verbindung von billigeren Clients in Form von Terminals Modell 1 (oder 11) mit Desktop-Druckern oder einem separaten Bodendrucker über sich selbst an den Host-Computer weiterzuleiten. Somit fungierten die Modelle 2 und 12 als Hub, der die Verbindung zum Host von Geräten herstellte, die eine direkte Verbindung zum Host-Computer erfordern, und kosteten erheblich mehr.

Die Terminals der 5252 Dual Display Station-Serie werden dem modernen Laien ebenfalls ungewöhnlich erscheinen.


Werbebild aus der IBM System / 38-Broschüre zu Geräten und Programmen (5252 Dual Display Station)

Der Preis für ein Terminal-Kit mit angeschlossenem Drucker könnte mehrere tausend US-Dollar erreichen.

Die Terminals wurden über ein Twinaxialkabel mit einer Bustopologie im Halbduplexmodus mit einer Übertragungsgeschwindigkeit von bis zu 1 Mbit / s an die Host-Maschine angeschlossen. Die maximale Anzahl von Terminals, die von Twinaxial unterstützt werden, beträgt bis zu 6 Terminals. Das vom Host am weitesten entfernte Terminal sollte sich in einer Entfernung von nicht mehr als 1500 Metern befinden.

Die Nummer jedes Terminals wird während der Installation über drei Switches festgelegt, sodass innerhalb des Busses eine eindeutige Adresse ermittelt wird. Bei Vorhandensein eines vorhandenen Koaxialnetzes können Adapter von einem Twinaxialkabel zu einem Koaxialkabel und ein geeigneter Satz von Kabelanschlüssen zum Crimpen verwendet werden. Mit diesem Schema konnten nur zwei Geräte am Bus mit einer maximalen Segmentlänge von bis zu 30 Metern angeschlossen werden. Die Gesamtzahl der angeschlossenen Geräte variierte je nach Modell zwischen einem Dutzend und mehreren Dutzend.

Mit der Entwicklung von Desktop-Systemen und Zugangsnetzwerken wurden sperrige Terminals durch Workstations ersetzt, auf denen verschiedene Erweiterungskarten von Drittunternehmen als Mittel für den Zugriff auf den Host-Computer verwendet wurden, um die direkte Verbindung über Twinaxial zu unterstützen. Nachdem IBM 1984 die Token Ring-Technologie entwickelt hatte, erschienen Softwarelösungen für den Zugriff auf die Maschine, auch über diese Schnittstelle.


5250 Adapter an ISA Bus (Hersteller unbekannt)


Blackbox 5250-Adapterkarten (PC470C, PC471C, PC472C, PC473C, PC478C)

Emulatoren für MS-DOS und MS Windows erscheinen sowohl von IBM als auch von Drittherstellern, einschließlich OpenSource-Implementierungen (z. B. tn5250j.sourceforge.net). Mitte der 90er Jahre kam der TCP / IP-Stack in die Mittelwelt -range und Low-End-Business-Maschinen. Um den Hostzugriff über das neue Protokoll zu unterstützen, entwickelt IBM Terminalemulatoren der Serie 5250.

Um ein Host-Protokoll zu erstellen, entwickelt IBM
Telnet-Protokollerweiterungen (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), zusammenfassend als Telnet5250 (TN5250) bezeichnet, beschreiben den Prozess des Empfangens und Sendens von Streams 5250 Datenströme (5250 Datenströme) über das Standard-Telnet-Protokoll.


IBM Client Access / 400 für Windows 3.1 Installer

Was ist das Besondere am IBM 5250?

Ein Merkmal der IBM 5250-Terminals (und dementsprechend des TN5250-Protokolls) ist ihre Blockorientierung im Gegensatz zu den üblichen * nix-Terminals, die symbolorientiert sind. Dies bedeutet, dass die 5250-Datenflüsse, über die der Host mit dem Terminal kommuniziert, von Datenblöcken übertragen werden und ein separates Symbol darin ohne den Kontext des übertragenen Blocks keinen Sinn ergibt.

Beispielsweise überträgt der Host-Computer einen Datenblock an das Terminal, der die auf dem Bildschirm angezeigten statischen Informationen zusammen mit den Attributen und Koordinaten der Eingabefelder und eine Angabe des Versatzes in diesem Block enthält, wo das Ergebnis der Benutzereingaben in die Felder geschrieben werden soll. Danach erwartet der Host-Computer Nachrichten vom Terminal und nimmt nicht am Benutzereingabeprozess teil.


Anmeldebildschirm für IBM i host RZKH.de (pub400.com)

Ferner besteht die Aufgabe des Terminalemulators darin, den Datenblock von der Maschine zu interpretieren und den Eingabebildschirm für den Benutzer zu bilden, wo er die Möglichkeit erhält, irgendwelche Informationen in die zulässigen Felder einzugeben. Zu den Aufgaben des Terminalemulators gehört auch eine Reaktion auf Benutzeraktionen. Die Tasten F1-F24 (F13-F24 werden über UMSCHALT + Fx simuliert), Enter, Home, End, PageUp, PageDn und einige andere Sondertasten, die auf modernen Tastaturen nicht verfügbar sind, gelten als Host-Tasten. Dies bedeutet, dass durch Drücken dieser Taste ein Stream-Puffer mit Informationen aus den Eingabefeldern und der Cursorposition auf dem Bildschirm, der zuvor mit dem Terminalemulator gefüllt war, zur Verarbeitung an den Host gesendet wird.


Anmeldeversuch für WIreshark 5250 Data Stream bei pub400.com

Der Host empfängt den Puffer, analysiert ihn und das Eingabeergebnis wird an das Programm übergeben, das die Antwort des Benutzers zur weiteren Datenüberprüfung angefordert hat, und die Anwendung arbeitet weiter, während die Anwendung den Code der gedrückten Host-Taste empfängt.

Warum wird hier überhaupt autotestet?

Wir haben darüber nachgedacht, das manuelle Testen von Green-Screen-Anwendungen zu automatisieren, als wir Hunderte von Bildschirmen eines entwickelten Moduls testen mussten, bei denen bis zu achtzig verschiedene Geschäftsprüfungen (Validierungen) auf einem Bildschirm durchgeführt werden konnten.

Das besondere Problem des Teams war das fast vollständige Fehlen von Green-Screen- Auto-Test- Tools für 2017, mit Ausnahme der proprietären UIPath- Lösung. Selbst heute gibt es nicht viele ähnliche Lösungen. Dem Autor sind Automate von HelpSystems und die JMeter- Erweiterung für BlazeMeter bekannt (ich werde mich über andere ähnliche Produkte freuen).

Die erste Untersuchung des Problems

Der Standardemulator des TN5250-Terminals, das an Arbeitsplätzen in der Bank installiert ist, ist IBM Personal Communications für Windows 6.0 (PCOMM 6.0). Kollegen stellten fest, dass dieses Produkt regelmäßig über Mittel zur Automatisierung seiner Verwaltung in Form einer vielfältigen API verfügt, nämlich:

1. HLLAPI (High-Level Language Application Program Interface);
2. Verbessertes HLLAPI;
3. Windows HLLAPI
4. Host Access Client Library (HACL).

Die ersten drei Schnittstellen sind die ältesten und werden seit DOS- und 16-Bit-Versionen von Windows unterstützt. Die Arbeit an der EHLLAPI-Schnittstelle wird implementiert, indem eine einzelne Funktion gemäß dem folgenden Prototyp aufgerufen wird:

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

Dabei ist der erste Parameter ein Zeiger auf die numerische Nummer der ausgeführten Funktion, die anderen beiden sind die kontextsensitiven Argumente für die aufgerufene Funktion, und der letzte ist das Ergebnis der Funktion. Das heißt, um den Verbindungsstatus 'A' anzufordern (Sitzungen im Emulator sind mit einem lateinischen Buchstaben im Bereich von 'A' bis 'Z' nummeriert), müssen Sie den folgenden Code ausführen (entnommen aus der IBM Dokumentation):

  #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 } 

Die Anzahl der Funktionen, die auf diese Weise aufgerufen werden können, beträgt ca. 60.

Die WinHLLAPI-Schnittstelle erweitert diese Funktionalität geringfügig um mehrere zusätzliche Funktionen, mit denen Rückruffunktionen für asynchrone Anrufe registriert werden können, um über Ereignisse beim Herstellen einer Verbindung mit dem Host, Trennen der Verbindung zum Host, Ändern von Daten auf dem Terminalbildschirm usw. zu benachrichtigen.

Die HACL-Schnittstelle (Host Access Client Library) schien benutzerfreundlicher zu sein, da im Gegensatz zum Aufrufen der "gleichnamigen Funktion" eine Variante der objektorientierten Hierarchie von Klassen bereitgestellt wurde, die jede Benutzeraktion vollständig imitierte.


Klassenhierarchie der HACL-Emulator-Klassenbibliothek (C ++)

Es gibt HACL-Implementierungen für C ++, Java, LotusScript und einen COM-Automatisierungsserver für Windows (praktisch für Visual Basic und .NET).

Erster Prototyp

Aufgrund der enormen Komplexität des 5250-Datenflussprotokolls und der äußerst knappen Informationen zu seinem internen Gerät mit Links zu geschlossener bezahlter Literatur von IBM wurde deutlich, dass die Entwicklung eines eigenen Emulators äußerst trivial und zeitaufwändig ist. In diesem Zusammenhang kam die Idee auf, eine Middleware-Schicht zu verwenden, mit der Sie den Terminalemulator innerhalb der minimal erforderlichen Funktionalität steuern können, insbesondere "Geben Sie einen Wert in das Feld ein", "Vergleichen Sie einen Teil des Bildschirms mit dem Standard" oder "Drücken Sie die Host-Taste F22".

Kollegen, die zuvor HACL-Schnittstellen verwendet hatten, behaupteten (und eine Suche in StackOverflow bestätigte dies), dass das COM-Objekt Stabilitätsprobleme hatte und nach Ausführung einer bestimmten Anzahl von Befehlen hängen bleiben könnte. Nur ein Neustart des Automatisierungsserverprozesses hat geholfen. Eine schnelle Analyse der Java-Version ergab, dass Wrapper über die C ++ - Schnittstelle über JNI verwendet wird. Daher fiel die Wahl auf die C ++ - Schnittstelle. Die entsprechenden Header- und LIB-Dateien waren im Installationsverzeichnis von Personal Communications For Windows selbst verfügbar.

Der erste Prototyp basierte auf Qt5, wo es möglich war, JavaScript-Code über QtScript auszuführen. In der Umgebung des ausführbaren Skripts wurde ein Objekt mit einer kleinen Anzahl von Methoden registriert, mit denen Befehle im Terminalemulator so ausgeführt werden konnten, als würden sie von einer Person ausgeführt (Eingabe eines Feldes, Drücken der Hosttasten, Warten auf eine Zeile auf dem Bildschirm). Wir haben eine Live-Demo demonstriert, in der wir einen Benutzerfall zum Starten einer Green-Screen-Anwendung aus ABS Equation mit einem Test der Reaktion der Anwendung auf falsche Eingaben in die Felder erstellt haben. Die Demonstration zeigte, dass der Prototyp erfolgreich war und wir weitermachen können.

Das Aussehen eines Nachbarn

Zusammen mit der Demonstration des ersten Prototyps haben Kollegen aus einer anderen Abteilung eine Reihe von Ruby + Cucumber + Quick3270 + Ruby-Modulen ( cheeze / te3270 ) zusammengestellt. Die vorgeschlagene Version verwendet ein Ruby-Modul, das über seine speziellen COM-Objekte (nicht kompatibel mit HACL-Schnittstellen) mit dem DN32 Computing Quick3270-Terminalemulator interagiert. Es war eine Komplettlösung für automatische Green-Screen-Testanwendungen im BDD-Stil mit einigen zuvor beschriebenen Schritten. In der vorgeschlagenen Lösung wurden wir jedoch durch Folgendes alarmiert:

1. Wir haben einen kostenpflichtigen Emulator eines Drittanbieters verwendet, der nicht von IBM stammt (alle Emulatoren funktionieren etwas anders, aber wir müssen die Arbeit an den in der Bank verwendeten Standardemulatoren überprüfen, da der Preis für den Fehler unglaublich hoch ist).
2. Bei der Implementierung der Cucumber-Schritte für Quick3270 wurde eine große Anzahl von Ruhezuständen verwendet, um auf eine Antwort von der Maschine zu warten.
3. Sehr schlechte Leistung von Quick3270 über die Automatisierungsschnittstelle (die Arbeit mit HACL im Prototyp über die C ++ - Schnittstelle sah viel dynamischer aus).

Quick3270 Terminal Emulator

Basierend auf dem Prototyp haben wir uns entschlossen, einen eigenen Automatisierungsserver zu implementieren, um Cucumber mit Personal Communications für Windows zu verbinden und die Schritte so zu gestalten, dass die Ausfallzeit zwischen den Aktionen auf dem Emulatorbildschirm minimal ist.

Lyrischer Exkurs . Trotz der Tatsache, dass es eine große Anzahl technischer Probleme im Zusammenhang mit dem vermeintlich "alten" IBM gibt, die anscheinend bereits für Systeme der mittleren und unternehmerischen Ebene gelöst worden sein sollten, ist die Relevanz der Anpassung und Übertragung vorhandener technischer Lösungen einfach deshalb sehr hoch ihre Abwesenheit auf der Plattform. Oft hängt die Abwesenheit mit den Funktionen dieses Betriebssystems zusammen, die sich grundlegend von modernen * nix-, Windows- oder MacOS X-Versionen unterscheiden, für die eine erhebliche Optimierung der Software für diesen Stapel erforderlich ist.

Eigene Entscheidung

Als unsere eigene Lösung haben wir einen Automatisierungsserver als Entwicklung des zuvor demonstrierten Prototyps erstellt. Dieser Server führt Befehle aus, um die Interaktion von Verbrauchern über einen RPC-Server (Qt5 WebSocket) zu automatisieren. Es interagiert mit Personal Communications für Windows, das Teil des Windows-Betriebssystemimages des Unternehmens ist, und ermöglicht Ihnen Folgendes:

• Terminal-Emulator-Sitzungen starten / stoppen;
• Screen Scraping Green Screen durchführen;
• Suche nach Eingabefeldern auf dem Bildschirm;
• Steuern Sie den Cursor und simulieren Sie Tastenanschläge (einschließlich Host).
• usw.

Starten Sie Automation Server

Trotz aller Vorteile der HACL-API hat sie einen Nachteil: Sie weiß nicht, wie sie mit dem im Betriebssystem integrierten DB2 for i-DBMS arbeiten soll, und erlaubt nicht die Ausführung von Befehlen, die für die Erstellung einer Scheinumgebung wichtig sind, in der ein Testskript ausgeführt werden würde. Wenn der DB2-Client für Ruby von IBM vorhanden ist, ist der Client für den Remotebefehls- und den verteilten Programmaufrufserver nur für Java in Form der JTOpen- Bibliothek: Die Open Source-Version der IBM Toolbox für Java (auch als jt400 bezeichnet) ) Wir haben die Lösung für dieses Problem bei IBM selbst „durchgesehen“, indem wir das Verhalten seiner Produkte mit ähnlichen Funktionen analysiert haben (insbesondere Personal Communications für die Windows-Datenübertragung, iSeries zu PC / PC zu iSeries Transfer usw.). Es stellte sich heraus, dass diese Produkte bei ihrer Implementierung je nach Version der Anwendung IBM JRE 6 oder 8 ausführen und die jt400-Bibliothek verwenden.

Für den Automatisierungsserver haben wir uns dazu entschlossen. Das JNI startet die IBM JVM, die im Lieferumfang von Personal Communications für Windows enthalten ist. Mit speziellen Wrapper-Methoden werden Befehle vom RPC-Server, die von außen kommen, ausgeführt, indem sie in Aufrufe der erforderlichen jt400-Funktionalität übertragen werden. Da letzterer auch einen JDBC-Treiber für DB2 enthält, wurde beschlossen, diesen für den Zugriff auf das DBMS unter IBM i zu verwenden.

Es ist wichtig zu beachten, dass Sie Oracle JVM bei Verwendung von HACL nicht verwenden können. Wenn Sie eine Terminalemulatorsitzung ausführen, stürzt der Versuch, eine Instanz der virtuellen Maschine zu erstellen, ab. Wenn Sie die Oracle-JVM im Adressraum eines Prozesses ausführen, der mit der HACL interagiert, bleibt diese ebenfalls ohne Erklärung hängen.

Im Laufe der Zeit wurde die Lösung für immer mehr Jobs implementiert. Es funktionierte schneller als die Lösung mit Quick3270. Die Popularität wuchs ebenso wie die Anzahl der Autotests. Während des Betriebs traten jedoch zusätzliche Schwierigkeiten auf:

1. Gelegentliches Einfrieren des Terminals;
2. Unfähigkeit, an einem Regressionsstand zu arbeiten, da der Terminalemulator den Start verweigert, wenn der Desktop des Benutzers, unter dem der Emulator gestartet wird, blockiert ist oder seine RDP-Sitzung blockiert ist.
3. Nur Windows;
4. Ein komplexes Verfahren zum Installieren, Konfigurieren und Aktualisieren von Tools (über ein MSI-Paket).
5. Unser Regressionszyklus für 130 Autotests (ca. 4000 Schritte) begann 7-8 Stunden.

Es muss etwas getan werden ...

Durch die Analyse der Ablaufverfolgungsprotokolle zahlreicher Autotest-Starts und das Auffinden von Engpässen bei der Leistung häufig verwendeter Schritte wurde die Gesamtausführungszeit für die Regression auf 4 bis 5 Stunden reduziert. Es war jedoch klar, dass die Verwendung der Middleware-Schicht in Form eines Automatisierungs-RPC-Servers in Verbindung mit der HACL-Schnittstelle, die auch „schwebende“ Fehler aufweist, die sich über die Dauer des gesamten Systems ansammeln, nicht zur Verbesserung der Leistung der Lösung beiträgt.

Andererseits bietet der Anbieter als Alternative zu IBM Personal Communications für Windows eine plattformübergreifende Lösung mit dem Namen IBM i Access - Client Solutions an.


IBM i Access - Client-Lösungen

Die Analyse der internen Struktur am Samstag- und Sonntagmorgen bei einer Tasse Kaffee ergab, dass die Codebasis auf einem anderen Produkt von IBM basiert, IBM Host on-Demand (IBM HOD). Dies ist eine vollwertige Lösung für den Zugriff auf IBM i, die in Java 6 entwickelt wurde und nicht nur die vollständige Implementierung verschiedener Kommunikationsprotokolle bietet, die in IBM-Maschinen (TN3270, TN5250, VTxxx usw.) verwendet werden, sondern auch Java-Swing-UI-Komponenten auf hoher Ebene. wird verwendet, um eigene Terminalemulatoren in Form eines Konstruktors zu erstellen, der aus der spärlichen IBM Dokumentation zusammengestellt werden kann Eine detailliertere Untersuchung des IBM HOD hat gezeigt, dass die UI-Komponenten auf der Java-Implementierung der HACL-Schnittstelle basieren, deren Dokumentation offen ist. Ihr Verhalten stimmt nur geringfügig mit der C ++ HACL-Dokumentation überein.


IBM Host On-Demand (Logo)

Als Nächstes haben wir eine Java-Bibliothek für den internen Gebrauch erstellt, die dieselbe Schnittstelle wie der C ++ RPC-Automatisierungsserver implementiert, jedoch intern IBM HOD verwendet. Um den Overhead während der Ausführung der Autotest-Schritte zu verringern, haben wir von Ruby Cucumber auf cucumber-jvm migriert und alle Schritte ähnlich den Ruby-Optionen neu implementiert. Bei einer dem RPC-Server ähnlichen Softwareschnittstelle war dies keine große Sache, insbesondere angesichts der Tatsache, dass wir versucht haben, das unkontrollierte Wachstum der Anzahl der Schritte selbst einzudämmen, und diesen Wert in der Region von 30 Einheiten hatten.

Was ist das Ergebnis?

Infolgedessen haben wir die Funktionsfähigkeit aller Autotests erreicht, ohne sie zu ändern, und die Arbeitsgeschwindigkeit wurde so hoch, dass wir eine künstliche Verzögerung zwischen den Schritten einführen mussten, damit Sie bei der Entwicklung eines Autotests dessen Arbeit beobachten konnten, da die Benutzeroberfläche sonst keine Zeit hatte, den Bildschirm bis zum Ende zu zeichnen.

Bereits vorhandene 180 Autotests mit mehr als 16.000 Schritten mit einer festgelegten Verzögerung von 60 ms zwischen den Schritten begannen etwa 30 Minuten gegenüber 5 Stunden 30 Minuten zu laufen, was einer elffachen Steigerung der Leistung des Regressionsstandes entspricht.

Die Ergebnisse übertrafen alle Erwartungen. Wir befinden uns nahe an den physikalischen Grenzen des TN5250-Protokolls.

Bisher wurde die Entscheidung der gesamten Bank veröffentlicht, und Kollegen aus anderen Städten haben sich der Verbesserung angeschlossen. Von den jüngsten Änderungen integrieren Kollegen die Lösung in Jenkins. In der Testversion wurde der Test des Starts auf einem Linux-Server mit Xvfb abgeschlossen und die Phase des Pilotbetriebs für die Ausführung von Autotests gestartet.

Vielen Dank für das Lesen bis zum Ende!
Alles Erfolg!

PS Im Dezember 2018 fand die nächste IBMi Developer Conference statt, auf der ein Bericht zum Thema dieses Artikels erstellt wurde.

Bisher haben wir die Konferenz jährlich nur für Bankangestellte abgehalten. Ab 2019 werden wir Teilnehmer aus anderen Unternehmen einladen. Es ist sehr interessant, den Kreis der beruflichen und persönlichen Kommunikation zu erweitern, Emotionen, Wissen und Erfahrungen auszutauschen.