I know IRIS has a built-in testing framework, but I'm not sure how to write tests that validate the full message flow through a Production without depending on external systems. Do you mock Business Operations? Is there a pattern you use to test integration scenarios in an isolated and repeatable way?

I've seen that %JSON.Adaptor makes it easy to serialize and deserialize objects to JSON, but I've also seen people building custom serialization logic. Are there scenarios where %JSON.Adaptor falls short, such as handling nested objects, null values or custom field naming conventions? What has been your experience?

If I need to add or change properties in a message class that is already being used by a running Production, what is the safest way to do this? Are there risks with existing messages in the queue or in the message store? Is there a migration strategy the community recommends?

I understand that Business Rules can be used to route or transform messages without touching code. But I'm not clear on when it's better to use a Business Rule versus handling the logic directly inside a BPL or a custom BP class. What criteria do you use to decide between them?

In .NET projects I usually rely on appsettings per environment. In IRIS Productions, settings are stored per component and seem tied to the namespace. What strategies do you use to manage different configurations across environments without manually changing settings every time you promote a Production?

I have several Business Operations that share similar behavior, like building HTTP headers or parsing a specific response format. In C# I would extract this into a service class or a base class. What is the recommended way to do this in IRIS? Should I use a utility class, a common superclass, or is there another pattern the community prefers?

I have a Business Process that needs to call an external API that may take several seconds to respond. I'm worried that keeping the BP blocked waiting for the response could affect the overall Production throughput. Is there a recommended pattern for handling async calls inside a BPL or custom BP class to avoid this kind of bottleneck?

What tools or techniques do you use to debug a Production during development? I know the Management Portal shows the message queue and event log, but I'm wondering if there are better ways to trace a message through the full BS > BP > BO flow without relying only on logs.

What is the recommended way to handle errors inside a Business Process in IRIS? Should I use Try/Catch within the BPL, return error responses to the caller, or rely on the built-in retry mechanism of the Production? Looking for guidance on what's considered good practice.

When building a Production, should I create separate message classes for each integration flow, or is it acceptable to reuse generic request/response classes across different Business Operations? I'm trying to understand how to keep things organized as the number of integrations grows.

I'm learning about Productions in InterSystems IRIS and I understand the basic roles of Business Service, Business Process and Business Operation. But I still get confused about where exactly to put certain logic. For example, if I need to validate a message before routing it, should that validation live in the Business Service or at the beginning of the Business Process? What's the recommended practice?

For those who learned Caché ObjectScript from scratch: what kind of personal or practice projects did you build to get comfortable with the language? I come from a C# background and I'm looking for project ideas that are small enough to be feasible but meaningful enough to actually teach the core COS concepts.