Ideen zu Java-Agent über AJAX mit Sarissa gesucht

[Mark³]

Ich bastel gerade eine kleine Anwendung, die ein Notes-Formular im Browser (Intranet) darstellt und die Daten dann per Ajax mit Hilfe von Sarissa an einen Java-Agenten übergibt. Der führt eine Transaktion in einer Javaanwendung aus und gibt das Ergebnis der Transaktion an das aufrufende Javascript zurück, so dass ich es dem User wieder präsentieren kann.
Natürlich kann man statt Ajax einfach den Agenten über WebQuerySave starten aber ich finde Ajax irgendwie spannender.

Bislang klappt das schon ganz ordentlich, ich bin mir aber nicht sicher, wie meine Maske optimal mit dem Java-Agenten spricht. Bei WebQuerySave kann ich ja über DocumentContext alle Felder direkt ansprechen. Bei Ajax bekomme ich über den DocumentContext nur die CGI-Variablen der Seite, da der Agent ja nicht im Kontext meines Formulars läuft sondern über Ajax mit ?OpenAgent aufgerufen wird.
Momentan übergebe ich die Feldwerte händisch als String an den Agenten und zerlege diesen String im Agenten mit einem StringTokenizer wieder. Geht das irgendwie eleganter oder hat jemand mal ähnliches gemacht?

Vielleicht kann ich in der Notes-Maske mit Durchgangs-HTML eine weitere Form erzeugen, so dass die Feldinhalte automatisch über CGI zum Agenten gelangen können?

[flaite]

StringTokenizer gilt als sehr schlecht wg. Performance, weshalb dieser Mechanismus nach meinen Infos heute nur noch sehr selten eingesetzt wird. Ich schlag das mal genauer am WE nach und poste Ersatzcode.

ERst dachte ich, du könntest einfach die DocUnique ID übergeben, aber das Problem ist glaub ich, dass dieses Dokument noch gar nicht auf dem Server gespeichert ist. Zumindest nicht mit aktuellen User-Eingaben.

Weitere Form erzeugen geht glaub ich in dem Szenario irgendwie nicht.
Einfach aus dem Grund, dass es eben eine starke Abhängigkeit von DocumentContext im Agenten auf ein echtes Domino Dokument gibt. Zumindest ist mir da nix bekannt wie dies gehen könnte.

Du kannst im Java Agenten näherungsweise die Zeit stoppen mit der statischen Methode

Code

private long letzteZeit; 

private long stoppeZeit (String identifier) {
   long jetztZeit = System.currentTimeMilis();
   if (letzteZeit != 0) {
       System.out.println( identifier + (jetztZeit - letzteZeit) )
   }
  letzteZeit = jetztZeit; 
}

... oder mit Log4J, was ich aber auch noch nie mit einem Domino Agenten gemacht habe.

Ruf die Methode einfach an bestimmten Stellen im Code mit jeweils wiedererkennbaren identifier auf. Nimm als identifier einfach irgendwas. Nur zur Wiedererkennung.
So bekommst du eventuell raus, wie lange das Verarbeiten der einzelnen Schritte im Gesamtprozess des Agenten wirklich braucht.

Vielleicht kannst du auch mit XML arbeiten, wobei ich nicht glaube, dass das dadurch schneller wird. Vielleicht wiederverwendbarer.

Nach weiteren Überlegen erschliesst sich mir nicht so richtig wo bei deinem Anwendungsfall der Vorteil von Ajax liegt. Wirklich lange dürfte hier ja die Java Transaktion sein, oder? Und den bekommst du so ja nicht asynchron. Kenn aber natürlich die Umstände nicht so richtig.

Gruß Axel


 

[flaite]

Du könntest es mit der Domino Servlet Umgebung versuchen.
Die ist allerdings leider von vor der Sindflut.

[Mark³]

statt Log4J habe ich die geniale Log-Datenbank von OpenNTF eingebaut, funzt super.
Die Performance ist hier kein Problem, da die Transaktion (einen Servicecall anlegen in HP Openview) ein paar Sekunden dauert.
In Sarissa ist doch irgendwie die XML-Serializer-Geschichte drin (man merkt schnell, dass ich mir das noch nicht im Detail angeschaut habe ) aber da ich kein Dokument habe (ich speichere gar kein Dokument, SaveOptions=0) wird das wohl nicht hinhauen.
Einen Vorteil bekomme ich scheinbar nicht mit Ajax, aber ich sehe auch keine Nachteil. Ich kann mit ein paar Zeilen Code die Antwort des Java-Agenten auswerten und muss nicht ständig Seiten neu laden und Form processed-Formulare anpassen...

[flaite]

(man merkt schnell, dass ich mir das noch nicht im Detail angeschaut habe )

So mach ich das auch immer. 
Anders geht das glaub ich auch gar nicht.

aber da ich kein Dokument habe (ich speichere gar kein Dokument, SaveOptions=0) wird das wohl nicht hinhauen.

Wieviele Felder musst du denn an den Agenten übergeben? So viele dürften das doch gar nicht sein, wenn du kein ganzes Dokument speichern willst. Dann ist die Übergabe per http-get an den Agenten (Url-encoded) doch ok?

Einen Vorteil bekomme ich scheinbar nicht mit Ajax, aber ich sehe auch keine Nachteil. Ich kann mit ein paar Zeilen Code die Antwort des Java-Agenten auswerten und muss nicht ständig Seiten neu laden und Form processed-Formulare anpassen...

Ist auch ein Vorteil für den User, da er nicht immer das Flickern wegen der neu geladenen html Seite sieht.

Durch die Entkoppelung der Prozesse durch Ajax (Asynchron) gibts natürlich auch zusätzliche Schwierigkeiten.
1. Der Ajax call wird abgegeben.
2. Der User kann jetzt irgendetwas mit seinem Browser machen.
3. Der Server meldet an die Browserseite den Ajax-Call zurück.

2. gibt es bei normalen Web Request-Response so nicht.

In jedem Fall interessant.

Axel

[Mark³]

ein paar Antworten muss ich präzisieren, damit ich das verstehe:

Wieviele Felder musst du denn an den Agenten übergeben? So viele dürften das doch gar nicht sein, wenn du kein ganzes Dokument speichern willst. Dann ist die Übergabe per http-get an den Agenten (Url-encoded) doch ok?

Das sind so etwa 20 Felder. Ich übergebe das allerdings als http-post, nicht als get, ist das egal? Hier ist mein Code:

Code

function callAgent(strAgentName,urlparam) {
	pathname = window.location.pathname;
	hosturl=pathname.substring(0,(pathname.lastIndexOf('.nsf')+5))
	strUrl = hosturl + strAgentName + "?OpenAgent";
	var objHTTP = new XMLHttpRequest();
	pathname = window.location.pathname;
	hosturl=pathname.substring(0,(pathname.lastIndexOf('.nsf')+5))
	
	strUrl = hosturl + strAgentName + "?OpenAgent";
	objHTTP.open("POST", strUrl, false, "", "");
	objHTTP.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
	objHTTP.send(urlparam);
	resp = objHTTP.responseText;
	objHTTP = null;

return resp;

Die Felder übergebe ich als String im Parameter 'urlparam', ich werde evt. allen Feldern, die ich übergeben möchte, einen HTML-Tag zuweisen, so dass ich sie programmatisch mit Javascript übergeben kann und nicht bei jedem neuen Feld auf der Maske in den Code hüpfen muss. Vielleicht 'ID beginnt mit XY' oder sowas...

Durch die Entkoppelung der Prozesse durch Ajax (Asynchron) gibts natürlich auch zusätzliche Schwierigkeiten.
1. Der Ajax call wird abgegeben.
2. Der User kann jetzt irgendetwas mit seinem Browser machen.
3. Der Server meldet an die Browserseite den Ajax-Call zurück.

2. gibt es bei normalen Web Request-Response so nicht.

Momentan führe ich den Befehl synchron aus (Parameter in objHTTP.open), ich weiss nicht, ob es Vorteile bringt, das asynchron zu machen. Das müsste so laufen (aus der Sarissa-Hilfe):

Code

xmlhttp.onreadystatechange = function()
{
	if(xmlhttp.readyState == 4)
		alert("Finished loading!");
}

[flaite]

Ich würde auf jeden Fall eine private function bauen, die die Feld-Wert Mappings als eine Art Map zurückgibt. Falls es das in JavaScript gibt. Sonst multidimensionaler Array.

Wenn du das nicht asynchron machst?
Ist der Browser dann für die 8 Sekunden blockiert, wenn der Call vom Server verarbeitet wird?
Asynchron bringt aus meiner Sicht nur neue Komplexitäten. Eigentlich heisst das, dass der Client während der Call-Verarbeitung machen kann, was er will. Das verringert dann natürlich die Kontrolle. Und das ist vermutlich kostspieliger als der Nutzen, den der Client von diesen 8 Sekunden Freiheit hat.

[Mark³]

nach einigen asynchronen Tests mache ich das nun wieder synchron, ist für den User irgendwie verständlicher, dauert auch nur 2-3 Sekunden.
Die Feldübergabe mache ich ja über das CGI-Feld REQUEST_CONTENT (wie groß darf das wohl sein?), den String erzeuge ich automatisch, indem ich den einzelnen Notes-Feldern unter den Eigenschaften HTML-Other ein neues Attribut zuweise, das auch den Klartextnamen des Felds beinhaltet. Dabei bin ich auf eine nervige Cross-Browser-Problematik gestossen:

Die Existenz des Feldes wollte ich mit

Code

if (form.elements[i].Attributname) 

testen. Leider klappt das nur im IE. Auch der Test mit

Code

typeof form.elements[i].Attributname != 'undefined'

klappte nur im IE. Die Lösung ist

Code

if (form.elements[i].getAttribute(Attributname)!= null) 

, dies klappt sowohl im IE als auch in FireFox   
Das wird lustig, wenn im IBM Workplace erstmal alle in Javascript programmieren müssen 

Die Stringzerlegung im Agenten (also in Java) habe ich noch nicht drin, auf jeden Fall muss ich wohl aus einem  String (ich habe ja nur das Feld REQUEST_CONTENT) wieder ein Array machen, das ist ja nicht kompliziert.
Sarissa bietet ja auch Methoden an, um beliebige Dokumente in XML zu konvertieren (Methode xmlize) aber ich denke, hier alles mit XML zu machen ist hier wohl 'übermäßige Vernichtung (mit Atombombe)' 

[flaite]

Das wird lustig, wenn im IBM Workplace erstmal alle in Javascript programmieren müssen 

Soweit ich das verstehe ist das ja dann kein browserspezifisches Java Script. Sondern IBM nimmt das als serverseitige Skriptsprache. Das dürfte dann vereinheitlicht sein.

ich glaub du wirst in den Feldern nicht an Begrenzungen stossen.

Ansonsten: 

Falls dich das interessiert. Du kannst bei Manning.com jetzt das ajax Buch wo Eric Pascarello von Javaranch mitschreibt, als Early Access PDF-Version bekommen. Die arbeiten noch dran, aber man kann sich immer schon mal runterladen was da ist. Natürlich auch später, wenn die fertig sind.