Sharing code between Worklight Adapters

Question

In most cases I've dealt with so far the Worklight Adapter implementation has been pretty trivial, just a few lines of JavaScript.

On the current project, using WL 5.0.6, we have several adapters, each with several procedures. Our particular backends require some common logic to set up requests and interpret responses. Seems ideal for refactoring common code to shared library, execpt that as far as I can see there's no "library" concept in the adapter environment unless we want to drop down into Java.

Are there any patterns for code-reuse between adapters?

Answer 1

I think you are right. There is currently no way of importing custom JavaScript libraries.

There is a way to include/load Javascript files in Mozilla Rhino engine by using the "load(xyz.js)" function, but this will make your Worklight adapter undeployable.

But I've noticed, that this will make your Worklight adapter undeployable. If you deploy a second *.js file within an adapter, you'll get the following error message:

Adapter deployment failed: Procedure 'getStories' is not implemented in the adapter's JavaScript file.

It seems like Worklight Server can only handle one JavaScript file per adapter.

Answer 2

I have shared some common functionality between adapters by implementing the functionality in Java code and including the jar file in the Worklight war file. This came in handy to invoke stored procs via JDBC that can handle multiple out parms and also retrieving PDF content from internal backend services. The jar needs to be in the lib dir of the worklight.war web app that the adapter will be deployed to.

Example of creating a java object in the adapter:

var parm = new org.apache.http.message.BasicNameValuePair("QBS_Reference_ID",refId);

Answer 3

One way to share JavaScript between adapters is to follow a pattern somewhat like this:

CommonAdapter-impl.js :

var commonObject = {
  invokeBackend: function(input, options) {
    // Do stuff to check/modify input & options

    response = WL.Server.invokeHttp(input);

    // Do stuff to check/modify response

    return response;
  }
}

getCommonObject: function() {
  return commonObject;
}

NormalAdapter-impl.js :

function getSomeData(dataNumber) {
  var input = {
    method: 'get',
    returnedContentType: 'json',
    path: '/restservices/getsomedata',
  }

  return _getCommonObject().invokeBackend(input);
}

function _getCommonObject() {
  var invocationData = {
    adapter: 'CommonAdapter',
    procedure: 'getCommonObject',
    parameters: []
  }

  return WL.Server.invokeProcedure(invocationData);
}

In this particular case, the common adapter is being used to provide a "wrapper" function around WL.Server.invokeHttp, but it can be used to provide any other utility functions as well.

The reason for this pattern in particular is that it allows the WL.Server.invokeHttp to run in the context of the "calling" adapter, which means the endpoint (hostname, port number, etc.) specified in the calling adapter's .xml file will be used. It does mean that the short _getCommonObject() function has to be repeated in each "normal" adapter, but this is a fairly small piece of boilerplate.

Note that this pattern has been used with Worklight 6.1 - there is no guarantee it will work in future or past versions.