Intro

For many in today's interoperability landscape, REST reigns supreme. With the overabundance of tools and approaches to REST API development, what tools do you choose and what do you need to plan for before writing any code?
This article focuses on design patterns and considerations that allow you to build highly robust, adaptive, and consistent REST APIs. Viable approaches to challenges of CORS support and authentication management will be discussed, along with various tips and tricks and best tools for all stages of REST API development. Learn about the open-source REST APIs available for InterSystems IRIS Data Platform and how they tackle the challenge of ever-increasing API complexity.
The article is a write-up for a recent webinar on the same topic.

In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab. I will cover such topics as:

• Git 101
• Git flow (development process)
• GitLab installation
• GitLab Workflow
• Continuous Delivery
• GitLab installation and configuration
• GitLab CI/CD

In the previous article, we covered Git basics, why a high-level understanding of Git concepts is important for modern software development, and how Git can be used to develop software. Still, our focus was on the implementation part of software development, but this part presents:

• GitLab Workflow - a complete software life cycle process - from idea to user feedback
• Continuous Delivery - software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently.

I needed to know programmatically if last ran failed or not.

After some exploring, here's the code:

ClassMethod isLastTestOk() As %Boolean
{
  set in = ##class(%UnitTest.Result.TestInstance).%OpenId(^UnitTest.Result)
  for i=1:1:in.TestSuites.Count() {
    #dim suite As %UnitTest.Result.TestSuite
    set suite = in.TestSuites.GetAt(i)
    return:suite.Status=0 $$$NO
  }
  quit $$$YES
}

In this article I'd like to discuss asynchronous REST and approaches to implementing it.

Why do we need asynchronous REST? Simply put - answering the request takes too much time. While most requests usually can be satisfied immediately, some can't. The reasons are varied:

• You need to perform time-consuming calculations
• Performing action actually takes time (for example container creation)
• etc.

The solution to these problems is asynchronous REST. Asynchronous REST works by separating request and real response. Here's an example, let's consider the following simple async REST broker:

In this article, I'd demonstrate how you can visualize the usage of Ensemble Workflow with DeepSee (tested on 2015.1 and later).

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.

In my previous article, we reviewed possible use-cases for macros, so let’s now proceed to a more comprehensive example of macros usability. In this article we will design and build a logging system.

Logging system

Logging system is a useful tool for monitoring the work of an application that saves a lot of time during debugging and monitoring. Our system would consist of two parts:

• Storage class (for log records)
• Set of macros that automatically add a new record to the log

In this article I'll show you how you can easily convert between many different document formats, these to be precise:

• in: html, odt, doc, docx, rtf, sdw, txt...
• out: html, odt, docx, rtf, pdf, txt, tex, xhtml...

and many more, check out this table. We'll use LibreOffice as a conversion engine.

In addition to its general security, Caché offers SQL security with a granularity of a single row. This is called row-level security. With row-level security, each row holds a list of authorized viewers, which can be either users or roles. By default access is determined at object modification Some time ago I became interested in determining row-level security at runtime. Here's how to implement it.