#Embedded Python

In the previous article, we used pyprod to create production components while relying on the UI for production configuration. That same production can now be defined entirely in Python:

from intersystems_pyprod import Production, ServiceItem, ProcessItem, OperationItem

iris_package_name = "HelloWorld"

class MyProduction(Production):
    services = [
        ServiceItem(
            "MyServiceName",
            "HelloWorld.MyService",
            host_settings={"target": "MyProcessName"},
        )
    ]
    processes = [
        ProcessItem(
            "MyProcessName",
            "HelloWorld.MyProcess",
            host_settings={"target": "MyOperationName"},
        )
    ]
    operations = [
        OperationItem("MyOperationName", "HelloWorld.MyOperation")
    ]

In the previous IoP article, I showed how IoP can expose Python messages to DTL by generating JSON schemas. That is useful when the message is primarily a Python object and we want the IRIS tooling to understand its structure.

This time, the direction is a little different.

Starting with IoP 3.7.1, a PersistentMessage can now be a native IRIS message body class. The Python class is still the source code you write, but the generated IRIS class extends Ens.MessageBody

With Embedded Python and the Native API, it is becoming increasingly natural to write part of IRIS application logic in Python. But one question quickly comes up: how can you manipulate IRIS persistent objects from Python without losing the connection to the native object model, class dictionary, indexes, storage, and SQL projections?

iris-persistence explores that question. The project provides a Python object persistence layer for InterSystems IRIS, inspired by %Persistent

InterSystems IRIS globals are one of the platform's core strengths: they store hierarchical data in a direct, ordered, and efficient structure. But when working from Python, manipulating globals can sometimes feel closer to a low-level API than to the natural habits of the language.

The iris-global-reference project provides a Python layer on top of IRIS globals. Its goal is simple: make access to globals more readable, more idiomatic, and easier to integrate into modern Python code, without hiding the underlying hierarchical model.

When developing Python applications with InterSystems IRIS, you can quickly end up with several execution contexts:

• Python launched directly by IRIS with Embedded Python;
• a regular python3 process that loads the Embedded Python libraries from a local IRIS installation;
• an external Python application that connects to IRIS through the official native driver.

These three cases are useful, but they do not behave exactly the same way for imports, system configuration, object APIs, and SQL access.

Data privacy regulations such as GDPR, LGPD, and HIPAA demand that organizations know exactly where Personally Identifiable Information (PII) lives inside their databases. Yet in practice, most teams rely on manual inventories, tribal knowledge, or external scanning tools that require data to leave the database engine — a process that itself creates privacy and security risks.

This article presents an MVP that takes a different approach: it runs PII detection inside InterSystems IRIS using Embedded Python, analyzing data where it lives and never exporting it to an external process.