This is a coding example working on Caché 2018.1.3 and IRIS 2020.2 
It will not be kept in sync with new versions 
It is also NOT serviced by InterSystems Support !

In Caché you had an example of a WebSocket Server in namespace SAMPLES
With IRIS the samples are gone and require additional installation effort.

This is a coding example working on Caché 2018.1.3 and IRIS 2020.2 
It will not be kept in sync with new versions 
It is also NOT serviced by InterSystems Support !

WebSockets as a communication technology wins increasing importance.
In the SAMPLES namespace, you find a nice example for running a WebSocket Server.
There is also a useful example for a Browser Client. But it is still in the browser. 

My point is:
How to consume the output of a WebSocket Server in your application?

In this article, I would like to talk about the spec-first approach to REST API development.

While traditional code-first REST API development goes like this:

• Writing code
• REST-enabling it
• Documenting it (as a REST API)

Spec-first follows the same steps but reverse. We start with a spec, also doubling as documentation, generate a boilerplate REST app from that and finally write some business logic.

This is advantageous because:

• You always have relevant and useful documentation for external or frontend developers who want to use your REST API
• Specification created in OAS (Swagger) can be imported into a variety of tools allowing editing, client generation, API Management, Unit Testing and automation or simplification of many other tasks
• Improved API architecture.  In code-first approach, API is developed method by method so a developer can easily lose track of the overall API  architecture, however with the spec-first developer is forced to interact with an API from the position if API consumer which usually helps with designing cleaner API architecture
• Faster development - as all boilerplate code is automatically generated you won't have to write it, all that's left is developing business logic.
• Faster feedback loops - consumers can get a view of the API immediately and they can easier offer suggestions simply by modifying the spec

Let's develop our API in a spec-first approach!

Similar to Caché so also in IRIS,  you have ClassQueries available in 2 variants

• Basic class queries, which use the class %SQLQuery and an SQL SELECT statement.
• Custom class queries, which use the class %Query and custom logic to execute, fetch, and close the query.

By now it's a commonplace how to implement a basic REST API in Caché and there is good documentation about it here: REST in Caché

A question that comes up from time to time is:

How can I make a parameter in my REST url optional?

Simply put, is it possible to create a URL map in Caché that maps a URL like this:

or "So you just got yelled at by your boss, for sending him an unformatted Hello World webpage"

Our previous lesson ended with us serving a Message value obtained from a Caché REST service to the client, using Angular as a runtime.  While there is a lot of moving parts involved in this process, the page is not especially exciting at the moment.  Before we can start adding new features, we should take a step back and review our tools.

Apache Spark has rapidly become one of the most exciting technologies for big data analytics and machine learning. Spark is a general data processing engine created for use in clustered computing environments. Its heart is the Resilient Distributed Dataset (RDD) which represents a distributed, fault tolerant, collection of data that can be operated on in parallel across the nodes of a cluster. Spark is implemented using a combination of Java and Scala and so comes as a library that can run on any JVM.

This is a coding example working on Caché 2018.1.3 and IRIS 2020.2 
It will not be kept in sync with new versions 
It is also NOT serviced by InterSystems Support !

Background

Device #2 named SPOOL dates back to the predecessors of Caché and IRIS
It was the first "%Stream" like option to buffer output before printing.
It is also the first and still today the most simple way of output redirection.

Easily transform a CSV file into a personalized preview of DeepSee - InterSystems BI

AnalyzeThis can be found on InterSystems Open Exchange. Use the Download link to navigate to GitHub and begin installing the project. Follow the “Installation” section of the GitHub README.

As we all well know, InterSystems IRIS has an extensive range of tools for improving the scalability of application systems. In particular, much has been done to facilitate the parallel processing of data, including the use of parallelism in SQL query processing and the most attention-grabbing feature of IRIS: sharding. However, many mature developments that started back in Caché and have been carried over into IRIS actively use the multi-model features of this DBMS, which are understood as allowing the coexistence of different data models within a single database. For example, the HIS qMS database contains both semantic relational (electronic medical records) as well as traditional relational (interaction with PACS) and hierarchical data models (laboratory data and integration with other systems). Most of the listed models are implemented using SP.ARM's qWORD tool (a mini-DBMS that is based on direct access to globals). Therefore, unfortunately, it is not possible to use the new capabilities of parallel query processing for scaling, since these queries do not use IRIS SQL access.

Meanwhile, as the size of the database grows, most of the problems inherent to large relational databases become right for non-relational ones. So, this is a major reason why we are interested in parallel data processing as one of the tools that can be used for scaling.

In this article, I would like to discuss those aspects of parallel data processing that I have been dealing with over the years when solving tasks that are rarely mentioned in discussions of Big Data. I am going to be focusing on the technological transformation of databases, or, rather, technologies for transforming databases.

Over the past year or so, my team (Application Services at InterSystems - tasked with building and maintaining many of our internal applications, and providing tools and best practices for other departmental applications) has embarked on a journey toward building Angular/REST-based user interfaces to existing applications originally built using CSP and/or Zen. This has presented an interesting challenge that may be familiar to many of you - building out new REST APIs to existing data models and business logic.

If you define a Persistent Class / Table the class compiler generates for you an appropriate Storage definition.
A different option is to define a SQL mapping for an already existing Global storage.  This has been excellently
explained already in a different series of articles.   The Art of Mapping Globals to Classes 1 of 3

This is a coding example working on Caché 2018.1.3 and IRIS 2020.2 
It will not be kept in sync with new versions 
It is also NOT serviced by InterSystems Support !

Standard error logs in IRIS / Caché / Ensemble are written global ^ERRORS.
As this piece dates back some decades back to previous millennium its structure
is far from the typical SQL storage structures.

"Telegram" is a well-known instant messenger, which provides an API for creating bots. The features of this API allow you to create bots with a wide range of functionality including receiving payments. 
With the help of the telegram bot, I solved a simple task - sending Alerts from Ensemble to Telegram.

Advantages: Alerts come to the mobile phone, a notification appears, so there is no need to install any additional applications (in contrast to the solution https://community.intersystems.com/post/sending-alerts-mobile-phone-using-pushover- httpoutboundadapter).

The bot can be extended by adding new commands, for example, for managing the Production or for solving other tasks in Iris, Ensemble or Cache.