Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Some Tips for Writing JavaScript Adapters for IBM MobileFirst

DZone's Guide to

Some Tips for Writing JavaScript Adapters for IBM MobileFirst

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

I’ve been doing a lot of playing lately with MobileFirst, and one of the cooler features it has is the ability to write adapters in JavaScript. I blogged about this last week and today I thought I’d share a few tips/notes for folks who may be new to this feature.

First and foremost, it is important to remember that you are not using a full Node.js-style stack. You are working with a subset of the Rhino container developed by Mozilla. This is a JavaScript engine that runs within the context of a Java server. However, this is not a full Rhino implementation as some features, like load(), are not implemented. Unfortunately we don’t document these differences (yet – I’m filing an enhancement request for this today).

Second, you cannot debug via console.log. Instead, simply use the WL.Logger API as shown below:

function getDetail(id) {
	WL.Logger.info("getDetail, requesting id "+id);
	return WL.Server.invokeSQLStatement({
		preparedStatement : getDetailStmt,
		parameters:[id]
	});
}

And where do those logs show up? Type mfp logs at the command line to be shown where your logs exist:

shot1

Then you can simply go to that directory and look at messages.log. I’d simply tail -f it while you work to see incoming messages. The log is a bit verbose, but you could use other tools to filter it out.

The third point to consider is that adapters are session-based. That means you can persist data by simply using a global JavaScript variable, but it will not be global to the server.

Finally, and I’ve mentioned these before, but don’t forget that you need to “build/deploy” when you edit your adapter files. You can use the bd shortcut for adapters just like you do for your web assets: mfp bd. You can also test your adapters directly from the command line using mfp invoke.

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.

Topics:

Published at DZone with permission of Raymond Camden, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}