In this article I will demonstrate how we can set up a new searchable REST service in an Bluemix XPages environment.
This article was driven by a question on Twitter from Paul Ramos (@parf82) who asked how to search a database in Bluemix. The answer is of course, in the same way that you search it not in Bluemix, using an FTSearch. The more pertinent questions is really how to make the XPages runtime find the application to search in the first place.
Creating the base application
If you follow this video by Brian Gleeson you will be able to create your first application in Bluemix. Once you have that you can manipulate the environment to your hearts content. There are multiple, documented, methods for updating your XPages environment in Bluemix, I prefer to create a Git repository. As Toby and I demonstrated in the socialbizug webcast you can download the application design, manipulate it and send it back to Bluemix as one.
Manipulating the boilerplate
I have the initial boilerplate code cloned to my local hard drive.
First step it to edit the Manifest and get rid of the Boilerplate application. Why, you ask? Well this way you have the manifest and everything else configured for you nicely. You can do this from scratch but I generally find this mentally easier to work through.
I renames the application from todo_design to xpages_design.
I took a design copy of my extjs database and saved it in the git repo folder. The database can be seen at (http://demo.xomino.com/xomino/extjs.nsf) which is at it’s heart just a modified fakenames.nsf database (http://www.xpagescheatsheet.com) from David Leedy.
The reason I chose this database is that it contains a lot of REST services already in a normal XPages environment.
I then had to create a copy of the database itself in the Bluemix NoSQL environment.
We now have the database split into two separate pieces
- The data on slaney/bluemix
- The design xpages_design.nsf – currently in my local git repo
Putting the data directly on slaney – very possible and works in a view as expected
But if we try and access an XPage – it doesn’t work – which is what we would expect.
Accessing the data from the XPages runtime
Back in our xpages_design database we are going to create a normal REST service – but we have to use the new BluemixContext object to find out the path for the service (https://www.ng.bluemix.net/docs/services/XPagesNoSQLDatabase/index.html#xpservice_portexisting).
The bluemixContext values are derived from the VCAP_Services variables made available to the XPages in Bluemix service through Cloud Foundry. An example is shown here – it is available from the Bluemix dashboard for your XPages by clicking on the ^ arrow on your NoSQL database service.
Viewing the result
Once we have pushed the REST service design changes back up to Bluemix we should be able to see them. Once we correctly create the URL to the rest service. In this case “xpages_design.nsf/xRestService.xsp/byFirstNameBlue”
We are able to demonstrate the new searchable REST service by manually modifying the URL and adding search parameters:
In this article we have seen that we are still able to use the XPages out of the box rest service to communicate between the design database and the “data” database. All the out of the box functionality is available as if it were an on premises application. We also saw the usage of the new bluemixContext to find out where the data database resides within Bluemix.