In general (and messages and streams are just one example) there is a trade-off between more traceability and visibility vs. storage/space (and performance).

QuickStream is indeed a mechanism used internally to address the performance and storage concerns, but, to complete this with a traceability option, there is also a dedicated Business Operation that can add the desired data - see Enhanced Debugging and the introduction of HS.Util.Trace.Operations. This simply adds more calls in the session, to this Operation which (could) include the stream data. The advantage of this is that you can turn it on or off, and you can control also the "level" of tracing. Take into account of course that this needs to be done ahead of what you want to trace/visualize, you can't "apply" this retroactively.

Hi Dmitrii,

From the discussion in the comments it seems like you're trying to use "Workers", but did you try to use the Event mechanism for your use-case?

See also this related article (and this one as well).

By the way here's a Docs reference of using this from Python.

I don't have a wider context of this, but in the IRIS Interoperability functionality, behind the scenes of the Interoperability components, and the Messages and Queues managed there, this Event mechanism is used. So perhaps if you are already using IRIS's Interoperability capabilities, you can implement this in the higher level of the Business Components in your Interoperability Production, rather than with the lower level code using the Event class.

The Workers mechanism you tried to use is intended more for distributing parallel work, and the Event API is more for messaging and queuing scenarios, which sounds more like your use-case.

This article might also be of interest to you as it discusses moving from "Workers" to "Events".