The beta of XPages in Bluemix introduces the concept of splitting design from data, with (on the whole) one NSF for the XPages components and one for the data. But for me that’s not a new concept, and has not been for some time.

Accessing a separate database is nothing new in XPages. It was something I was doing in 8.5.0 and something I first did programmatically in the first release of XPages OpenLog Logger.

Consequently, pointing all data to a separate data database is similarly straightforward and something I’m doing for an upcoming set of demo applications. The core code I’ve added onto XSnippets.

It requires some Java utility methods, the first and most complex of which are for retrieving a notes.ini / xsp.property variable. I’ve ported these as-is from XPages OpenLog Logger, but in most scenarios I suspect the xsp.property would be a better approach than notes.ini. Then follow the getter and setter. As you can see from the code on XSnippets, this lazy-loads the variable into the class, something that becomes a standard approach once you move into Java and have easy access to e.g. a bean for the page. Finally, there’s a helper method that uses the variable to get the relevant Domino database, for everywhere you want to use from Java.

On the surface, converting an existing application may seem hugely onerous, but it’s not. A find-and-replace on ExtLibUtil.getCurrentDatabase() to repoint to AppUtils.getDataDb() handles all Java references. And for any datasources, you just need to add in the databaseName property, like this:

  <xp:this.databaseName><![CDATA[${javascript:importPackage(uk.co.intec.utils);
AppUtils.getDataDbPath();}]]></xp:this.databaseName>
Any SSJS code that uses the database variable will also need amending to call AppUtils.getDataDb(), with the same importPackage statement. Alternatively, you could use an applicationScoped bean that only stores the path (scoped variables can be accessed via just the variable name, although it’s up to the developer to ensure the same variable name is not also used in request, view or session scope). Personally, where all my business logic is now in Java, calling a utility method is easier and cleaner.
Why do this? It means the differences in application structure for coding XPages applications for Bluemix is minimal. Beyond XPages, the application structure for OSGi plugin applications, other non-XPages applications or even non-Domino web applications is negligible.

1 thought on “Building On Premises XPages The Bluemix Way”

  1. Hi,
    Thanks for sharing this.

    Just a comment regarding the ExtLibUtil.getCurrentSession().getServerName(). We discovered that in Notes client this is returning an empty string, also when on server. It was discovered when we had some problems with users working on Citrix. On web this returns the correct servername.

    Using ExtLibUtil.getCurrentDatabase().getServer() works in both situations . . .

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top