Questions and Answers from deploying a Teamroom application on Bluemix

Introduction

write once, run everywhere

Thise WORE slogan is used often in cross-platform solutions, also in IBM Domino. But what if you move your XPages application from an on premise Domino installation to the cloud, more specific IBM Bluemix?

Teamroom

To gain some experience in this area I decided to take a well known application, IBM’s Teamroom and deploy it on Bluemix. I will spare you the details of creating a Bluemix account, setting up Domino Designer, deploying the Design application and binding it to a XPages NoSQL Database service. I will focus on adapting/preparing the Design of the XPages application and some areas I have not found an answer for (yet).

First consideration – Choose your data-binding

bluemixContext

Bluemix requires the separation of design and data so if you haven’t use this principle your applications yet, you must apply it now. Second, Bluemix will allow you also to run your XPages application in a mixed environment (part cloud / part on-premise) so if your application will do so the bluemixContext object will let you identify where your application is running and point to the corresponding data NSF.

DAO Bean

In my case the Teamroom application would only run in Bluemix so instead of applying bluemixContext.getDataService().findDatabaseName() I prefer to use Oliver Busse’s daobean which I have been using in other applications as well. This allows me to use the shorter dao.getDbpath() for xp:dominoDocument and xp:dominoView data-binding.

Remember: in the Teamroom design you need to set this property for every Document and View binding!

<xp:this.databaseName><![CDATA[#{javascript://bluemixContext.getDataService().findDatabaseName()
dao.getDbpath()}]]></xp:this.databaseName>

Use the search function in DDE to locate where these bindings are used.

Valuepickers

Value pickers are used throughout the Teamroom application and for the dataProvider property you need to calculate the location of the database.

Search after dataProvider and you will get the list of design elements where they are used. Look for the once who use the xe:dominoViewValuePicker since they are using a View as data-source. Again make the database location computed.

Addressbook

Some dataProviders use xe:dominoNABNamePicker and the location of the server is set via the Teamroom Setup function, which asks for the web server address. Default the web server address where the design resides is filled in. I tried to fill in the ip address of the server where the data resides (gathered via dao.getServer()) but this still did not allow me to open an NAB.

@dbcolumn @dblookup

What is an XPages application without the @dbcolumn and @dblookup functions? Use DDE to allocate in which design elements there are used and exchange the @DbName() function with bluemixContext.isRunningOnBluemix()? bluemixContext.getDataService().atDbName():@DbName or dao.getServer()+”!!”+dao.getDatabase(). 

database object

With the database object is you can make a quick reference to the NotesDatabse class, and so it is used throughout the Teamroom application. Mind a database.isFTIndexed() to check if the search bar will be displayed or not? Again do your search in DDE.

You can apply method chaining e.g. dao.getDatabase().isFTIndexed()

Run form validation

I noticed that I had to disable the option to validate the saving of documents using form validation (on document save option). Otherwise the operation failed silently.

Changing form name

Adding a team member via the browser resulted in a document created with the form reference of Team Member Profile   –   ParticipantProfile. If you add a member via the Notes client the form reference will be ParticipantProfile. This explains why newly created members did not appear in the list at first.

So I modified the form name as:
<xp:dominoDocument formName=”ParticipantProfile” …

I also set this alias as first in the Notes form. Not sure if that is necessary.

Wrap-up

So far so good. So how “Bluemix ready” is my Teamroom and what are my first thoughts?

Except the lookup to the name and address book I pressume my Teamroom is working as normal. I guess you can call this is major issue.

The tag cloud is not working, but that is due to the fact that the  xp:tagCoud control does not provide a database property (yet). Again I would call this a major issue.

Looking at the design of the Teamroom and counting the number of design elements I would think the development team has made the application design too complicated. I think the power of custom controls and property definitions is that you can re-use them in complete other ways and so reduce the amount of design elements.

I also notified almost no Java code in the design. Perhaps adding some classes for the objects can also reduce the amount of design elements dramatically. Also the application might get less spaghetti coded with logic stored in a central place.

Going through the code resulted in some new “discoveries” and was therefor fun to do. I will write another post about the things I haven’t used before.

Happy development and looking forward to next week’s Engage =)