GraphQL is a standard for declaring data structures and methods of data access that serves as a middleware layer between the client and the server. If you’ve never heard about GraphQL, here is a couple of useful online resources: here, here and here.

In this article, I will tell you how you can use GraphQL in your projects based on InterSystems technologies.

In this article I'll cover testing and debugging Caché web applications (mainly REST) with external tools. Second part covers Caché tools.

You wrote server-side code and want to test it from a client or already have a web application and it doesn't work. Here comes debugging. In this article I'll go from the easiest to use tools (browser) to the most comprehensive (packet analyzer), but first let's talk a little about most common errors and how they can be resolved.

Index

This is a list of all the posts in the Data Platforms’ capacity planning and performance series in order. Also a general list of my other posts. I will update as new posts in the series are added.

You will notice that I wrote some posts before IRIS was released and refer to Caché. I will revisit the posts over time, but in the meantime, Generally, the advice for configuration is the same for Caché and IRIS. Some command names may have changed; the most obvious example is that anywhere you see the ^pButtons command, you can replace it with ^SystemPerformance.

While some posts are updated to preserve links, others will be marked as strikethrough to indicate that the post is legacy. Generally, I will say, "See: some other post" if it is appropriate.

Capacity Planning and Performance Series

Generally, posts build on previous ones, but you can also just dive into subjects that look interesting.

• Part 1 - Getting started on the Journey, collecting metrics.
• Part 2 - Looking at the metrics we collected.
• Part 3 - Focus on CPU.
• Part 4 - Looking at memory.
• Part 5 - Monitoring with SNMP.
• Part 6 - Caché storage IO profile.
• Part 7 - ECP for performance, scalability and availability.
• Part 8 - Hyper-Converged Infrastructure Capacity and Performance Planning
• Part 9 - Caché VMware Best Practice Guide
• Part 10 - VM Backups and IRIS freeze/thaw scripts
• Part 11 - Virtualizing large databases - VMware cpu capacity planning

While the integrity of Caché and InterSystems IRIS databases is completely protected from the consequences of system failure, physical storage devices do fail in ways that corrupt the data they store. For that reason, many sites choose to run regular database integrity checks, particularly in coordination with backups to validate that a given backup could be relied upon in a disaster.

In this post I would like to talk about the syslog table. I will cover what it is, how you look at it, what the entries really are, and why it may be important to you. The syslog table can contain important diagnostic information. If your system is having any problems, it is important to understand how to look at this table and what information is contained there.

This week I am going to look at CPU, one of the primary hardware food groups :) A customer asked me to advise on the following scenario; Their production servers are approaching end of life and its time for a hardware refresh. They are also thinking of consolidating servers by virtualising and want to right-size capacity either bare-metal or virtualized. Today we will look at CPU, in later posts I will explain the approach for right-sizing other key food groups - memory and IO.

So the questions are:

Attention:

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

Full backport from IRIS for Windows (x86-64) 2020.1 (Build 215U) Mon Mar 30 2020 20:14:33 EDT

IRIS brought us an excellent %JSON.Package
It is an essential component of the Project Manager (ZPM)
This backport makes it available also in Caché and builds a base to eventually backport also ZPM.

Good men don’t need rules.

The Doctor.

It's not an easy task to be a master of dates and times, it is always a problem and sometimes confusing in any programming language, we are going to clarify and put a few tips to make this task as simple as possible.

Get on the TARDIS and I'm going to turn you into a Time lord

++ Update: August 1, 2018

The use of the InterSystems Virtual IP (VIP) address built-in to Caché database mirroring has certain limitations. In particular, it can only be used when mirror members reside the same network subnet. When multiple data centers are used, network subnets are not often “stretched” beyond the physical data center due to added network complexity (more detailed discussion here). For similar reasons, Virtual IP is often not usable when the database is hosted in the cloud.

Network traffic management appliances such as load balancers (physical or virtual) can be used to achieve the same level of transparency, presenting a single address to the client applications or devices. The network traffic manager automatically redirects clients to the current mirror primary’s real IP address. The automation is intended to meet the needs of both HA failover and DR promotion following a disaster.

InterSystems Data Platforms and performance - Part 5 Monitoring with SNMP

Here's a sample code to display JSON or dynamic object.

It shows how to iterate over object, get property values and their paths.

This should be an overview over a subject that pops up over several places in online documentation mostly as remarks and never as dedicated chapter.

Once upon a time ... No it's not a fairy tale.
In the beginning of Caché (and before) you had your partition to run your code. Part of that partition was a space with all your local variables nicely sorted by %,A,..Z,a,...z