Hi Luis,

Regarding the first alert, it indicates that a failover has occurred. This is not an error in itself, but a signal that the previous primary node went down and that this instance took over. From this node's perspective, it’s benign, but it’s important to investigate the original primary, as it may still be down or unstable.

For the <PROTECT> KillAlive+1^%SYS.CDIRECT message, this is less common. I’ve seen similar cases where it was related to the "IRISLIB" database being moved or having incorrect permissions. It would be worth checking that all system databases are in their expected locations and that the filesystem permissions are correct, especially in your durable storage path.

If the issue persists after verifying that, I’d recommend opening a WRC case so it can be analyzed in more detail.

If you use IRIS, the easiest and cleanest way to interact with AWS S3 is by using embedded Python and the boto3 library, which is the official AWS SDK for Python.

IRIS allows you to write class methods with Language = python, so you can write pure Python inside your ObjectScript classes. Here’s a simple example of listing objects in an S3 bucket:

Class MyApp.S3Utils
{

ClassMethod ListS3Objects(bucket As %String = "your-bucket-name") [ Language = python ]
{
    import boto3

    s3 = boto3.client("s3")
    response = s3.list_objects(Bucket=bucket,Prefix="your_folder")

    contents = response.get("Contents", [])
    for obj in contents:
        print("Key:", obj["Key"])
}

}

To call this method from ObjectScript:

Do ##class(MyApp.S3Utils).ListS3Objects("my-s3-bucket")

Just make sure the Python environment IRIS is using has boto3 installed:

pip install boto3

If you’re working with Ensemble, which doesn’t support embedded Python, you can still achieve the same result by calling a Python script externally using $ZF(-1):

Set cmd = "python3 /path/to/your_script.py"
Set status = $ZF(-1, cmd)

This way, you can keep the S3 logic in a Python script and still integrate it with Ensemble.

The CSPSystem user has probably been disabled because it has not been active for so long. You can connect to the terminal and use the ^SECURITY routine to display all the users and check the ones disabled. 

If this doesn't work and you need access quickly, contact the WRC. 

Hey @Dmitry Maslennikov , awesome job!

Have you thought about using WebSockets with a simple HTML/JS setup for your terminal, as the VS Code extension does? If you've already tried that and moved on, I’d love to know why. If not, it’s a super easy approach, and I’m sure you’ll have it working in no time.

Just create a WebSocket connection:

const socket = new WebSocket("ws://localhost:8273/api/atelier/v8/%25SYS/terminal");

Then hook it into your terminal like this:

term.onData(data => socket.send(data)); // Send input to the server

I did some tests and got a working terminal. It’s not as smooth as VS Code Lite or yours, but it's close! Let me know if you want to dive deeper.

I think this is not working anymore. I tried installing the v2.12.6 but got the message that the extension is not available from Visual Studio Code for the Web 🙁

I am having this same problem and I am using the latest extension. 

I added the 

"http.proxyStrictSSL": false

to the User settings.json , which is the same as

But still getting the error: 
 

Check your server details in Settings (vgorillaaws[VGORILLA]).

request to https://ec2-x.x.x.x.us-east-2.compute.amazonaws.com/api/atelier/ failed, reason: self signed certificate

I am using [2.5.0] - 2024-05-02 InterSystems Language Server

Great article!

I've gained a clearer understanding after reading it. However, I'm struggling a bit with your example. It seems a bit complex, especially for those of us who are new to integrating ObjectScript with custom Python classes and routines. A more straightforward example would be really helpful.

Your code particularly draws attention to the use of this class:

ClassMethod GetPythonInstance(
	pModule,
	pRemoteClassname) As %SYS.Python
{
    set importlib = ##class(%SYS.Python).Import("importlib")
    set builtins = ##class(%SYS.Python).Import("builtins")
    set sys = ##class(%SYS.Python).Import("sys")

    set module = importlib."import_module"(pModule)
    do importlib."reload"(module)

    set class = builtins.getattr(module, pRemoteClassname)
    return class."__new__"(class)
}

Could you elaborate on the rationale behind this specific structure, particularly the inclusion of builtins, importlib, and sys? Is there a simpler alternative you might suggest?

In my own projects, I've been using embedded Python with the Python tag, which usually is enough due to its simplicity and speed. However, as you mentioned, it lacks certain features. Eventually, I end up with numerous embedded functions, repeatedly importing the same libraries for each method, which looks cluttered. See:
 

ClassMethod moveFile() [ Language = python ]
{
    import boto3,iris
    # do stuff
}

ClassMethod getFile() [ Language = python ]
{
    import boto3,iris,json,datetime
    # do stuff
}

At this juncture, adopting your strategy to transfer all code to a .py file (not as a class) seems like a viable option, then accessing these methods via ObjectScript. I'm inclined to avoid Python classes due to their complexity and the need for instantiation. I prefer using functions for their simplicity and ease of understanding. What would you recommend in this scenario? How would calling code looks like? 
 

This is not a nice error to see in a production environment. If this is a production site, I recommend contacting the Support department. 

To find the problem, you can look at the messages.log. There should be an error written with more details.

Most of the time, these errors are related to disk permissions or disk stress. Tools like ^SystemCheck and/or ^SystemPerformance will gather the required information to diagnose the problem. If you contact Support, they will probably ask for this.