All
Accepted answers
Ward De Backer · Jan 24, 2019 go to post

Excellent work Rob, thank you for the hard integration work!

I got my IRIS container running on AWS in ... less than 15 mins (I used a free tier t2.micro instance). Of which 2/3 of the time was learning to know the AWS website! wink

Let's start developing now the latest React/Vue.js/... apps with QEWD.js/Node.js back-end running on IRIS ... which is very easy now because the complete back-end is in a Docker container to try out.

And you have the choice at the front-end: communicating with the back-end using WebSockets or REST endpoints using e.g. the react-qewd or vue-qewd module ... all abstracted for you using very easy methods like this.$qewd.send() (Vue.js with WebSockets) or axios.post() (using REST calls).

Ward De Backer · Aug 23, 2016 go to post

If your Node.js version is 4.4.7, you need the Node.js connector provided in the latest field test. If you have a WRC login, you can find it under "developer download". Be aware this is a field test version - not ready for production use.

The existing versions you'll find in the latest official release (2016.1) are cache0100.node (for Node.js version 0.10.x) and cache0120.node (for version 0.12.x). If you install a on a 64-bit Windows, you also need to install the Node.js 64-bit binary and use the corresponding 64-bit cache.node connector you'll find in the Caché bin directory - as Caché follows the OS architecture version, everything needs to be of the same architecture version - Node.js itself and also the cache.node connector. Just put the connector in your node_modules directory (where you install your other Node.js modules using npm) and rename it to cache.node, that's all! You then just put require('cache') in your Javascript code and you can open a Caché connection.

If you need the cache.node connector for the current Node.js LTS version 4.x from the field test, you don't need to install the Caché field test completely - you can also extract it from the field test installation package (cache-2016.3.0.640.0-win_x64.exe) using e.g. 7-Zip: first extract the field test installer exe to a temp dir and next, also extract the other_~1.cab file in the temp dir to another temp dir. You'll find there a cache421.node connector you can use with Node.js version 4.x (currently v4.5.0).

One more tip: to determine if a certain cacheXXXX.node connector version will work with your Node.js version, you can check the Node.js release table: you need to look at the NODE_MODULE_VERSION column. As long as the module version number is the same, it will work with that Node.js version. E.g. in the field test installer, you'll find a cache421.node connector for version 4.2.1. As this is module version 46, it will also work on Node.js 4.4.7 and 4.5.0. But it will not work on version 6.x (module version 48 is required for that).

And in addition, always remember the OS architecture (x86 or x64) needs to be the same for Caché, Node.js and the cache.node connector! wink

HTH,
Ward

Ward De Backer · Sep 13, 2018 go to post

Hi,

I'm using the popular JasperReports reporting library with Caché/IRIS for several years.  See my presentation on this topic from the Caché User Group how to do this: CUG - reporting with JasperReports

You have several options: using the IRIS JDBC connector is the most obvious one, but I'm also using HTTP endpoints returning XML data source to JasperReports. Works very well.

A big advantage is that you can design your reports pixel-precise using JasperSoft Studio.

FYI, you can simply use the JasperReports server community edition: https://community.jaspersoft.com/

You'll need to install JasperReports Server and JasperSoft Studio to work with the IRIS JDBC connector.

HTH,

Ward

Ward De Backer · Dec 21, 2018 go to post

Hi Scott,

I assume you discovered a useful Node.js module for image manipulation in the NPM registry.

As Bernd Mueller describes in an article about callouts, I think the most efficient way is to host your Node.js module in an Node.js/Express server endpoint and make a REST call from within ObjectScript to do this. As Bernd describes, you can do this quite easily using this technique because REST calls are much more efficient than starting external (Node.js) process instances with $ZF() for each callout.

However, there's also a much more powerful variant of Node.js/Express server where you have access in JavaScript to your Caché/IRIS data too using the latest QEWD-Up server. To just manipulate an image externally this will probably look as an overkill, but for other external JavaScript modules where you need to have access to your data too, this multiprocess Node.js/Express server is a perfect fit for applications needing external functionality.

I'm using this for my applications too to use external JavaScript modules, giving you access to pretty much everything you can imagine and the NPM registry has an out-of-the-box module available for.

HTH,

Ward

Ward De Backer · Jan 3, 2019 go to post

The instructions in the docs are different from the usual place a node.js module like iris.node should be put.

Usually, you create a test.js file in a directory of your choice, e.g. in C:\Test and inside this directory, you create a C:\Test\node_modules directory where iris.node should be placed.

When you do:

var iris = require('iris')

Your test.js file will look for it inside node_modules.

Ward De Backer · Jan 9, 2019 go to post

Yes, this makes no difference at software level and should work exactly the same with RS422/485 as with RS232.

The difference is that with RS232 the hardware cable uses single-ended signals, with RS422/485 the cable uses differential signals. In addition, RS485 can transport signals over much longer cables and can talk to multiple devices connected to the same cable, in that case a protocol with device uid's is needed.

So Caché can talk in an identical way to a RS485 device, but the (software) protocol will probably be different.

You'll need also a hardware device (converter/bus driver) to convert the RS232 signals from your pc/server to RS485 differential signals.

Ward De Backer · Jan 21, 2019 go to post

You should have a look at the ewd-document-store npm module, this module contains high-level global access methods for Node.js. Btw, it's the underlying module used also by the QEWD.js back-end server for Node.js & Caché/IRIS.

E.g. you can iterate easily over your Customer global using:

var DocumentStore = require('ewd-document-store');

// put the appropriate irisXXX.node version inside node_modules
// and rename it to iris.node
var iface = require('iris');
var db = new iface.IRIS();

// Change these parameters to match your IRIS system:
var ok = db.open({
  path: '/opt/iris/mgr',
  username: '_SYSTEM',
  password: 'SYS',
  namespace: 'USER'
});

// bind the iris.node db instance to the high-level DocumentStore
var documentStore = new DocumentStore(db);
// instantiate a DocumentNode object to access the Customer global
var customerNode = new documentStore.DocumentNode(‘Customer’);
// iterate over customerId's using the forEachChild() method
customerNode.forEachChild(function (customerId) {
  console.log(customerId); // will output 1, 2, 3, ...
  // access sub-nodes using the $() method using method chaining
  // and retrieve the city using the value property
  if (customerNode.$(customerId).$('Address').$('1').value == 'London') {
    // do what's needed with a London customer ...
  }
});

// probably, customerNode.forEachLeafNode() is even more appropriate

// close the db connection to IRIS
db.close();

I haven't completely tested the code above, but you should get the idea. The module provides you with some cool high-level NoSQL access methods to iterate over a global  in JavaScript. The methods of DocumentStore and DocumentNode allow you to access very large globals without size and/or memory limitations (see documentation).

Ward De Backer · Jan 26, 2019 go to post

A quick idea: doing a search for TWAIN on the NPM repository for JavaScript & Node.js, it seems you can quite easily add the ability to scan images to any web application:

  • add the Scanner.js module to your web page
  • add the scanner.scan() method in your webpage to show a native TWAIN dialog in the user's browser
  • from the examples in their developers guide, you can then show the images in the browser & upload them to the server (this should work with any back-end which allows file uploading)
  • I would upload the images to a (protected) image directory on your webserver instead of storing them as a blob inside the CACHE.DAT - your database will grow very quickly and it becomes much more difficult to show images e.g. in a browser page

You can easily search for more TWAIN npm modules on npm - Scanner.js seems to be the most popular one these days. You don't have to re-invent the wheel, npm contains a gazillion of modules for nearly every application you can think of!

Ward De Backer · May 14, 2021 go to post

Nice repository and a must-read, uncovering the best kept secret about the fastest databases on the IT planet! yes

Ward De Backer · Aug 23, 2021 go to post

I'm a cat fan ... wink

<object>
  <script>S tooCute=1</script>
  <cats>

  </cats>
</object>

Ward De Backer · Nov 6, 2021 go to post

Front-end technology changes much faster than back-end technology. As Dmitry also suggests, for best results I can recommend you for writing web based apps to use modern front-end frameworks like Vue.js/NuxtJS, React, Angular, Svelte. These frameworks allow you to write well-structured and maintainable code, separating front-end nicely from your back-end. See also this NuxtJS tutorial article. Btw, if you're most used to HTML/CSS/JS in your pages, Vue.js will feel the most familiar to work with and it allows you too to update your existing pages gradually by including the Vue.js script in your <head> tag and start using it for parts of your existing HTML code.

To interact with you back-end IRIS/Caché server, you have two major options: using the REST application server built into IRIS/Caché (if you want to write your back-end completely in ObjectScript) or use a Node.js applications server built on the very popular Express npm module: QEWD-Up. This Node.js back-end server is both a REST & WebSockets application server. It allows you to write JavaScript both in your front-end and back-end code.

In addition, the Node.js option has the advantage you can use all existing npm modules too: for nearly every feature you can imagine, you'll find an existing npm module - you don't need to re-invent the wheel! E.g. you need Google maps in your app? There's a module for that!

WebSockets in contrast to REST give you a very efficient open connection to your IRIS/Caché back-end without the overhead of a REST call. And the most important part: QEWD-Up takes care of all setup and boilerplate code so you can focus on your application code.

Ward De Backer · Nov 15, 2021 go to post

It's really great to see the developer community growing to this milestone, it's a great place to meet other members, exchange ideas and new concepts. Congratulations to the whole DC team, keep the community growing! On to the upcoming next 5 years! yesyesyes

Ward De Backer · Dec 2, 2021 go to post

Very nice integration PoC, showing the power of using the Node.js ecosystem. Combining mainstream Node.js tools & modules with IRIS allows you to create very powerful applications without having to reinvent the wheel. smiley

Ward De Backer · Sep 29, 2022 go to post

Rob, this is a great addition to the JavaScript (Node.js) tech stack for IRIS because glsdb allows you to work with classes and globals as if they were simple JS arrays or objects. A JS developer has now persisted arrays/objects at his disposal in a very simple & familiar way.

This is a big step forward for creating Node.js back-end applications with IRIS as the underlying database when you combine this with any standard JS front-end framework + tools.

Ward De Backer · Oct 24, 2022 go to post

I'm very sorry I missed this one!

My 2 cents: I think you still need both because VSCode doesn't work on older Caché versions (as you need Atelier api). But I'm looking forward to be able to move over to VSCode when all features are supported there.

Ward De Backer · Oct 27, 2022 go to post

Hi Rob, this backend architecture is a very good solution and makes the native API really usable for real-world scenarios. Thanks for your contribution which opens up IRIS to the Node.js JavaScript community!

Ward De Backer · Mar 16, 2023 go to post

Very nice article @Maria Gladkov to start developing with VSCode! The most noteworthy extensions I'm using too in my VSCode setup:

  • Encode decode (convert text to other formats like Base64)
  • OpenAPI (swagger) Editor (specifying & documenting your REST api endpoints)
  • WSL (enabling direct use of the Windows Subsystem for Linux in VSCode)
Ward De Backer · May 2, 2023 go to post

Thanks for this great article @Robert Cemper ! This brings back memories ... I did some benchmark testing as a student on a DEC MicroVAX I in 1987 in VMS (using a VT100 terminal). I didn't work with M at that time yet but our retail business run by older family members started using it in +/-1986 on a PC AT (Micronetics MSM running on top of DOS) with an ISA bus terminal multiplexer card - RS232/422 cables were installed for multiple Falco VT420 terminals. Soon after, our other retail business started using Digital Unix workstations with these VT terminals too. I started programming in M in 1997 using DTM, soon followed by Open M when we grounded our current retail business and now - 26 years later - I'm writing modern apps and api's in JavaScript/ObjectScript using a Caché/IRIS + Node.js back-end running on the same globals structure! I don't think many technologies can stay relevant/on top for that long ... 😉

Ward De Backer · May 23, 2023 go to post

Great work, VSCode extensions work very well now with all latest fixes & improvements - I switched from Studio to VSCode for all ObjectScript development! 😉

Ward De Backer · Oct 5, 2023 go to post

How about "Coffee Machine Talks"? As a lot of developers are real coffee addicts ... 😂

Ward De Backer · Oct 5, 2023 go to post

@Rob Tweed thanks for the correction: of course, the qewd.start  must be done before the qewd.intercept - my mistake. I changed the article text to reflect this change!