Best practices for Streams in Interoperability

Discussion

#Interoperability #JSON #InterSystems IRIS

I would like to know which are the best practices of using Streams in Interoperability messages.

I have always use %Stream.GlobalCharacter properties to hold a JSON, or a base64 document, when creating messages. This is fine and I can see the content in Visual Trace without doing anything, so I can check what is happening and resolve issues if I have, or reprocess messages if something went wrong, because I have the content.

But I think this is not the best way of using Streams. After a couple of years, I ussually have space problems: messages seems not to purge correctly (I don't know yet if it's because the use of %Stream.GlobalCharacter, or it's just a coincidence).

I have asked InterSystems, and they recomended me to use QuickStream instead of %Stream.GlobalCharacter. But if I choose this way, I loose visibility on Visual Trace (unless I write the content with a $$$LOGINFO or something like that, which doesn't convince me), and I think I have read somewhere that QuickStream content dissapear after ending the process (I mean, it's not persistent, which is fine to avoid space problems, but not to resolve issues).

So, I want to ask the community: which are the best practices? What you recomend me?

Thank you in advance :)

Tani Frankel · 7 hr ago

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.

1 0

Stephen Canzano · 2 hr ago

One important note about QuickStream. If you decide to go down this path you must make certain to Clear the QuickStream as part of your pipeline. The Message Purge that is set up as a task will purge the message header and the associated message body but when it looks at the message body all it sees is a property called QuickStreamId and it doesnt know it should also Clear the associated QuickStream object.

0 0