go to post Ward De Backer · Nov 6, 2021 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.
go to post Ward De Backer · Jan 21, 2019 @Fabian Pie one thing I forgot: you should also build an index from the Customer global, e.g. based on Robert's code snippet: set id="" for { set id=$order(^Customer(id)) quit:id="" set city=$get(^Customer(id,"Address",1)) set name=$get(^Customer(id,"Name")) if $length(city)&$length(name) set ^CustomerIndex(city,name,id)="" } Now you can easily filter on the selected city and loop over the (sorted) customer names by iterating over the ^CustomerIndex global using similar JavaScript code as above. By using globals, you get sorting for free! And you don't need to traverse the whole customer global anymore.
go to post Ward De Backer · Jan 21, 2019 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).
go to post Ward De Backer · Jan 9, 2019 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.
go to post Ward De Backer · Jan 4, 2019 In that case, I'd go the $ZF(-100) route with ImageMagick. You can run this from shell and Perl, building from source will be necessary I suppose.
go to post Ward De Backer · Sep 10, 2016 The full Caché is probably too heavy, but a "lite" version as GlobalsDB would be a perfect fit for such a device. In IoT, data coming in from sensors (at a remote location e.g.) typically needs a lot of storage and filtering out before it's sent to a server (located elsewhere). Network bandwidths and in-memory storage are not sufficient to hold and send all data in real-time.I saw these problems already many years ago in several industrial automation projects (even before IoT existed). In IoT applications these days, the incoming data stream for an RPi collecting data remotely is much heavier now - real (lightweight) database storage would be a blessing and can be an excellent stepping stone to full Caché on the server for decision makers and developers. I'm very confident that IoT developers would welcome this because the current offering on the market is sparse.
go to post Ward De Backer · Sep 8, 2016 Supporting an RPi 2/3 would be possible without major code rewriting these days with Windows 10 IoT Core starting from the same codebase as Caché for Windows (built to a different target: ARM). For Linux, the default Raspbian OS is based on Debian.
go to post Ward De Backer · Aug 23, 2016 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! HTH,Ward
go to post Ward De Backer · Aug 23, 2016 Hi Stephan, that's really great news! Is there any progress on the npm release of the Node.js connector?Currently I need to use the field test connector version in my production environment (!) because I need the Node.js 4.x version - many npm modules already require a much more recent Node.js version 4 to install. In the latest official 2016.1 release there is only a v0.10 and a v0.12 connector available.Thanks in advance!
