Hi Sergey,

Thanks for these steps. I'm trying this with Angular 7 as its component architecture really saves my time to learn. 

Yet as I want to migrate the project into a CSP application, I get lost at some points. For simplicity, let me start with a new angular project "my-app" which is created by the "ng new" command and can be run successfully by "ng serve". Up to here, it means to me I have already done Step (1). 

Now I go to Step (2). I defined my CSP application path "/my-app". Then in my "ng build" command, specify the --output-path to that CSP application physical directory. Then I modify every occurrence of the src import in index.html with the "/my-app/" prepended.

Then I test the the URL of index.html in the browser.  But the page is not loaded. It is not a 404. It is just a blank page.

Do you see anything I have missed out or gone incorrectly?

Thanks for such great works! Your prototype has helped me speeding up a lot for preparing a demo kit integrating Angular and Ensemble Workflow.

I'm a newbie to Angular and I know it's popular. In Ensemble Workflow, the field %FormFields are treated as simple %String's only. I'm considering to extend the class  EnsLib.Workflow.FormEngine, such that it would process the fieldname:type tuples, e.g.:

"DocumentLink:TEXT,Photo:FILE,DisclaimerAgreed:CHECKBOX"

etc., and draw the HTML form accordingly as follows:

<input type="text" name="DocumentLink" /><input type="file" name="Photo"/><checkbox name="DisclaimerAgreed"/>

Or else, I would handle this entirely in Angular.

Which approach would you recommend? 

I think I know the reason. For the table I was giving SQL queries against in that RESTful web service, it corresponded to a particular DB and the resource and role representing it was %DB_XXX. However, even if I added this %DB_XXX to the list of Application Roles of that CSP path, the UnknownUser still didn't have the sufficient right to access that table, because %DB_XXX didn't include the rights to specific SQL tables.

If later I created a new role, copying from %DB_XXX, and in addition to it I gave the CRUD rights to my target tables, then added this new role to the list of Application Roles of my CSP path, the dynamic SQL could be run and return results even with UnknownUser.  

Just encountered the similar situation when following the exercise of building a RESTful web service in the Learning Service... if I ran the simple GET which requires running a dynamic SQL at the back, it gave me empty results if I did it with UnknownUser, while something returned for SuperUser.

Then I tried adding all possible roles except %ALL to that web application as "Application Roles" (automatically added to the current role set). Yet still the Dynamic SQL wouldn't return me anything. Again, I tried adding the last %ALL to confirm that working with it, and it did.

It seems to me there are something other than those available roles required to be granted or added, in order to run dynamic SQL in a RESTful web service. Just realise this post was written about 18 months ago, and wonder if someone could shed me light on it.

Thanks for the sharing, Eduard. That is a good demonstration of the use of -volume in the docker run command.

In the situation of bringing up multiple containers of the same InterSystems IRIS image (such as starting up a number of sharding nodes, etc.), the system administrator may consider organising the host by some files/folders among instances as sharable but read-only (such as the license key, etc.), and some as isolated yet temporary. Maybe we can go further and enhance the docker run command in this direction, so that the same command with a small change (such as the port number and the container name) is enough for starting up a cluster of instances quickly.