I'll be interested to see others' thoughts on this as well, but one approach is:

  • Create a new empty database for the globals
  • Use GBLOCKCOPY or MERGE to copy each of the globals from the current DB to the new globals DB. I believe GBLOCKCOPY is faster than MERGE.
  • After they are copied/merged to the new DB kill the globals in the currrent DB. This then becomes your routines DB.

Or you can do the opposite and export all of your routines from the current DB, import them into a new routines DB, then delete them from the current DB which becomes your globals DB. This would be faster than the first approach unless your globals are really small.

Here's a working example using <img> in a <table>. I don't think you can put an <img> inside an <item> or inside another <img>.

<table orient="col">
            <block width="40%">
                    <img src="http://localhost/logo.jpg" contentHeight="0.56in" contentWidth="2.33in" style="text-align:left"/>
            <block width="40%">
                <table orient="col">
                        <item field='#(..pagetitle)#'/>
            <block width="20%" style="text-align:right;">
                  <item field='#(..subtitle)#'/>

Here is the section in the docs that explains why this is happening and why @Eduard Lebedyuk asked if that class is persistent.

Business Process Execution Context

The life cycle of a business process requires it to have certain state information saved to disk and restored from disk, whenever the business process suspends or resumes execution. This feature is especially important for long-running business processes, which may take days or weeks to complete.

A BPL business process supports the business process life cycle with a group of variables known as the execution context. InterSystems IRIS automatically save the variables in the execution context and restores them each time the BPL business process suspends and resumes execution.

There's no option for %DisplayFormatted to split the results into multiple parts automatically. You would need to write a custom method to do your CSV output with the logic you need. I can post some sample code that outputs CSV if that would be helpful.

8 hours for 16 million records at ~140 bytes/record seems really slow. I just did a test on a slow Windows VM and for a simple "SELECT *" for 16 million records @ 150 bytes/record, %DisplayFormatted took about 18 minutes to output the 2.4 GB CSV.

I suggest you contact the WRC to help look at where the bottleneck is.

%XML.Reader and %XML.Document won't automatically update the original stream. You need to use %XML.Writer to output the %XML.Document into a stream.

set writer=##class(%XML.Writer).%New()
set outStream=##class(%Stream.GlobalCharacter).%New()
set tSC=writer.OutputToStream(.outStream)
set tSC=writer.Document(document)
write "Stream:[",outStream.Read(3000000),"]",!

File Specs for services support wildcards, but not the complex time stamp specifications that are used for outputting filenames from an operation.

File Spec
Filename or wildcard file specification for file(s) to retrieve. For the wildcard specification, use the convention that is appropriate for the operating system on the local InterSystems IRIS Interoperability machine.


You can definitely do the OAuth requests using basic HTTP calls.

Doing it in OnInit won't work because the token you receive has an expiration time.

You'll need to:
- For every message your Operation receives you'll need to check if the cached token's expiration time has passed (or if there's no cached token).
- If you need a new token, do your POST call to get a new token and cache it.