I enjoy the challenge of being in a contest. Currently I participate in InterSystems IRIS with REST API Programming Contest. My idea for this contest was to create an app to help me keep track of tasks for my Status Reports. I started with the template provided by Evgeny Shvarov. I created a persistent class for Tasks and a REST Dispatch class. I defined my URL map and I even figured out how to test my REST app using Postman.

Hi developers!

I just want to share with you the knowledge aka experience which could save you a few hours someday.

If you are building REST API with IRIS which contains more than 1 level of "/", e.g. '/patients/all' don't forget to add parameter 'recurse=1' into your deployment script in %Installer, otherwise all the second and higher entries won't work. And all the entries of level=1 will work.

/patients

- will work, but

/patients/all

- won't.

Here is an example of CSPApplicatoin section which fix the issue and which you may want to use in your %Installer class:

    <CSPApplication Url="${CSPAPP}"
      Recurse="1"
      Directory="${CSPAPPDIR}"
      Grant="${RESOURCE},%SQL"
      AuthenticationMethods="96"
      />

Here is an ObjectScript snippet which lets to create database, namespace and a web application for InterSystems IRIS:

    set currentNS = $namespace

    zn "%SYS"

    write "Create DB ...",!
    set dbName="testDB"
    set dbProperties("Directory") = "/InterSystems/IRIS/mgr/testDB"
    set status=##Class(Config.Databases).Create(dbName,.dbProperties)
    write:'status $system.Status.DisplayError(status)
    write "DB """_dbName_""" was created!",!!


    write "Create namespace ...",!
    set nsName="testNS"
    //DB for globals
    set nsProperties("Globals") = dbName
    //DB for routines
    set nsProperties("Routines") = dbName
    set status=##Class(Config.Namespaces).Create(nsName,.nsProperties)
    write:'status $system.Status.DisplayError(status)
    write "Namespace """_nsName_""" was created!",!!


    write "Create web application ...",!
    set webName = "/csp/testApplication"
    set webProperties("NameSpace") = nsName
    set webProperties("Enabled") = $$$YES
    set webProperties("IsNameSpaceDefault") = $$$YES
    set webProperties("CSPZENEnabled") = $$$YES
    set webProperties("DeepSeeEnabled") = $$$YES
    set webProperties("AutheEnabled") = $$$AutheCache
    set status = ##class(Security.Applications).Create(webName, .webProperties)
    write:'status $system.Status.DisplayError(status)
    write "Web application """webName""" was created!",!

    zn currentNS

This code snippet is an example of a CSP page that has a dynamically reloading table:

This is a quick note on what happens when, on your CSP page, you call a cache script which returns a %Boolean and store that value in a javascript variable.

When you call a script with language="cache" and returntype="%Boolean" from a javascript script, the return value is interpreted as a string, not as a boolean.

Here's an example:

A cache script that returns (in theory) a "false" value:

or "Didn't you say you would cover Persistent Objects in Part 5, Chris?"

Yes, that was the plan. This is a pretty important topic, so it get's its own Article

Up until now, we've display widget JSON that has been created by a basic loop. Clearly this isn't of much value. Now we have our stack connected together, and we can see that the data is flowing to the Welcome page, it's time to complete the stack and start feeding our service from "real" data.

In our last lesson, we implemented a new REST Service to allow us to perform CRU operations on Widgets, and refactored our Controllers to allow the page setup to be decouple from the content.

Sometimes you can face the situation when you did update the web app on Caché server but you cannot get the newest version of the app in a browser.

Here are couple recipes which help me to solve it. From simplest to more sophisticated and not obvious.

1. Refresh page in a browser

In Chrome it is Ctrl+R or 'Refresh' button. Obvious, but helpful.

2. Hard reset in a browser

If you are in Chrome, open Developer tools

In our last lesson, we implemented a linkage to our WidgetAccessory class, and debugged some errors we encountered along the way. We now have our data being returned by REST, but what if we want to update or add new data to our application?

We finished our last lesson with our Widgets Direct page iterating over a list of widgets, displaying an ID and a Name value. While we have been able to achieve this with only a small amount of coding, the page itself is not the most visually appealing place to be. The AngularJS framework is providing a powerful Model-View-Controller framework for our structure and logic, but it does not implement anything that will provide a nice UI experience.

If you are developing applications that use CSP or Zen, or potentially any of the other InterSystems web-related stuff that's built on top of CSP, then it's important to know how to keep one particular secret.

A central part of the CSP security architecture is a server-side session key. "Server-side" because its value should never be revealed to the client that is issuing the web requests. If it is revealed, a malicious client might be able to use it to bypass your security and make your server do things you don't want it to.

In this recent post I highlighted the importance of a CSP session's Key property in enforcing the level of security your web application may be relying on, and in particular the need to keep the property value secret.