AllAccepted answers
Eduard Lebedyuk · Sep 26, 2025

%Close is called automatically. Consider the following example:

Class Utils.GC Extends %RegisteredObject
{

Property Type As %String;

/// do ##class(Utils.GC).Test()
ClassMethod Test()
{
	set obj = ..%New("explicit")
	kill obj
	
	do ..Implicit()
}

ClassMethod Implicit()
{
	set obj = ..%New("implicit")
	// obj will be removed from memory after we exit current method/frame.
}

Method %OnClose() As %Status [ Private, ServerOnly = 1 ]
{
	Write "%Close is running: ", ..Type,!
	Quit $$$OK
}

Method %OnNew(type) As %Status [ Private, ServerOnly = 1 ]
{
	Set ..Type = type
	Quit $$$OK
}

}

Here's the output from the Test method:

HCC>do ##class(Utils.GC).Test()
%Close is running: explicit
%Close is running: implicit
Eduard Lebedyuk · Sep 17, 2025

Are you on Linux? Use JDBC. ODBC Snowflake driver is incompatible with IRIS because it uses a backtrace() syscal which causes signal 11 in IRIS process if the process is running in a background.

Snowflake ODBC driver uses backtrace to determine Driver Manager on Linux, so currently it does not work on Linux at all with IRIS.

Eduard Lebedyuk · May 20, 2025

You're welcome. Here's a bit more info about how BPL BPs work. After you compile a BPL BP, two classes get created into the package with the same name as a full BPL class name:

  • Thread1 class contains methods S1, S2, ... SN, which correspond to activities within BPL
  • Context class has all context variables and also the next state which BPL would execute (i.e., S5)

Also BPL class is persistent and stores requests currently being processed.

BPL works by executing S methods in a Thread class and correspondingly updating the BPL class table, Context table, and Thread1 table where one message "being processed" is one row in a BPL table. After the request is processed, BPL deletes the BPL, Context, and Thread entries. Since BPL BPs are asynchronous, one BPL job can simultaneously process many requests by saving information between S calls and switching between different requests.
For example, BPL processed one request till it got to a sync activity - waiting for an answer from BO. It would save the current context to disk, with %NextState property (in Thread1 class) set to response activity S method, and work on other requests until BO answers. After BO answers, BPL would load Context into memory and execute the method corresponding to a state saved in %NextState property.

That's why registered objects as context properties can (and would) be lost between states - as they are not persisted.

Eduard Lebedyuk · May 19, 2025

HS.FHIR.DTL.vR4.Model.Resource.Patient is a registered object and not a persistent object, so there's no guarantee it will exist beyond a current BP State. You set context.patient in "Transform 1", so it will be gone from process memory after "Send to FHIR Repo 1" sends the request, but before it gets the reply back.

As a solution you can serialize FHIR resource to json and persist that.