Java-Anwendung mit einer Delphi-Anwendung fernsteuern

[Papaschlumpf73]

Liebe Delphi-Gemeinde,

bei meinen Kunden läuft eine VCL-Anwendung und generiert Daten, welche die Anwender (mühevoll und zeitaufwendig) manuell in eine Java-Anwendung eines anderen Anbieters übertragen müssen.

In der Java-Anwendung öffnet der Anwender einen Dialog über das Hauptmenü, trägt dort ein Datum und einen Betrag ein, wählt einen Eintrag aus einer ComboBox aus und klickt auf „Speichern“.

Der andere Anbieter ist (vorsichtig ausgedrückt) sehr zurückhaltend, wenn es um entsprechende Schnittstellen geht. An den Quellcode der Java-Anwendung komme ich auch nicht heran und der direkte Zugriff auf die dahinterliegende Datenbank ist tabu.

Welche Möglichkeiten seht Ihr, diesen Vorgang aus der Delphi-Anwendung heraus zu automatisieren? Und bevor Ihr mich in der Luft zerreißt: Ich habe keine Ahnung von Java.

[Der schöne Günther]

Anmerkung: Ich persönlich würde mich hüten die Notlösung "Fremde GUI fernsteuern" zu wählen und dann wahrscheinlich für die Eingaben deines Programms zu haften. Da muss doch nur der "andere Anbeiter" einmal was an seiner Oberfläche ändern und dein Programm macht entweder nichts mehr oder gibt - noch schlimmer - Dinge falsch ein.

[Luckie]

Wird schwierig werden, da GUI Java Programme ihre Steuerelemente selber zeichnen und sie somit kein Windows Handle besitzen, welches man zur Identifizierung nützen könnte, um Nachrichten an das betreffende Steuerelement zu schicken.

Gibt es keine Importschnittstelle oder eine API für das Java Programm?

[Sherlock]

Lass es bleiben. Nenn das Kind beim Namen (unkooperativer Dritthersteller) und verbrenn Dir nicht die Finger (Geld und Zeit in etwas stecken, das nach einer kleinen GUI-Änderung nicht mehr geht) an so einer Sache.

Sherlock

[Papaschlumpf73]

Die Versionskontrolle und Fernsteuerung einer reinen Windows-Anwendung würde ich problemlos hinbekommen. Nur bei Java ist eben alles anders. Es muss auch nicht zwangsläufig eine GUI-Fernsteuerung sein. Ich wollte nur den bisherigen Arbeitsablauf verdeutlichen.

Es gibt definitiv keine Importschnittstelle. Ob APIs vorhanden sind, weiß ich nicht. Wie gesagt, dieser Anbieter ist nicht besonders kooperativ. Gibt es denn eine Möglichkeit, eine Liste der APIs und Parameter aus einer Java-Anwendung auszulesen?

[Union]

Nicht nur das, du kannst das ganze auch refaktorieren, dafür gibt es diverse Tools.

[Papaschlumpf73]

Ich habe ca. 20 Kunden, die jeweils ca. 25.000 Euro pro Jahr an Personalkosten für diese manuelle Erfassung ausgeben müssen. Das sind insgesamt 500 TDE pro Jahr.

So schnell möchte ich das Thema daher noch nicht fallen lassen. Ich habe sehr kooperative Kunden, die jede neue Version der Java-Anwendung zunächst in einer Testumgebung ausprobieren.

Vielleicht hat ja noch jemand eine zündende Idee?

[Blup]

Wenn der Anbieter keine Importschnittstelle vorgesehen hat, hat das sicher auch einen Grund.
Man sollte so etwas über die Benutzeroberfläche eigentlich nicht tun.
Deshalb würde ich, wenn das nicht zu vermeiden ist, ein zusätzliches Exportprogramm nur für diesen Anwendungsfall erstellen.
Mit eigenene Nutzungsbedingungen und Haftungsbeschränkung.

Das Problem hat aber nichts mit der jeweiligen Programmiersprache zu tun.
Ein Weg wäre Fensterhandle über die Windows-API zu ermitteln und die Anwendung per Windows-Botschaften zu steuern.
Dafür fehlen dir aber vermutlich die notwendigen Kenntnisse, sonst würdest du die Frage anders formulieren.
Du könntest aber aus deinen Daten ein Tastenmacro bilden und die Steuerung einem geeigneten Player überlassen.
Vieleicht ist da etwas geeignetes mit entsprechender Doku der Makrodatei dabei:
https://www.heise.de/download/produc...ftware/makros/

[Papaschlumpf73]

Zitat:

Zitat von Blup (Beitrag 1349038)

Wenn der Anbieter keine Importschnittstelle vorgesehen hat, hat das sicher auch einen Grund.

Na klar: Der Anbieter will eine schlechte Kopie meiner Software als eigenes Modul verkaufen.

Zitat:

Zitat von Blup (Beitrag 1349038)

Das Problem hat aber nichts mit der jeweiligen Programmiersprache zu tun.

Das sehe ich etwas anders - wie auch Luckie - In einer Windows-Anwendung hat (fast) jedes Control ein Handle, welches ich auslesen, überwachen und fernsteuern kann. Bei Java-Anwendungen jedoch nicht. Macro-Aufzeichnungen oder SendKeys sind mir dann doch etwas zu gefährlich.

[mkinzler]

Es ist nur fraglich, ob das Javaprogramm überhaupt Windows-Controls verwendet.

http://www.delphipraxis.net/15388-wi...6-09-08-a.html

[Papaschlumpf73]

Zitat:

Zitat von mkinzler (Beitrag 1349040)

Es ist nur fraglich, ob das Javaprogramm überhaupt Windows-Controls verwendet.

Die verwenden sie definitiv nicht.

[Zacherl]

Du kannst "theoretisch" das Java Programm dekompilieren, dir eine eigene Schnittstelle einbauen und das Tool dann wieder neu kompilieren. Ob das rechtlich in Ordnung ist, weiß ich allerdings nicht (vermutlich eher weniger) und bei Updates der Software müsstest du das ganze Spielchen von vorne anfangen.

[uligerhardt]

Ich kenn mich da ja nicht aus, aber könnte nicht was mit Accessability gehen?

[Benedikt Magnus]

Zitat:

Zitat von Zacherl (Beitrag 1349046)

Du kannst "theoretisch" das Java Programm dekompilieren, dir eine eigene Schnittstelle einbauen und das Tool dann wieder neu kompilieren. Ob das rechtlich in Ordnung ist, weiß ich allerdings nicht (vermutlich eher weniger) und bei Updates der Software müsstest du das ganze Spielchen von vorne anfangen.

Das war auch mein erster Gedanke, und funktionier bei Java auch ziemlich gut, ist aber rechtlich absolut verboten. Und wenn der Entwickler des Programms davon Wind bekommt (er scheint ja offensichtlich wenig Interesse an einer Kooperation zu haben) könnte das ziemlich haarig werden.

Zitat:

Zitat von Papaschlumpf73

Ich habe ca. 20 Kunden, die jeweils ca. 25.000 Euro pro Jahr an Personalkosten für diese manuelle Erfassung ausgeben müssen. Das sind insgesamt 500 TDE pro Jahr.

Zitat:

Zitat von Papaschlumpf73

Na klar: Der Anbieter will eine schlechte Kopie meiner Software als eigenes Modul verkaufen.

Da kam mir gleich die Frage in den Sinn: Wie komplex ist das entsprechende Javaprogramm bzw. wie umfangreich die entsprechend benötigten Funktionen? Je nachdem könnte es sich lohnen, den Spieß umzudrehen und Besagtes einfach direkt in dein Programm einzubauen.

[Papaschlumpf73]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1349059)

Da kam mir gleich die Frage in den Sinn: Wie komplex ist das entsprechende Javaprogramm bzw. wie umfangreich die entsprechend benötigten Funktionen? Je nachdem könnte es sich lohnen, den Spieß umzudrehen und Besagtes einfach direkt in dein Programm einzubauen.

Das wäre echt cool. Leider ist die Java-Anwendung riesig. Da arbeiten ca. 120 Entwickler seit über 15 Jahren dran... Bei denen im Quellcode würde ich auch nicht rumpfuschen.

[HolgerX]

Ich denke, da Du die JAVA-Anwendung weder fernsteuern, noch verändern kannst, geht eine automatische Datenübermittlung nur direkt mit der Datenbank.

Nach dem Prinzip arbeiten auch einige unserer Kunden, da die andere Software keine Schnittstelle hat, werden exportierte Daten von uns direkt in die andere Datenbank geschrieben. Dies erfolgt jedoch durch eine spezielle Datenkonvertierungssoftware und wird durch die Kunden-IT programmiert.

[Hisoka]

Zitat:

Zitat von HolgerX (Beitrag 1349074)

Ich denke, da Du die JAVA-Anwendung weder fernsteuern, noch verändern kannst, geht eine automatische Datenübermittlung nur direkt mit der Datenbank.

Nach dem Prinzip arbeiten auch einige unserer Kunden, da die andere Software keine Schnittstelle hat, werden exportierte Daten von uns direkt in die andere Datenbank geschrieben. Dies erfolgt jedoch durch eine spezielle Datenkonvertierungssoftware und wird durch die Kunden-IT programmiert.

Da wäre ich aber vorsichtig, denn der Kunde kann durch solche Aktionen jeden Anspruch auf Wartung verlieren. Dies könnte für den Kunden böse enden.

Denn als "Hersteller" einer solchen komplexen Anwendung würde ich natürlich keine Garantie übernehmen, dass die Anwendung in einem solchen Falle funktioniert.

Würde doch eher versuchen einen Kontakt zu dem Hersteller aufzubauen.

[mensch72]

Das mit dem "FernSteuern" von fremden Anwendungen ist bei uns seit Jahren Bestanddteil unserer Arbeit.
Im semiprofessionellen Finanzsektor gibt es zahlreiche Anbieter von guten Detaillösungen, aber wenn ein Anwender (s)einen optimierten Workflow will, scheitert dies da quasi immer an nicht vorhandenen APIs oder Schnittstellen. Rechtlich ist das vom Sicherheitskonzept da sogar oft garnicht möglich, sowas "offen" zu realisieren.

1. Wir verifizieren optisch jede GUI Aktion per Screenshot, welcher jeweils intern per HASH über konstante Punkte validiert wird... bei erkannten Unstimmigkeiten oder Abweichungen(z.B. GUI Änderungen des Fremdsystems) stoppt unsere Fernsteuerung von selbst und protokolliert/dokumentiert die Abweichung
2. Wir arbeiten immer mit einer Kombination aus Hard&Software, wenn wir etwas fernsteuern(heist wir haben eine kleine BOX, welche 2 USB Schnittstellen hat und sich auf einer per simulierter "HDI Mouse/Tastatur Kombi" völlig transparent als zweit Tastatur+Maus im System absolut unbemerkbar für Fremdsoftware verhält)
3. Wir klären mit dem Anwender, das er unser Tool nur auf eigene Verantwortung einsetzen kann. (er hat selbst ja auch das Risiko das bei einer stupiden Datenerfassung der Bediener der Fremdsoftware rein menschlich ein paar Eingabefehler macht, neben den Kosten der Arbeitszeit die er dafür braucht)
4. Unsere Anwender bestätigen uns neben den Kostenvorteilen auch eine geringere Fehlerquote bei wenigen Fehlalarmen oder Abbrüchen wegen erkannter/nicht erkannter GUI/Umgebungsveränderungen
5. Unsere Anwender testen stets selbst zuerst manuell eine Basisversion, "die alles einträgt", aber die "speichern" Funktion noch nicht selbst auslöst... erst wenn das klappt, schaltet der Anwender selbst die "Vollautomatisierung" auf eigenes Risiko frei, die dann solange arbeitet bis eine Unstimmigkeit erkannt wird, ober der Anwender sie selbst wieder deaktiviert


-> auch wenn andere davon strikt abraten... wir machen es und gehen dabei auch mal in den Graubereich bis an die Grenze der rechtlich vertretbaren Funktionalität... Man darf viele fremde Programme/Services laut AGB der Fremdanbieter garnicht automatisiert nutzen oder da Daten abgreifen. Das ist aber nicht unser Problem, wenn ein Kunde von uns eine Automatisierungslösung für was auch immer will, dann bekommt er die auch. Wir haben schon mit kleinen Magneten echte Tasten an Fremdgeräten/Maschinen automatisiert gedrückt... wenn der Kunde zahlt weil er viel spart oder etwas will was er sonst nicht bekommt, dann ist sehr viel möglich.
-> wir arbeiten/bleiben bei Fremddaten stets sauber getrennt... wir greifen schreibend niemals Fremddatenquellen per Software direkt an(rein lesende Checks, als LOG-Funktion sind möglich)
-> wir hacken keine Fremdsoftware, wir machen bewußt niemals mehr wie das was ein normaler Anwender manuell auch tun könnte, nur eben automatisiert und wenn möglich etwas schneller


Genauer kann ich auf diesen Teil unserer Arbeit leider nicht eingehen, denn man macht sich mit sowas eventuell auch etwas unbeliebt... bzw. Kunden, welche auf eigenes Risiko bewusst gegen die AGB von anderen Anbietern verstoßen könnten von diesen belangt werden. Es werden auch 100W Lampen für Autoscheinwerfer für Rennzwecke entwickelt und an "jeden" verkauft, nur im Staßenverkehr darf man die nicht einsetzen, weil sonst die Betriebserlaubnis erlischt (so wie die Nutzungslizenz von Fremdsoftware eventuell erlischt, wenn man da was vom Anbieter ungewollt "fernsteuert"...)


=> also, ja es geht, man kann per Delphi entweder rein per Software oder besser per echter USB HDI Simulation ALLES fernsteuern, egal ob in JAVA oder was auch immer programmiert... bei Sachen mit WinAPI-GUI ist nur die Verifikation eventuell einfacher, wenn man sich in die Windows-Messages per "Hook" einhängt... wir machen das nicht und setzen immer auf unsere universelle grafische Verifikation mit einer Kombination aus OCR & Matrix Datenvergleich

[Papaschlumpf73]

Zitat:

Zitat von mensch72 (Beitrag 1349103)

2. Wir arbeiten immer mit einer Kombination aus Hard&Software, wenn wir etwas fernsteuern(heist wir haben eine kleine BOX, welche 2 USB Schnittstellen hat und sich auf einer per simulierter "HDI Mouse/Tastatur Kombi" völlig transparent als zweit Tastatur+Maus im System absolut unbemerkbar für Fremdsoftware verhält)

Vielen Dank für die ausführlichen Informationen. Das scheint ein gangbarer (wenn auch etwas aufwendiger) Weg zu sein. Eines habe ich jedoch nicht ganz verstanden: Welchen Vorteil bietet die kleine USB-Box im Gegensatz zu einer reinen Software-Lösung?

[mensch72]

..."Welchen Vorteil bietet die kleine USB-Box im Gegensatz zu einer reinen Software-Lösung? "...

Wir haben schlechte Erfahrungen mit Fehlalarmen von Sicherheitssoftware, wenn wie mit "tiefen Hooks" uns in Maus und Tastatur einklinken, um da vernüftig zu arbeiten.
Wir kennen auch einige Programme, die es selbst nicht mögen, wenn Eingaben ohne reale Maus & Tastatur Aktionen erkannt werden, bzw. die selbst schon mit Hooks arbeiten.

Da ist der Aufwand mit 2 Microcontrolern wo einer Maus&Tastatur als HDI emuliert und der andere per USB eine serielle Schnittstelle emuliert, auf mit der wir dann beliebiges einfach ausgeben, was als Maus oder Tastaturdaten dann im Windows wieder ankommt. Und wenn es ganz hart kommt und der zu steuernde PC so geschützt ist, das man da noch nichtmal ein eigenes Programm und USB Treiber installieren kann, dann geht mit so einer Boxlösung und optischer Kammera nach unserer Methode sogar die Fernsteuerung per 2. PC ganz ohne Softwareverbindung.

Es ist immer eine Frage des zu überwindeneden Sicherehitslevels, wieviel Aufwand man dafür benötigt. Da es unser Konzept hergibt, machen wir es auch wenn es sein muss und jemand in seinen AirGap Rechnerverbund z.B. gar keine fremde Software duldet... dann dann funktioniert unsere USB-HDI Emulation mit optischer Rückkopplung immernoch. Für eine 0815 WaWi Kopplung ist es mit Kanonen auf Spatzen geschossen, aber wenn es alles an/auf einem PC läuft der Sicherheit gegen Software mit tiefen Hooks auch nicht abträglich.

[Papaschlumpf73]

Danke, jetzt hab ich es auch gerafft. In unserem Umfeld geht es glücklicherweise nicht ganz so sicher zu, so dass eine reine Softwarelösung ausreichen sollte. (hoffentlich...)