This article is one of the series which introduces Eclipse to experienced Caché/ Ensemble/ HealthShare users. The goal is to open the perspective of a developer who was using Caché Studio for years and make Her/ Him see deeply into the Eclipse world – far beyond Atelier. In other words it is an Atelier (Eclipse IDE for InterSystems technology) beginner’s guide. This time the topic is: editing XML files using Atelier.
As web application gets more complex, more technologies are involved into the application development. Once it gets deployed in large scale the configuration gets more complex too. For sure one of the most difficult part of the story is the security. In a complex solution when independent servers are feeding single web pages with contents, it is indeed challenging to keep the integrity of such system. HTML5 introduced a (weak) security constraint, the Cross Origin Resource Sharing (CORS). This article tells how to enable CORS for CSP/ ZEN applications.
A beginner’s guide to position Ensemble in regards to MicroServices Architecture (MSA). MSA is getting more visibility in the Enterprise Java world therefore it is vital to understand what is behind the buzz. I make a (humble) attempt to write my view and share with you.
Background
First of all I must confess. Early this summer our Czech colleague Daniel Kutac was asking me to collect some information about a health care product developed in Hungary. When I got the feedback from the related company, it turned out, that the product is a modular system, based on MicroServices Architecture (MSA).
This is a beginner’s guide to the design of a “MicroService” implemented in Ensemble. “MicroService” is a popular phrase these days which has a broad interpretation. My interpretation is: “MicroService” is a “NoSQL Service”. A what? The answer is in the article.
We learnt what the difference is between SQL and NoSQL databases. For me the difference is nearly the same between a SOA Web Service and a “MicroService”. I am going to explain it through an example.
Please note, that although this is a beginner’s guide, I assume deep technology knowledge on data modelling, RESTful services and Ensemble.
Beginner’s guide to RESTful Application Program Interface (API) design and documentation. Through the example you will learn some common pattern for RESTful API.
Before you read
You need to know
- How to create RESTful web service in Ensemble
- How to consume RESTful web service in Ensemble
- How to pass service parameters
- How to return service result
What is a Service API?
What is an Application Programming Interface? Is it something materialized? Is it a single programming unit? What is an API for? From my point of view an API is something which is determined by the program code in an indirect way.
A beginner’s guide to Exception Handling in RESTful web services. The article gives an example how the various error conditions during processing a service request can be handled.
We expect our client – server communication working in a flawless operational condition, running error free software. But we are prepared to handle exceptions. Are we? So far in the examples of the previous sessions were not. We did not care about exceptions. The result? In any error incident it took ages to figure out what the problem is and more importantly how to fix it.
Remember, REST leans on HTTP.
This article gives a brief introduction how a RESTful service consumer and a RESTful service provider exchange data. It is a beginner’s guide. Data is transferred from a consumer to a provider as parameters of the service. Parameters are part of a service request. The result of the service action a response is returned from a provider to a consumer. Both the service request and response are standard HTTP messages. Since HTTP is a flexible standard regarding to the message contents, RESTful services also enjoy the versatility of data transfer methods.
The article is a step by step guide for beginners to learn how to build a RESTful web service consumer (or client) in Ensemble. The provider can be any RESTful service, but the example is based on the service we made during the previous sessions.
It is more than obvious that many client development environment has programming libraries or containers to build a RESTful client. For example in the earlier sessions we used Java Script to access services. Ensemble as a container also offers client functionality. Let us have a quick list what Ensemble offers.
Cross-origin Resource Sharing (CORS) is one of the basic security features built into browsers. CORS controls accessing resources from a HTML page in domains other than the original domain. It is particularly important for AJAX calls. Since RESTful services can be used as data provider to any AJAX call, you have to be able to control cross-origin access. By default services are not allowed to do CORS. You are going to learn how to enable it for Ensemble RESTful services.
The Resource Map class (the subclass of %CSP.REST) controls whether CORS is enabled. There are two approaches to do.
This is a detailed guide to develop RESTful services using InterSystems Ensemble. The goal of this guide is to make you understanding the basic concept and building blocks of a RESTful service. The service is going to provide a very basic functionality (a “Hello world!”).
You will learn how to create required components as Ensemble classes, configure the run-time as an Ensemble Production and create a service configuration as a web application.
The Ensemble documentation library explains basically two ways to implement RESTful web service using Ensemble.
A beginners guide to develop Ensemble RESTful web services.
Background
Before you start reading this short introduction please go through the on-line documentation of Ensemble with special attention to chapter “Creating REST services and clients with Ensemble”.
The approach in the documentation is undisputable the fastest and easiest way to create RESTful services. As a beginner I went through the documentation and I had several questions. This short article is listing those questions plus my humble answers.
When I refer to documentation I mean Ensemble 2016.2 and onwards.
Introducing non-persistent messages. eXpert-to-eXpert
Background
InterSystems Ensemble as a tool does a lot for the Developer. One of the nice features is the Message trace utility. It shows a message flow diagram. The diagram shows the progress of the message processing real time. You can get many-many useful information from the production. In any case, someone needs to find a bug in a production implementation, without the Message trace utility it could turn into a real nightmare.
On the other hand, keeping message “traceability” is not for free. A heavy loaded production can very quickly run out of resources just because of the house keeping functions of Ensemble. House keeping functions such as maintaining message header, log entries, message queue generates a significant load on the Caché database used by Ensemble.
This article is about to show how to force Ensemble work more for the everyday life, instead of being prepared for “any-time-debugging”.
This is an eXpert-to-eXpert article. Therefore, I assume the deep understanding of Ensemble.