Solved in comments.

Hi, Rubens!

Thanks for sharing this!

I like to see UDL code in sources and folder=package structure for the source code.

Few ideas:

Why not save code without txt extention? Cls would go with .cls, include files with .inc and etc, like in this project, or  this project or in that one.

Would you please share a small screencast video of the general use cases which shows the key advantages and benefits?

Thank you in advance!

PS: Look at the source code %occMessages.inc - there's a lot of tasty there ;) or read the article in my blog...

This is the article.

Search engine is the next in dev queue, hope we'll fix it soon.

Ponnumani, you can search also with google search within community.intersystems.com.

E.g. for angular phrase.

Hi, Arockia!

InterSystems Caché is multi-model DBMS - see the official information. Caché comes with 3 models "out-of-the box": Globals, SQL, Caché Objects.

Everything in Caché is stored in Globals, which are multidimensional key-value indexed variables with persistent nature.  The good visible explanation of "what is global" you can find in this Merge command article, or in @Rob.Tweed's article.

"Multi-model" means that:

- you can store data in the same database with different data models simultaneously.

- you can access the same data via different data engines if the data models are compatible: e.g.  you can operate with same data via Caché SQL, Caché Objects and Globals because they are compatible. Need to notice, that if you want to access globals, which are part of storage schema for Caché Objects and SQL it is safe to access only for read manipulations(or you should be very confident in what are you doing). For other types of manipulation better use documented model-related functions.

- you can use the data models which come "out-of-the box" (Globals, SQL, Caché Objects) and you can implement your own data-manipulation library with Caché ObjectScipt or bindable languages which would store the data in Globals in your own way, structure and logic. Using this approach you can implement literally any data model e.g. graph, document store, key-value, your-own-unique-extraordinary-database-model, but you would be responsible for the  support as well ;)

Hope that helps.
 

Hi, Lasse!

Thanks for the input.

It's not off topic, but a new good question. Would you please introduce it as a new question  regarding security setup in REST and refer to the article? 

You can use member mentioning to ping the member you want to participate in discussion. 

Thank you in advance!

Pinging web socket experts @Nikita.Savchenko and @Fabian.Haupt.

Also see Fabian's article about web sockets, HTH.

Hi, Vibha! Why do you need that? Why not create new namespace and start there?

I would not recommend you to develop anything in SAMPLES namespace. One of the reasons why not is that it would be erased and updated with every Ensemble version update.

If you want the packages from samples you can easily transfer them to your new namespace.

The Webinar is available on InterSystems Developers YouTube Channel too. Please welcome:

https://www.youtube.com/embed/flyLkIYCdFo
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]

Please welcome!  

Put the formal answer here as Jeff answered in comment

Hi, Sylvain!

See the article about it.

Hi, Ponnumani!

Please see some introductory articles from @[Benjamin.deBoe] e.g. Getting started with Text Categorization, iKnow demo apps (part 1) - Knowledge Portal, iKnow demo apps (part 2) - Set Analysis demo, iKnow demo apps (part 3) - Dictionary Builder Demo, iKnow demo apps (part 4) - Rules Builder Demo, and I would suggest to see all the Benjamin's articles and I'm sure articles with iKnow tag would be helpful for you too.

And please see this iKnow playlist on Developer Community video channel.

If you can share something which even not cover $LB it would be already suitable for a lot of "Config-in-Global" cases.