I have not looked at RESTForms, so I can only provide a biased opinion on the DynamicObject Adapter.

We have used this for REST CRUD interfaces. This enabled us to use the same message structure classes for SOAP, REST XML and REST JSON interfaces. On the REST interfaces we use the ContentType to determine whether we should use the XML Reader to parse or the DynamicObject adapter. After the parsing, we encapsulate the message instance in an Ensemble message to invoke a business service in the cases where it is not just CRUD.

Great stuff. Thanks. Where can I get the sample files and/or some instructions on the use of Kubernetes as demonstrated?

Thanks. I think that is one of the sessions I wanted to attend, but never got to it. I still need to go watch all the ones I wanted to attend, but had to choose between sessions or got pulled into meetings.

Thanks for the post. I am looking forward to 2019.1.

Regarding the following statement:
"application>.disp: dispatch class ready to use in the CSP application. It extends %CSP.REST and define the XData UrlMap. This class is read-only and marked as system class (by default is hidden in Atelier)."
- My opinion is that is should not be hidden by default. I would like to add it to the git repo to package it with a version.

A question on the "impl" file. What happens if I have implementation code in it already and get an updates Swagger and generate it again? Does is overwrite the code or does it keep my code and add the new methods, etc.?

Hi Evgeny,

Thank you for the suggestion.

We still then need to keep on developing primarily on Ensemble and once we release, then we create a release file for IRIS, which sounds good. This does create the risk of testing something on Ensemble and it maybe does not work on IRIS.

Every project has its own set of classes as well in addition to the shared code libraries. On these project specific classes, we may want to use new IRIS features. This creates the issue that I can't develop on Ensemble and only build and IRIS release. Not sure if you understand what I am getting at. The idea was that if a dev works on one of these projects, he/she only changes the server connection in Atelier, synchronise, compile and work. If that person needs to work on another project on Ensemble, the repeats the steps above. The git repo takes care of the source management, even though we are on different InterSystems products.

We use a local git repository on one of our servers.

Missed that bit. I was only looking at the part I wanted. Such a typical developer thing to do wink

Thanks. Appreciate it. If  I'm writing a method that uses this class in another namespace, I should be able to just zn to %SYS in the code in order to use the class.

Thanks. I will try from the %SYS namespace. I was trying to access it in another namespace. It also does not show in the class explorer. One of those "hidden" features.

I am using Ensemble 2017.2 and the Config.MapGlobals query is not available.

Do you know how I can list the mapped globals of a namespace on 2017.2?