This is a rather common misunderstanding. The naming GLOBAL was created in the 60ties. Long before any other programming language even had anything named Global or similar.
GLOBAL in Caché is a persistent storage component that builds the backbone of (SQL) Tables and Persistent Objects.
$LIST(list,position,end) returns a “sublist” (an encoded list string) containing the elements of the list from the specified start position through the specified end position (inclusive). If position and end specify the same element, $LIST returns this element as an encoded list.
In the development stage, programmers should have full access but data are anonymized.
In the test stage - only some qualified developers get limited access
in the production stage, neither users nor developers should have access to the studio or terminal. Access is given only temporary, to top experts for error analysis. That's like the doctors that take care of places of your body you won't' show to anybody else.
But you can't prevent them from writing code with similar functionality. And run it. And then you have the same SYSTEM privileges as your Caché installation has.
It might be hard to block it.
For stronger security block all developers on production systems.
- mount the copy of the DB as an additional DB to your Test Environment READ ONLY. e.g directory C:\InterSystems\Cache\myCopyDB\ - Using Extended Global References you copy whatever global your need.
e.g. merge ^my.Global = ^|"^^C:\InterSystems\Cache\myCopyDB\"|my.Global
This is a rather common misunderstanding.
The naming GLOBAL was created in the 60ties.
Long before any other programming language even had anything named Global or similar.
GLOBAL in Caché is a persistent storage component that builds the backbone of (SQL) Tables and Persistent Objects.
see this documentation: Using Caché Globals
Excellent & valid comment !
I didn't think of this difference before.
the data property is a standard HTML page.
I'm not aware of some function in Caché that converts HTML to JSON.
But asking Google "convert HTML to JSON" shows that this a standard feature in JavaScript.
so I see 2 options:
- write your own parser (or someone in the community has done this before ???)
- call an external tool (eg. node.js) to it for you
see: https://stackoverflow.com/questions/34504050/how-to-convert-selected-html-to-json
or https://stackoverflow.com/questions/12980648/map-html-to-json
or https://stackoverflow.com/questions/43469412/convert-html-source-code-to-json-object
I prefer this solution as it is in full accordance with the documentation and
with no need also for beginners to fiddle into internals .
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_flist
<snip>
</snip>
I miss Public { } in your example
it ensures that only parameters are visible as <Private variables> or all %*
did you try to Save your Stream.Container ?
set tSC = tRequest.%Save()
before
set tSC = ..SendRequestAsync(..TargetConfigNames,tRequest)
my personal rule:
Access is given only temporary, to top experts for error analysis.
That's like the doctors that take care of places of your body you won't' show to anybody else.
Yeah!
you can lock out developers from SMP.
But you can't prevent them from writing code with similar functionality. And run it.
And then you have the same SYSTEM privileges as your Caché installation has.
It might be hard to block it.
For stronger security block all developers on production systems.
I like the second solution!
really excellent
#3 in details:
- mount the copy of the DB as an additional DB to your Test Environment READ ONLY.
e.g directory C:\InterSystems\Cache\myCopyDB\
- Using Extended Global References you copy whatever global your need.
e.g.
merge ^my.Global = ^|"^^C:\InterSystems\Cache\myCopyDB\"|my.Global