Konsumieren eines Webservices mittels LotusScript über einen Java-Consumer

[Mitch]

Hallo zusammen,

ich möchte einen Webservice (adhoc) konsumieren den ein Kunde bereitstellt. Dieser ist mittels UsernameToken geschützt.

Diese Informationen werden im SOAP-Header des Requests mitgeschickt, und - korrigiert mich wenn ich falsch liege - man kann den Header nur über einen Java-Webservice-Consumer manipulieren (SetCredentials reicht zumindest nicht aus). Ich habe dazu das hier gefunden: http://enerosweb.wordpress.com/2010/07/28/lotusdomino-8-5-webservice-consumer-manipulating-soap-header/

Jetzt benötige ich die Rückgabe des Webservices aber in meiner bestehenden Anwendung - und die ist in LotusScript geschrieben.

Daher versuche ich die generierte Java-Bibliothek mittels LS2J anzusprechen, scheitere aber bereits beim Erstellen des WS-Objektes.

Ich gehe wie folgt vor:

Code

Dim jSession As JavaSession
Dim jClass As JavaClass
Dim jWS As JavaObject

Set jSession = New JavaSession ()
	
Set jClass = jSession.GetClass("com.kundenname.anwendungsname.B_XXXXX_BindingStub")
Set jWS = jClass.CreateObject

Das resultiert aber in einem Java-Fehler:
java.lang.NoSuchMethodError: com/kundenname/anwendungsname.B_XXXXX_BindingStub.<init>()V.

Okay, die Klasse scheint ja auch Parameter zu benötigen:

Code

public B_XXXXX_BindingStub(java.net.URL endpointURL, javax.xml.rpc.Service service) throws lotus.domino.types.Fault {
         super(endpointURL, service);
    }

Mein Code müsste also so aussehen:

Code

(...)
Set jWS = jClass.CreateObject("(Ljava/net/URL;Ljavax/xml/rpc/Service;)V", jURL, jService)

Also habe ich versucht mir (ebenfalls über LS2J) die Parameter zu erstellen. jURL habe ich geschafft, aber bei bei jService finde ich auf teufel-komm-raus nicht die benötigten Parameter zum Initialisieren. Die Service-Klasse hat aber, wenn ich das richtig sehe, auch einen leeren Konstruktor: http://ws.apache.org/axis/java/apiDocs/org/apache/axis/client/Service.html

Aber damit laufe ich wieder in den gleichen Fehler wie oben.

Fragen:

1) Kennt jemand einen besseren Weg um mein eigentliches Vorhaben zu lösen (ansprechen eines via UsernameToken geschützten Webservice aus einem bestehenden, umfangreich mit LS geskripteten Systems)?

2) Weiß jemand wie ich die Binding-Klasse via LS2J initialisieren kann?

3) Sonstige Anmerkungen?  

Beste Grüße,

Mitch

[Mitch]

So, falls hier mal jemand auf ähnliche Probleme stoßen sollte:

Ich bin zwar etwas weiter gekommen - man muss die XXXXLocator Klasse verwenden und kommt dann darüber (theoretisch) an alles andere.

Aber das resultiert leider in einem Fehler:

lotus.domino.axis.ConfigurationException: No engine configuration file - aborting!

Und mit dieser Fehlermeldung findet man dann auch ein offizielles IBM Statement:

http://www-304.ibm.com/support/docview.wss?uid=swg1LO42772

Dort steht, kurz gesagt, Java-Webservice-Consumer mittels LS2J ansprechen geht nicht und wird niemals gehen.

Es ist als Bug eingestuft, der aber nicht gefixt werden wird, sondern als Einschränkung bestehen bleibt.

Austricksen lässt sich das leider scheinbar auch nicht, ich hatte versucht mir eine eigene Java-Klasse zu schreiben, die den Java-Consumer anspricht und diese dann via LS2J einzubinden, aber das resultiert in gleichem Fehler.

Ich werde wohl größere Teile der Anwendung umschreiben müssen.

Gruß,

Mitch

[Ralf_M_Petter]

Ich verstehe jetzt das Problem noch nicht ganz. Warum packst du den Aufruf des Java Webservice Consumer nicht einfach in einen Java Agenten. Diesen Agenten kannst du dann von Lotusscript problemlos aufrufen. Für etwaige Parameterübergaben mache ich es immer so, dass ich ein Dokument erstelle in dem ich die Aufrufparameter reinschreibe und die NoteID dieses Dokuments an den Javaagenten übergebe. Dieser liest dann die Parameter aus dem Notesdokument und schreibt das Ergebnis wieder zurück. Dann kann der rufende Lotusscript Code die Daten aus dem Dokument auslesen.

Funktioniert in meinen Anwendungen prima. In Notes muss man halt oft einfach etwas seltsame Wege beschreiten, obwohl etwas auch sehr einfach gehen könnte.

[m3]

Ich verstehe jetzt das Problem noch nicht ganz. Warum packst du den Aufruf des Java Webservice Consumer nicht einfach in einen Java Agenten. Diesen Agenten kannst du dann von Lotusscript problemlos aufrufen. Für etwaige Parameterübergaben mache ich es immer so, dass ich ein Dokument erstelle in dem ich die Aufrufparameter reinschreibe und die NoteID dieses Dokuments an den Javaagenten übergebe. Dieser liest dann die Parameter aus dem Notesdokument und schreibt das Ergebnis wieder zurück. Dann kann der rufende Lotusscript Code die Daten aus dem Dokument auslesen.

Funktioniert in meinen Anwendungen prima. In Notes muss man halt oft einfach etwas seltsame Wege beschreiten, obwohl etwas auch sehr einfach gehen könnte.

Performant ist anders ...

[Ralf_M_Petter]

Performant ist anders ...

Hast du es schon einmal probiert. Wir verwenden diese Agentlösung um Dialogboxen die mit Javaswing programmiert sind aufzurufen. Wenn man auf den Button in der Notesmaske drückt ist praktisch (<0,5 sec) sofort die Dialogbox da. Also so unperformant ist das nicht.

Grüße

Ralf

[m3]

Das glaub ich dir schon. Ich denke da eher an gleichzeitige, serverbasierte Agents, die getriggert laufen. Ich bezweifle, dass das gut skaliert. Aber wenn es fuer den Anwendungsfall passt ist es ja gut.

[Mitch]

Hallo Ralf,

danke, den Umweg über Dokumente halte ich mal im Hinterkopf, ich bin aber eigentlich kein Freund temporärer Dokumente. Müsste ich das Dokument nicht sogar speichern um von den verschiedenen Elementen darauf zugreifen zu können? Und dann wieder löschen?

Da produziere ich ja haufenweise Deletionstubs, die Abfrage wird sicher einige hundert Male am Tag verwendet werden...

Momentan überlege ich einen eigenen Webservice zu schreiben, der den Kundenwebservice aufruft. Die Header/UsernameToken-Geschichte habe ich bereits in den Java-Consumer geschoben, d.h. meiner wird ganz flach ausfallen und ich könnte ihn daher mit LS ansprechen.

Aber da habe ich sowohl Performance-Bedenken (der erste Aufrauf eines WS dauert bei mir immer ein/zwei Sekunden, danach fluppts dann aber) als auch die Befürchtung, dass die Kundenseite, auf deren Servern meine Anwendung liegt, keinen fremden WS haben will, insbesondere da wir mit Personaldaten hantieren. Zugriffseinschränkung wäre zwar eigentlich kein Problem, aber der Kunde ist da sehr "sensibel".

Gruß,

Mitch

[Ralf_M_Petter]

Ja du musst das Dokument speichern. Das muss aber natürlich nicht in der eigentlichen Datenbank sein, sondern kann auch eine eigene Datenbank für temporäre Dokumente sein.

[Peter Klett]

Du musst die Dokumente danach auch nicht löschen, sondern verwendest die immer wieder. Falls nur ein Aufruf gleichzeitig möglich ist, hast Du immer nur ein Dokument dafür, dass Du mit neuen Inhalten füllst. Könnten die Aufrufe kollidieren, setzt Du z.B. einen Status in das Dokument. Bei einem neuen Aufruf suchst Du ein beliebiges Dokument mit Status inaktiv. Findest Du keines, erstellst Du eines. Auf jeden Fall hast Du dann ein Dokument, setzt den Status auf aktiv, führst die Aufgabe aus und setzt den Status wieder auf inaktiv. So hast Du dann einen Pool von Dokumenten, die Du recycelst. Damit umgehst Du die Deletionstubs.

[Mitch]

Hey Peter, das ist natürlich auch eine Möglichkeit. Ich werde mal verschiedene Ansätze testen.


Übrigens habe ich gerade festgestellt, dass folgende Info nicht ganz korrekt/etwas irreführend ist:

Und mit dieser Fehlermeldung findet man dann auch ein offizielles IBM Statement:

http://www-304.ibm.com/support/docview.wss?uid=swg1LO42772

Dort steht, kurz gesagt, Java-Webservice-Consumer mittels LS2J ansprechen geht nicht und wird niemals gehen.

Es ist als Bug eingestuft, der aber nicht gefixt werden wird, sondern als Einschränkung bestehen bleibt.

In 8.5.3 (FP1) funktioniert das nämlich wunderbar. Haben sie wohl doch gefixt. Allerdings scheint das im Allgemeinen keine so saubere Geschichte zu sein, denn auch unter 8.5 gibt es wohl u.U. Probleme (http://www-304.ibm.com/support/docview.wss?uid=swg21431059) und die Empfehlung lautet auch hier: Kein LS2J verwenden...

Gruß,

Mitch