Launch the Domino Designer from Eclipse to debug your custom Designer extensions.

Cameron Gregor asked me in a comment whether it is possible to launch the Domino Designer from eclipse in the same way like the Notes client and the answer is yes this is possible. In this post i will describe what you have to change in your existing notes launch config to start the Designer from eclipse. This enables you to debug Extensions for the designer or XPages. To follow the steps you need a working Notes plugin target and a launch config for the notes client. If you need help with this you can learn how to do this in my tutorial "How to configure Eclipse 4.3 to develop plugins for Notes Part 1 and Part2".


The goal is to have a full working Domino Designer, launched in Debug mode from eclipse.

The first step is go to your eclipse and open the "Debug Configurations" dialog.

In there duplicate your existing notes launch config.

Then change the Name and the "run a product" field to Domino Designer and com.ibm.designer.domino.product.dde.

Switch to the "Arguments" Tab and change the Program arguments to

-vm ${rcp.home}/../jvm/bin\j9vm\jvm.dll
-personality com.ibm.designer.domino.personality
-product com.ibm.designer.domino.product.dde
-debug
-console
-nl en_US

Save your changes with the "Apply" button. Then click the debug button to launch Designer. Be sure that you have no open instance of Notes/Designer because only one instance can be open at the same time.

When everything works, you will get a designer window with a welcome screen. To close the welcome screen, choose "Close Perspective" from the Window menu.

Then you should see your normal Designer UI. Maybe you get many error message in the Problem view that some Java elements cannot be resolved. No problem we will fix this in the next step. 

Open the Preferences of Designer and navigate to "Plug-in Development" -> Target Platform. Change the location from "NotesProgDir\framework\eclipse" to "NotesProgDir\framework\rcp\eclipse". Click Apply and "Ok". Eclipse will reload the target platform.

After reload all error message will be solved automatically in the background. Now you can try or debug your extensions in  Designer.

Open mail database of the session user in Java

In many Notes/Domino Applications you have to work with the mail file of the user. In Lotus script it is very easy to open the mail file of the session user.

Dim mailDB As New NotesDatabase( "", "" )
Call mailDB.OpenMail

Unfortunately the OpenMail method is not available in Java. As a workaround you can get the mail database of the session user from the DBDirectory.

Database mailDB = ses.getDbDirectory(null).openMailDatabase();

ses should be a valid Notes Session Object.

Lotus Notes 9 final is available in passport advantage

I am so excited that Lotus Notes 9 is available. Now i am downloading the code and will post what has changed since the public beta later today.

The product codes for the most important downloads are:

IBM Notes, Domino Designer and Admin V9.0 for Windows XP,Vista and Windows 7 32 Bit English(CIB9AEN)

IBM Notes Client V9.0 for Windows English(CIB8LEN)

IBM Notes Client V9.0 for Mac English(CIB8PEN)

IBM Notes Client V9.0 for Linux (RPM Install) English(CIB8MEN)

IBM Notes Client V9.0 for Linux (Debian Install) English(CIB8NEN)

IBM Notes Traveler V9.0 for Windows Multilingual(CIB95ML)

IBM Domino Sever V9.0 64 bit for Windows English(CIBM1EN)

IBM Domino Sever V9.0 32 Bit for Windows English(CIBM0EN) 

Very cool! Conditional breakpoints in the SSJS Debugger

I blogged about the new SSJS Debugger in Designer 9 and how to use it to find bugs in your java script code some weeks ago. And today i want do show you how to use conditional breakpoints in the new debugger.

Every developer knows that it is very annoying when you have a problem in a loop which occurs only in a particular iteration. So you have to step through the loop many times only to get to the faulty iteration. And when you click step over one time to often you can start from the beginning. Look at the following example:

var view=session.getCurrentDatabase().getView("Employees");
var doc=view.getFirstDocument();
var money=0;
while(doc!=null){
 money=money+100/doc.getItemValueDouble("value");
 doc=view.getNextDocument(doc);
}
getComponent("result").setValue(money);

We are looping through a view and make a litte calculation. When we run this example we get a value of "inifinty". So we are pretty sure that on one iteration there is a Division by zero. But the big question is which document contains the zero value? So we can step through the whole loop to find the doc which contains a zero vale or define a conditional breakpoint.

1. Go to the source tab of your xPage.
2. Left click the breakpoint area left of the line numbers to define a breakpoint.
3. Right click the new breakpoint and select "Breakpoint Properties"

4. Define the condition when your breakpoint should stop the script execution

After the condition is set the SSJS Debugger will stop the script execution every time the code where the break point is defined is executed and the condition is true. In our example stops the execution when doc.getItemValueDouble("value") is 0. When the Execution stops you can find out with the expressions view which document is causing the error. For example you can get with doc.getUniversalID() the UNID from the document with the 0 value.

Condtional breakpoints are a very valuable tool to find bugs in complex SSJS code.

Reference to all my posts about the SSJS Debugger

How to activate and use the expressions view in the SSJS debugger

The "expressions" view in the java debugger is one of the most valuable tool for debugging java code. With this view you can deeply inspect the values of all objects you are using in your code at runtime and you can even run methods on this object to get values not visible in the standard "variables" view. For example when you have a document object you can invoke getItemValueString on this object to get the value of a field from the document. Knowing this you will understand my disappointment when i first try the SSJS Debugger in Desinger 9, because it looks like there is no expression view in the java script debugger. But fortunately the view is only hidden and can be activated in Designer 9.

Go to the "Window->Show Eclipse View" menu and activate the "expressions" view.

After that we can use the expressions view to analyze the state of all objects available in our code when the execution is stopped at a breakpoint in the debugger.

For example we have the following serverside java script code in our xPage.

 

var view=session.getCurrentDatabase().getView("Employees");
var doc=view.getFirstDocument();
var money=0;
while(doc!=null){
 money=money+100/doc.getItemValueDouble("value");
 doc=view.getNextDocument(doc);
}
getComponent("result").setValue(money);

The following screenshot shows what is possible with the expressions view in SSJS Debugger at a brekpoint inside the loop.

You can access every field from the doc Object with getItemValueString() or every java script variable. You can get every information from the session, for example the effective username running this script. From the session you can acces databases and from the databases you cann acess views and so on and on. The possibilitys are endless.

To add, change or remove expressions in the expression view simply right click the view and select the appropriate menu action. Or use the actions in the toolbar. When you hove over a toolbar icon you get a simple description of the action.

So i hope IBM will activate the expressions view by default in future service packs of Designer 9 so that every xPage developer knows about this great tool. A right click Option "Watch this expression" in the source editor would be nice too.

Reference to all my posts about the SSJS Debugger

Erste Schritte mit der Rest API von Lotus Domino

Im letzten Post habe ich gezeigt, wie einfach es ist die REST Api für einen Domino Server zu aktivieren. Jetzt möchte ich zeigen wie man die API ohne ein Programm zu schreiben testen kann und erste Erfahrungen mit der Syntax der RESTurls gewinnen kann.

Dafür erscheint mir die RESTClient Extension für den Firefox am besten geeignet. Diese Extension kann auf Knopfdruck zum Firefox hinzugefügt. werden.

Nach einem Neustart des Firefox ist der RESTClient im Browser verfügbar. Der Knopf für den RestClient befindet sich ganz rechts in der Adresszeile.

In der UI des RESTClient kann man dann seine Zugriffsmethode, die URL und bei Bedarf auch Daten im Body mitschicken.

Wie sehen nun aber die URLs für den Zugriff auf Domino Daten aus. Hier ein paar Beispiele:

Erstellen einer Liste sämtlicher Datenbanken auf dem Domino Server:

http://localhost:80/api/data

Zugriff auf den Inhalt einer View:

http://localhost:80/test.nsf/api/data/collections/name/Adressen

test.nsf ist der Datenbankname und Adressen der Ansichtsname der zurückgegeben werden soll.

Zugriff auf ein Dokument mit einer bestimmten UNID:

http://localhost:80/test.nsf/api/data/documents/unid/9721E84AF9E25C4AC1257AE200598E50

Nach dem man im RESTClient dann auf den "SEND" Knopf gedrückt hat, werden einem die Ergebnisse der Abfrage unten angezeigt. Im Reiter "Response Headers" sieht man die HTTP Headers. Im Response Body sieht man das zurückgegebene JSON Dokument, dass die angeforderten Daten enthält. Hier ein kleines Notesdokument mit 2 Feldern:

{
    "@href":"http:\/\/localhost:80\/test.nsf\/api\/data\/documents\/unid\/9721E84AF9E25C4AC1257AE200598E50",
    "@unid":"9721E84AF9E25C4AC1257AE200598E50",
    "@noteid":"8F6",
    "@created":"2012-12-28T16:18:11Z",
    "@modified":"2012-12-28T16:18:27Z",
    "@authors":"CN=Ralf M Petter\/O=Demo",
    "@form":"Test",
    "Name1":"Ralf",
    "Name2":"Petter"
}

Natürlich kann das REST Api des Domino Servers noch viel mehr und jede URL bietet auch noch diverse Parameter um das Ergebnis zu beeinflussen. Einen guten Überblick über die Möglichkeiten, bekommt man in der REST Referenz im IBM Developer Wiki.

Das REST Api hat meiner Meinung nach enormes Potential für Anwendungen die nur lose an Domino angekoppelt werden sollen und der RESTClient im Firefox ist ein Super Werkzeug um seine ersten Schritte in diesem neuen Umfeld zu machen.

Debuggen von SSJS in Designer 9 mit der lokalen Web Vorschau

Zum Wochenende habe ich geblogget, wie man den neuen SSJS Debugger mit einem Domino Server verwenden kann. Stephan Wissel hat dann gefragt ob ich nicht auch noch testen könnte wie man den SSJS Debugger mit der lokalen Web Vorschau im Designer verwenden kann. Nun also prinzipiell ist der Ablauf ganz der gleiche wie beim Debuggen einer xPage auf einem Server. Als erstes muss man 3 Einträge zur notes.ini des Designerclients hinzufügen.

JavaEnableDebug=1
JavascriptEnableDebug=1
JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=8001

Wichtig ist, dass falls auf dem Rechner auch ein Server mit Debugunterstützung läuft eine andere Portnummer gewählt wird. Ich habe z.B. 8001 für den Designerclient gewählt und am Server 8000. Damit kommen sich die beiden nicht in die Quere.

Danach muss die lokale Webvorschau einmal durchgestartet werden. Dies kann man im Menü Tools "Stop local web preview" machen.

Sobald man wieder eine lokale Datenbank zum Testen startet, wird der lokale nhttp Task wieder gestartet.  Wenn die SSJS Debug Unterstützung aktiviert ist, findet sich im console.log im IBM_Technical_Support Verzeichnis der Hinweis "JVM: WARNING: Remote Java Debugging is enabled, resulting in decreased performance and potentially compromised security"

Bei mir konnte sich aber trotz der Meldung im Log der SSJS Debugger nicht mit der lokalen Web Vorschau verbinden. Der Grund war, dass ich unter den Java Debugging Preferences den Punkt "Local Web Preview" angeschalten hatte. Diese Einstellung verträgt sich nicht mit den Einträgen in der notes.ini Also den Haken herausgenommen und den lokalen Vorschauprozess noch einmal beendet.

Dann unbedingt vor dem Starten der Debugsitzung einmal eine xPage in der Vorschau öffnen, damit der Lokale Vorschau Prozess wieder gestartet wird.

Dann kann man auch schon über Tools Manage Debug Configurations die SSJS Debug Sitzung starten.

Wichtig ist dann, dass man wieder die richtige Portadresse bei der Verbindung angibt.

Dann läuft wieder alles wie beim Debuggen von Javascript auf einem Server.

Für weitere Infos zur neuen Version schauen Sie auch auf meine Übersicht über alle Postings zum Thema Notes/Domino 9 
Alle Postings zum Thema SSJS Debugger

Designer 9 hat endlich einen Debugger für SSJS in xPages

Ein großes Problem bei der Verwendung von Serverside Javascript in der xPage Entwicklung unter 8.5.x war das Fehlen eines Debuggers. In der heutigen Zeit kann man sich die Arbeit ohne leistungsfähigen Debugger eigentlich gar nicht mehr vorstellen und endlich mit Version 9 des Designers bekommen auch die xPages Entwickler diese in anderen Umgebungen selbstverständliche Hilfe.

Folgende Schritte sind für eine erfolgreiche Debug Session einzuhalten:

Als erste sollte man einen Testserver haben, da um SSJS zu Debuggen der Server mit speziellen notes.ini Variablen gestartet werden muss und diese Variablen erstens die Performance verschlechtern und auch Securityrisken mitbringen. Deshalb bitte die Testhilfeunterstützung auf keinen Fall auf produktiven Servern aktivieren!

Drei notes.ini Variablen müssen auf dem Testserver hinzugefügt werden.

JavaEnableDebug=1
JavascriptEnableDebug=1
JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=8000

Der Wert bei address gibt die Portnummer an, auf denen der Server auf Debugbefehle horchen soll. Beim Start des Debugclients im Designer muss dann genau wieder diese Portnummer angegeben werden. Der Port muss natürlich auch in einer eventuell vorhandenen Firewall freigeschalten werden.

Danach muss der Server durchgestartet werden. Laut Doku reicht das neustarten des HTTP Tasks, doch hat es in der Public Beta bei mir erst nach dem Neustart des gesamten Servers funktioniert.

Dann kann im Designer 9 eine Debugsitzung im Menü Tools gestartet werden.

Für die Debugsitzung kann man einen Namen vergeben, unter dem man die Debugkonfiguration später jederzeit wieder aktivieren kann.

Wichtig sind auch der Host und der Port. Der Host ist der Server und unter Portnummer muss die Nummer eingetragen werden, die unter "address" in der Notes.ini am Server eingetragen wurde.

Dann kann man noch einstellen, ob automatisch bei jedem Serverside javascript angehalten werden soll, oder ob nur bei explizit gesetzten Breakpoint der Debugger aktiviert werden soll.

Falls die Notes.ini Parameter nicht gesetzt sind oder der Server nicht durchgestartet wurde, bekommt man beim Start des Debuggers eine Fehlermeldung.

Wenn alles richtig gelaufen ist, bekommt man keine Fehlermeldung und beim nächsten Aufruf einer xPage auf dem Testserver wird automatisch der Debugger gestartet. Beim ersten Start des Debuggers fragt der Designer ob er zur Debugperspektive wechseln soll, was man natürlich bestätigen sollte.

Danach kann man den Javascript code Schritt für Schritt durchlaufen lassen und jederzeit die Variablen kontrollieren.

Wenn man mit dem Debuggen fertig ist, kann man die Verbindung zum Debugserver mit einem Rechtsklick auf die Verbindung und Auswahl von "Terminate" beenden.

Aufgrund der gewählten Architektur kann immer nur ein Client sich mit der Debugfunktion verbinden. Wenn ein weiterer Client eine Verbindung aufbaut, bekommt man die falsche Fehlermeldung, dass die notes.ini Variablen für die Debugfunktion nicht gesetzt sind. Deshalb sollte immer nur ein Entwickler gleichzeitig den Testserver verwenden.

Für weitere Infos zur neuen Version schauen Sie auch auf meine Übersicht über alle Postings zum Thema Notes/Domino 9 
Alle Postings zum Thema SSJS Debugger

Gedanken zur Edcom Nachlese 2013

Die letzten zwei Tage war ich auf der Edcom Nachlese in München. Zwei Tage vollgepackt mit interessanten Sessions, vielen Gesprächen mit anderen Anwendern von IBM Produkten und einer gemütlichen Abendveranstaltung mit sehr gutem Essen.

Einige Punkte die ich von der Veranstaltung mitnehmen konnte:

Die Sessions zu Connections waren teilweise eher weniger besucht. Im Vergleich dazu waren die Sessions zu Neuerungen in Notes/Domino 9 so voll, dass gar nicht alle sitzen konnten. Man sieht also, dass das Interesse an Notes nachwievor sehr groß ist.

In Notes und Domino 9 gibt es noch mehr Neuigkeiten als ich bisher kannte. Vielleicht kann ich noch den einen oder anderen Blogpost dazu erfassen, wenn ich auch diese Features getestet habe.

xPages ist noch immer ein großes Thema bei der IBM, auch wenn ich nach wie vor eher skeptisch bin was xPages betrifft. Der neue Serverside Javascript Debugger von xPages in Notes 9 sieht nicht schlecht aus.  Auch die Managed Beans die man in xPages verwenden kann, sind eine gute Erweiterung der Möglichkeiten des xPages Entwicklers.

Connections ist ein interessantes Produkt mit vielen Möglichkeiten, dass aber aufwendig einzurichten und vor allem zu administrieren ist. Was sich die IBM dabei denkt, dass es keine UI für die Administration gibt und man sämtliche Administrierungstätigkeiten in XML Dateien bzw über kryptische Befehle auf der Commandline erledigen soll, erschließt sich mir nicht wirklich.

Die TimetoAct hat mit dem Connections Administration Toolkit (CAT) ein sehr interessantes Werkzeug zur Administration von Connections im Angebot, dass die Defizite der IBM ausgleichen kann.

Scott Souder und Chris Crummney haben die Keynotes gehalten und konnten eine sehr positive Stimmung verbreiten. Scott Souder präsentierte erfreuliche Nachrichten für den Bereich Notes/Domino. Die Anzahl der Kunden mit aktiven Wartungsverträge ist 2012 wieder gestiegen. 1500 Kunden die Ihre Verträge früher nicht mehr verlängert hatten, sind 2012 wieder zurückgekehrt. Ich denke Scott Souder der Notes seit Version 1 kennt, hat die Fähigkeiten die Lücke die der Wechsel von Ed Brill zur mobility Sparte hinerlassen hat zu schließen. Ein Blog von Scott, ählich dem von Ed Brill ist bereits in Vorbereitung und soll demnächst online gehen.


Scott Souder hat in der Fragestunde gemeint, dass der Designer und der Notesclient getrennt werden sollen, damit die Eclipseversion des Designer schon früher aktualisiert werden kann. Aber auch der Client soll in der nächsten Major Version nach 9 auf die aktuelle Eclipseversion gebracht werden. Dies ist mir als Pluginentwickler von sehr großer Bedeutung Ebenfalls auf meine Frage hin wurde versprochen, dass auch die Bereiche die derzeit noch im alten Design sind an die neue Designsprache angepasst werden. z.B. der Anwendungs Öffnendialog wurde von ihm explizit erwähnt. Er meinte auch, dass seit der öffentlichen Beta im Dezember noch viele Verbesserungen eingebaut wurden.

Volker Weber hat seine neuesten Handys Blackberry Z10 und Nokia Lumia 920 vorgezeigt und erklärt. Blackberry 10 sieht wirklich sehr gut aus und vor allem die perfekte Trennung zwischen geschäftlicher und privater Umgebung ist ein echtes Alleinstellungsmerkmal von Blackberry. Blackberry 10 wird vom Traveler 9 unterstützt. Ein Blackberry Enterprise Server ist für Blackberry 10 nur notwendig, wenn ich die Trennung zwischen geschäftlich und privat haben möchte. Sonst kann man das Z10 auch ohne BES betreiben. Der BES 10 ist wesentlich ressourcenschonender, da er eigentlich nur mehr ein Provider für eine sichere Verbindung ins Firmennetzwerk ist. Die eigentliche Synchronisation mit Domino erfolgt ebenfalls über Activesync und dem Traveler. Auch das Lumia 920 macht einen extrem guten Eindruck und wird ebenfalls ab Traveler 9 unterstützt. Die Kamera des Lumia ist ein echtes Highlight und macht vor allem bei wenig Licht für eine Handykamera fantastische Fotos. Auch sonst läuft Windows Phone 8 extrem flüssig und ist auf jeden Fall eine Alternative zu iOS und Android.

Alles in allem eine rundum gelungene Veranstaltung, die sich auf jeden Fall ausgezahlt hat.

Content Assist in Domino Designer oder Eclipse anpassen.

Aufgrund der historisch gewachsenen API der Notes.jar können die Syntaxvervollständigungsvorschläge teilweise etwas verwirrend sein. Es gibt die selben Typennamen in bis zu 4 Paketen. Es ist auf den ersten Blick nicht leicht zu erkennen welchen Namen man jetzt importieren soll.

Der Richtige in dem Fall wäre der Erste.

Eclipse bzw. DDE bieten aber eine komfortable Einstellungsmöglichkeit mit der man die Vorschläge für die falschen Paketen ausschließen kann.

Unter DDE muss man den Menüpunkt "Datei->Vorgaben" und unter Eclipse "Windows->Preferences" aufrufen. Dort kann man dann  unter "Java->Darstellung->Typfilter" die Pakete hinzufügen, für die man keine Syntaxvervollständigung mehr haben will.

Und schon klappt es auch mit der verbesserten Syntaxvervollständigung.

Übrigens für Entwickler die viel mit SWT und jface arbeiten, kann man mit der selben Funktion auch awt und swing unterdrücken, da es auch hier viele Überschneidungen der Typnamen gibt.