I would like to advise against this course of action, there are several reasons:

  1. Ensemble messages should be as small as possible. If you can pass id only, pass id only, etc. Minimizing message size keeps production efficient.
  2. ResultSet does not contain the data itself, it's more like a compiled instructions on how to get the data. Only when you're calling Next method the data is actually loaded into memory
  3. Results of SQL query should be immediately acted upon, because the older the SQL results, the more they differ with reality. it is best to pass parameters and execute query in-place.

If you want it for debugging purposes you can add a trace event which would store ids only for example, but if you actually need to pass a set of results between different business hosts it may be beneficial to you to rethink the production architecture.

Here's some questions:

  1. What business hosts do you have?
  2. What data do you pass between different hosts?
  3. Can you pass parameters between hosts and execute a query on a target host?
  4. Can you pass not a set between hosts, but rather elements individually?

Some options:

> - Utilize another language or library that has methods to parse the data into an Excel file (https://stackoverflow.com/questions/17684610/python-convert-csv-to-xlsx).

If you want to use Python from Cache, check PythonGateway.

Mimedata is subscripted by name and index.

So in your case:

set name = "BulkFileUpload"
for i=1:1:%request.CountMimeData(name)
    set mimeData = %request.GetMimeData(name, , i)
}

On each iteration mimeData variable would hold the stream with one next mimedata.

%request is simply an object of %CSP.Request class, check the docs or code to know how it works.

Additionally you can use this snippet to see what's inside %request, %response and %session objects:

set %response.ContentType = "html"
do ##class(%CSP.Utils).DisplayAllObjects()
quit $$$OK

Bitmap indices maintain one node per each chunk of 64 000 id's, if at least one id from that range exists. So random integer ids can slow bitmaps down. On the other hand if there are two consecutive but spread (i.e 1..1000 and 100000...110000) id sequences it would generate just 2 global nodes so everything should be ok in that scenario.

Check index global in various scenarios:

 
Example.Bitmap

Eduard, are you referring to the Priority property of the Ens.MessageHeader class?

Yes.

That seems to be used exclusively for marking the message for Async vs. Synchronous delivery.

These priorities are available:

#define eMessagePriorityHighSync 1
#define eMessagePrioritySync     2
#define eMessagePrioritySimSync  4
#define eMessagePriorityAsync    6

Sync by default is 2, so specifying priority 1 may indeed help. Cursory glance at Ens.Queue indicates that messages with priority 1 would be processed first.