Reading JS library from CDN within Mirth

Question

I'm doing some testing around Mirth-Connect. I have a test channel that the datatypes are Raw for the source and one destination. The destination is not doing anything right now. In the source, the connector type is JavaScript Reader, and the code is doing the following...

var url = new java.net.URL('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.15/lodash.fp.min.js');
var conn = url.openConnection();
conn.setRequestMethod('GET');

if(conn.getResponseCode() === 200) {
    var body = org.apache.commons.io.IOUtils.toString(conn.getInputStream(), 'UTF-8');
    logger.debug('CONTENT: ' + body);
    globalMap.put('_', body);
}

conn.disconnect();

// This code is in source but also tested in destination
logger.debug('FROM GLOBAL: ' + $('_')); // library was found
var arr = [1, 2, 3, 4];
var _ = $('_');
var newArr = _.chunk(arr, 2);

The error I'm getting is: TypeError: Cannot find function chunk in object.

The reason I want to do this is to build custom/internal libraries with unit test and serve them with an internal/company CDN and allow Mirth to consume them.

How can I make the library available to Mirth?

You can try it this way ..... copy the entire js available in https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.15/lodash.fp.min.js and place that in code template of mirth then use it. — Vibin Guevara, Nov 14 '19 at 04:08

score 5 · Answer 1 · edited Jun 20 '20 at 09:12

Rhino actually has commonjs support, but mirth doesn't have it enabled by default. Here's how you can use it in your channel.

channel deploy script

with (JavaImporter(
    org.mozilla.javascript.Context,
    org.mozilla.javascript.commonjs.module.Require,
    org.mozilla.javascript.commonjs.module.provider.SoftCachingModuleScriptProvider,
    org.mozilla.javascript.commonjs.module.provider.UrlModuleSourceProvider,
    java.net.URI
)) {
var require = new Require(
    Context.getCurrentContext(),
    this,
    new SoftCachingModuleScriptProvider(new UrlModuleSourceProvider([
        // Search path. You can add multiple URIs to this array
        new URI('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.15/')
    ],null)),
    null,
    null,
    true
);
} // end JavaImporter

var _ = require('lodash.min');
require('lodash.fp.min')(_); // convert lodash to fp

$gc('_', _);

Note: There's something funky with the cdnjs lodash fp packages that don't detect the environment correctly and force that weird two stage import. If you use https://cdn.jsdelivr.net/npm/lodash@4.17.15/ instead you only need to do var _ = require('fp'); and it loads everything in one step.

transformer

var _ = $gc('_');
logger.info(JSON.stringify(_.chunk(2)([1,2,3,4])));

Note: This is the correct way to use fp/chunk. In your OP you were calling with the standard chunk syntax.

Additional Commentary

I think it's probably ok to do it this way where you download the library once at deploy time and store it in the globalChannelMap, then retrieve it from the map where needed. It would probably also work to store the require object itself in the map if you wanted to call it elsewhere. It will cache and reuse the object created for future calls to the same resource.

I would not create new Require objects anywhere but the deploy script, or you will be redownloading the resource on every message (or every poll in the case of a Javascript Reader.)

Edit: I guess for an internal webhost, this could be desirable in a Javascript Reader if you intend for it to pick up changes immediately on the next poll without a redeploy, assuming you would be upgrading the library in place instead of incrementing a version

The benefit to using Code Templates, as Vibin suggested is that they get compiled directly into your channel at deploy time and there is no additional fetching step at runtime. Making the library available is as simple as assigning it to your channel.

In my case, what Vibin suggested is not a benefit since code is not reusable across multiple instances. Also, having a test suite is more cumbersome. Having all common functionality outside Mirth with unit test and pulling code as need makes more sense for my use case. — redeemefy, Nov 26 '19 at 14:17

score 0 · Answer 2 · answered Nov 22 '19 at 03:42

0

Even though importing third party libraries could be an option, I was actually looking into this for our team to write our own custom functions, write unit-test for them, and lastly be able to pull that code inside Mirth. I was experimenting with lodash but it was not my end goal to use it, it is. My solution was to do a REST GET call with java in the global script. Your URL would be the GitHub raw URL of the code you want to pull in. Same code of my original question but like I said, the URL is the raw GitHub URL for the function I want to pull in.

answered Nov 22 '19 at 03:42

redeemefy

4,521
6
36
51

Well, you can absolutely use the answer I posted to do that if you write your custom functions as modules. You then also get the benefit of having modules able to depend on other modules and caching so that the same code isn't pulled down more than once when accessed with the same require instance. If you're pulling down code as a String, you'll then also need to either compile it in a separate step, or eval it (which I would not recommend.) – agermano Nov 22 '19 at 14:06
How do you pass a token to the `new URI()` – redeemefy Nov 25 '19 at 03:15
A URI is just a path. If you need to authenticate first, you might need to extend https://mozilla.github.io/rhino/javadoc/org/mozilla/javascript/commonjs/module/provider/UrlModuleSourceProvider.html to allow it to take a token. The extension code would probably end up looking similar to what you already are using. Alternatively, a URI can also point to a local file if you have a local clone of the git repo. – agermano Nov 25 '19 at 08:44

Reading JS library from CDN within Mirth

2 Answers2

channel deploy script

transformer

Additional Commentary