When you have || in Id, it usually means, that you have additional Index by two or more fields, and marked as IdKey. Something like this.

Property RollNo As %String;

Property Marks As %String;

Index RollNoMarks On (RollNo, Marks) [ IdKey, Unique ];

Here we have some two properties, to store both values separately, but we used both of their values as IdKey.

Now it is possible to check of existing an object by ##class(User.School).%ExistsId(RollNo_"||"_Marks), or open id by  ##class(User.School).%OpenId(RollNo_"||"_Marks)

But in additional to this system methods, we now have some new ones which construct with index name and "Exists", "Open" and so on. But call will be a bit different. You should pass all values separately in this way.

##class(User.School).RollNoMarksExists(RollNo, Marks)

##class(User.School).RollNoMarksOpen(RollNo, Marks, , .sc)

You can try any of these ways, and you should remember about Status variable, which may help you to understand what's happening.

do $system.OBJ.DisplayError(sc)

will decode status

It's actually a very interesting question, and actually mostly depends on what you really want to achieve.

First of all, you can redefine Dockerfile name in docker-compose.yml

version: '3.7'
services:
  myapp:
    build:
      context: .
      dockerfile: Dockerfile.test

or just in docker build

docker build -f Dockerfile.test .

But there is another use case when you would need even different docker-compose.yml files. If you would want to split running like in the production and development environment.

You can just do it this way, 

docker-compose up --build -f docker-compose.prod.yml

docker-compose up --build -f docker-compose.dev.yml

But I would recommend a bit different way, based on the possibility to extend one YAML file with the content of another.

So we need main docker-compose.yml

version: '3.7'
services:
  iris: 
    extends:
      file: docker-compose.${MODE:-dev}.yml
      service: iris
    ports:
      - '${WEBPORT:-52773}:52773'

which in fact declares just common settings, which will be the same for dev and prod.

Then look at docker-compose.dev.yml, for example I'm using IRIS community edition for development

version: '3.7'
services:
  iris: 
    image: store/intersystems/iris:2019.3.0.302.0-community
    volumes:
      - ./src:/opt/myapp/src

and docker-compose.prod.yml, and licensed version for testing production environment

version: '3.7'
services:
  iris: 
    image: store/intersystems/iris:2019.3.0.302.0
    volumes:
      - ~/iris.key:/usr/irissys/mgr/iris.key

By default when you will start docker-compose environment, it will use dev. Because here ${MODE:-dev} it uses environment variable MODE with default value as dev. Then, you can change it this way.

MODE=prod docker-compose up --build

But you can also create file .env with values for any environment variables which you would like to redefine. So, in our case it can be like this, with changed WEBPORT as well.

MODE=prod
WEBPORT=52774

It is not a big problem to make it with Caché. But I would recommend you to look at different ways. Using Caché just as a reverse proxy, looks like a sledgehammer to crack a nut.

First of all, you should go from an original source of users, I don't see it in your question, but it can be LDAP/AD or something else outside of Caché. 

I would look at Nginx for example, which is actually very flexible.

Have you looked at @Daniel Kutac series of articles about OAuth2? In part 3 he mentioned about debugging. Kind of like this should help you.

set ^%ISCLOG=5
set ^%ISCLOG("Category","OAuth2")=5
set ^%ISCLOG("Category","OAuth2Server")=5

There is an option in the settings: "objectscript.export.addCategory",  when it's set to true, it will add categories for different file types.

In uppercase CLS for files "cls",  and RTN for "int", "mac", "inc".

The next coming version will support the way to have more control over it, where the left side for extension of a file, and the right part for a category name

"objectscript.export.addCategory": {
  "cls": "_cls",
  "mac": "_mac",
  "int": "_int",
  "inc": "_inc"
}

Remember about the second parameter in methods like Get and Post, which named test, which you can use for debugging purposes.

 If test is 1 then instead of connecting to a remote machine it will just output what it would have send to the web server to the current device, if test is 2 then it will output the response to the current device after the Get. This can be used to check that it will send what you are expecting.

Just install this extension for Docker, and you will be able to up, and down compose configuration, from the context menu on file, or from the command palette. 

And of course, after that, you will be able to set any shortcut for those commands

Another solution would be to use tasks in VSCode. So, you can add new or edit file .vscode/tasks.json, with content like this.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Compose Build",
      "type": "shell",
      "command": "docker-compose build",
    },
    {
      "label": "Compose Up",
      "type": "shell",
      "command": "docker-compose up",
    }
  ]
}

And by command Run task from the command palette, it will offer to select which task to run.

As you getting <STORE> error, it is related to the process's memory. So, I think you can solve it easily by increasing the value of maximum memory per process.

It should be by default 256Mb, but, maybe you have too much CSP files. Just temporarily increase maximum memory per process may solve the issue.

What do you mean? There are still Ensemble.inc