JSONStore Revisited in Worklight V6 Part 1: The Adapter
DavidDhuyvetter 10000034CQ Visits (10397)
This was meant to be a quick V6 update to the Employee Directory app that I wrote using Worklight V5. There have been some changes to the JSONStore API that are worth exploring. Additionally, I've had occasion to use some techniques that I wanted to fold into the sample. Well, before I was done, it turned out to be much bigger than a breadbox. Rather than trying to write it all up in a single post, I'm going to look at it in sections.
For anyone who wants to skip to the end, you can download the PI for the project, and explore it yourself. In addition to configuring the datasource for the adapter (as will be described in this post) you will need to add an Android or iOS environment. After creating the environment, set the Security test for the environment to: Samp
The Employee SQL Adapter
The SAMPLE Datasource
The adapter is still based on the DB2
The Adapter descriptor is actually simpler when you are using a datasource
The rest of the configuration is done in Worklight Studio -> Servers view ->Worklight Development Server -> Server Configuration. The structure of the Datasource definition has a number of parts:
It is a bit easer to see what is going on in the Server Configuration editor Source pane. At its simplest, a Datasource definition isn't anything more than the directions for where to find the database jar file(s), along with the required properties (database name, user name, and password) If the connection details (hostname and port) match the defaults (localhost:50000) then they don't need to be specified in the definition. If you need to specify more details for your particular database, the Design pane of the Server Configuration editor will guide you. Most of the more interesting options are under the DB2 JCC Properties element.
You can add this definition directly to your Worklight Development Server server.xml file, but a nice feature of Liberty Profile is that it supports including fragments. You can put the Datasource definition above in its own XML file in the project (wrapped in a top level <server> ... </server> element), and then simply include this file in your test server configuration. That way, the data source definition can be checked into source code control or shared across a team.
If your server target is WAS ND, then the Datasource definition you used in development provides a guide in how to configure the WAS ND Datasource. If your target server is WAS Liberty, then the Datasource definition file used in development can be adapted and used in production. Details such as hostname/database name/user name/password will probably have to be changed, but any customizations to the configuration can just be passed from development on through to production. It is important to realize that the password in the Datasource definition is obfuscated, but it is not encrypted. The password will not be obvious to someone taking a quick glance at the file, but it can be retrieved from the value. So, care must be taken with this file.
The Adapter Implemetation
With the dataSourceJNDIName in the Adapter's connectionPolicy, and the Datasource definition in the Worklight Development Server configuration, the adapter is much as it was in the initial version of the Employee Directory app. It has the basic CRUD operations defined to support synchronization with the JSONStore. The addEmployee() function is present, but not implemented to avoid the complexity of dealing with foreign key constraints in the Employee table.
The getPhoto() Function
The DB2 SAMPLE database has an EMP_PHOTO table with the photos of some of the employees.
Displaying photos is a natural addition to the Employee Directory application, and it was an excuse to explore using a Worklight SQL adapter to fetch BLOB/CLOB data. The getPhoto() function is not integrated with the JSONStore, because I didn't want to proactively retrieve all the photos in the database. Photos are retrieved as needed by the application using an ordinary Worklight adapter call, and are not cached in the application. The SQL statement for the getPhoto function is simple enough:
My first attempt was the simple implementation for a SQL get:
Unfortunately, this did not return the BLOB data. Instead the caller received:
The JSON serialization of the java.sql.Blob was a simple toString() on the object. In order to get the BLOB data, I had to call getBytes() on the object. This would return a byte array. Unfortunately, this resulted in a different error:
It turns out that the DB2 Datasource has to be specifically configured to support BLOBs. Back in the Worklight Development Server Datasource definition, I added the required properties:
The result was better, but I still wasn't getting the BLOB data in the adapter reply, simply the string representation of a Java byte array. I knew that I ultimately wanted the data to be Base64 encoded (for display as a data URL in an IMG tag) so I Base64 encoded the byte array from the BLOB. (I also pre-pended the data URI indicator that I knew would be needed to display the image) With this, I was able to get the adapter to return the photo data:
As I said at the start, this is just one piece of the Employee Directory. The JSONStore API has been totally revamped since I initially wrote the app. I want to look at the API and how the changes make it easier to use. I also want to look at using JSONStore to provide a mechanism to log into the app when the connection to the Worklight Server is not available. Finally, I want to look at enhancements made to the Logging infrastructure. But those topics are for another day. :-)