For some years I missed being able to offer, to everybody interested in ObjectScript, a tutorial more or less complete, to start with ObjectScript. Something that could help more and make things easier to those new developers that come to our technology... something intermediate, halfway between the common "Hello World!", that doesn't really get you further, and the "Advanced Training", that is unaffordable because of lack of time,etc.

If there were something truly helpful not only as an introduction to the ecosystem, but as a starting point, as a boost, to really start to walk into ObjectScript and move forward by yourself... wouldn't that be awesome?

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 !

This  an example of a customized SystemFunction extension (ZZISJSON) in Caché & IRIS
This time it is  to be included in %ZLANGF00.mac

A JSON string is mostly imported from a file or over REST.
You rely on a clean and compatible structure. This is the check.

Hi Devs!

Recently, I needed to create templates for newsletters.
I couldn't find any tools, so I decided to use the CSP (Caché Server Pages) to build the templates.

Let's figure out how to make a newsletter similar to Weekly OEX Digest.

Weekly OEX Digest

There are many ways to generate excel files using Intersystems, some of them are ZEN reports, IRIS reports ( Logi reports or formally known as JReports), or we can use third party Java libraries, the possibilities are almost endless.

But, what if you want to create a simple spreadsheet with only Caché ObjectScript? (no third party applications)

Setting the Scene

I was editing the properties of a persistent ObjectScript class the other day and noticed that the storage definition wasn't updating to reflect my latest changes.

In this case, I deleted a property that was no longer needed from the class definition, saved, recompiled, and still saw it in the storage definition.

InterSystems technologies are renowned for their high performing databases, which support the systems and operations of many organisations. However a key ingredient to this success is the quality and maintainability of their code. 

The quality of code can impact everything from speed and ease of fixing bugs and making enhancements, to the overall performance of your organization and your ability to get ahead in the marketplace. 

By ensuring your code is maintainable, you can reduce approximately 75% of the systems life cycle costs*. This is why, at George James Software, the solutions we build are always straightforward and written in high quality code - because we know that this solid foundation can positively impact the rest of your organization. 

With a maintainable system you're able to reduce your overall maintenance as any issues that occur are significantly faster to identify and fix. This means you're free to allocate that time and budget to enhancements, enabling you to get the most value out of your applications and ultimately better support your organization. 

Keep an eye out for our next few posts about what a maintainable system looks like and the tools that can help you keep your code maintainable, in order to help you to reduce those maintenance costs.  

As you know ObjectScript has no FOREACH system command nor system function.
But it has a wide room for creativity.

The task is to loop over a global or local array and do something FOR EACH element.

There are 2 possible solutions:
- creating a macro that generates the required code sequences
- creating an Extended Command to perform the action.

Hi developers!

Just want to share an old but always relevant best practice on namespaces changing @Dmitry Maslennikov shared with me (again).

Consider method:

classmethod DoSomethingInSYS() as %Status

{

set sc=$$$OK

set ns=$namespace

zn "%SYS"

// try-catch in case there will be an error

try {

// do something, e.g. config change

}

catch {}

 zn ns    ; returning back to the namespace we came in the routine

return sc

}

And with new $namespace the method could be rewritten as:

classmethod DoSomethingInSYS() as %Status

{

set sc=$$$OK

new $namespace

set $namespace="%SYS"

// do something

return sc

}

So! The difference is that we don't need to change the namespace manually as it will be back automatically once we return the method.

and we don't need try-catch (at least for this purpose) too.

Hi community,

This is another article about how to perform actions that you can do in the web portal but via code.

Today.... Add a business item in your production by code

Over the years, I have found myself needing to create multiple HL7 messages based on a single inbound message. Usually these take the form of an order or result from a lab. Each time I have approached it, I have tried to start from scratch under the belief that the previous attempt could have been done better.

A VIEW in SQL is basically a prepared SQL statement.
It has to be executed and assembled like any other SQL query.
MATERIALIZED VIEW means that the content is collected before hands and can be retrieved rather fast.
I saw the concept first with my favorite competitor named O* and they made a lot of noise about it.
  { favorite: because I could win every benchmark against them }

I ran into an interesting ObjectScript use case today with a general solution that I wanted to share.

Use case:

I have a JSON array (specifically, in my case, an array of issues from Jira) that I want to aggregate over a few fields - say, category, priority, and issue type. I then want to flatten the aggregates into a simple list with the total for each of the groups. Of course, for the aggregation, it makes sense to use a local array in the form:

agg(category, priority, type) = total

Such that for each record in the input array I can just:

Introduction

If you're solving complex problems in ObjectScript, you probably have a lot of code that works with %Status values. If you have interacted with persistent classes from an object perspective (%Save, %OpenId, etc.), you have almost certainly seen them. A %Status provides a wrapper around a localizable error message in InterSystems' platforms. An OK status ($$$OK) is just equal to 1, whereas a bad status ($$$ERROR(errorcode,arguments...)) is represented as a 0 followed by a space followed by a $ListBuild list with structured information about the error. $System.Status (see class reference) provides several handy APIs for working with %Status values; the class reference is helpful and I won't bother duplicating it here. There have been a few other useful articles/questions on the topic as well (see links at the end). My focus in this article will be on a few debugging tricks techniques rather than coding best practices (again, if you're looking for those, see links at the end).