Another option to view/monitor opened transactions directly from System Management Portal is to use the System Dashboard (System Operation -> System Dashboard). No need to write code or SQL, just a few clicks.
In System Dashboard there is a line "Transactions":

In case one or more transactions is/are opened for more then 20 minutes (or so...) the System Dashboard shows a Troubled state.

In System Dashboard, if you click the "Transactions" label (regardless of Troubled state) then at the bottom of the page a link "Click here for more details" is displayed:

If/when "Click here for more details" is clicked a page with top 5 transactions (longer time) are displayed:
 

From there you can click the Process ID and go directly to the Process Details page.

Create a Business Service that use Ens.InboundAdapter and in the OnProcessInput() method call your routine, something like:

Class Community.bs.ServiceTest Extends Ens.BusinessService
{

Parameter ADAPTER = "Ens.InboundAdapter";

Method OnProcessInput(pInput As %RegisteredObject, Output pOutput As %RegisteredObject) As %Status
{
	Set result=$$getTicket^production.etl.getTicket()
	Quit $$$OK
}

}


When you add the Business Service to the production set the setting CallInterval to a VERY LARGE interval (like 99999999), this ensure that the BS is called once.
In the BS settings add a schedule that starts the BS every day at 12 and stops at 13:00 (any time you are sure your call has finished), like: START:*-*-*T12:00:00,STOP:*-*-*T13:00:00

Note that no trace will be visible because the BS does not create any message, you may add some entry in the event log to track execution, something like $$$LOGINFO("Running getTicket") and possibly other info/error handling etc. (depends on your code).

The sample you are posting does not work, %JSON.Adaptor is an abstract class and cannot be instantiated, so the line:
set test = ##class(Test.Json).%New()
returns <METHOD DOES NOT EXIST> error.

In order to instantiate it you need to inherit from a non abstract class like %RegisteredObject, here is my test:

Class Community.TestJSON Extends (%RegisteredObject, %JSON.Adaptor)
{

Property bool As %Boolean;
}

Then this is what I get:

set test=##class(Community.TestJSON).%New()
do test.%JSONExport()
{}

Another test:

set test=##class(Community.TestJSON).%New()
set test.bool=1
do test.%JSONExport()
{"bool":true}

I'm using IRIS 2023.3, same as yours.

Maybe you have a different situation than the sample you posted?

First I'd suggest not to use a persistent class "linked" to a message (Ens.Response in this case), Supplier  is linked by your message class in this case.
If you do it, you will definitely create "orphaned" persistent objects when you purge, unless you add some logic (like triggers and callbacks) to delete the "linked" persistent objects when a message is purged.

To avoid this (when possible) a serial class is preferred.

So, the Supplier class would be:

Class Community.App.Msg.Supplier Extends (%SerialObject, %XML.Adaptor)
{
Property row As %Integer;
}

As for the message class:

Class Community.App.Msg.Suppliers Extends Ens.Response
{

Property Supplier As list Of Community.App.Msg.Supplier(XMLPROJECTION = "ELEMENT");
ClassMethod test() As %Status
{
    set XmlString="<Suppliers><Supplier><row>1</row></Supplier><Supplier><row>2</row></Supplier></Suppliers>"
    set reader = ##class(%XML.Reader).%New()
    $$$ThrowOnError(reader.OpenString(XmlString))
    do reader.CorrelateRoot("Community.App.Msg.Suppliers")
    do reader.Next(.Suppliers, .tSC)
    do Suppliers.XMLExport(,",indent")
    quit tSC
}
}

For simplicity I modified the sample to be a classmethod.
When the test() method is run the output is:

EPTEST>d ##class(Community.App.Msg.Suppliers).test()
<Suppliers>
  <Supplier>
    <row>1</row>
  </Supplier>
  <Supplier>
    <row>2</row>
  </Supplier>
</Suppliers>

The relevant documentation is "Controlling the Form of the Projection for Collection Properties" here.

Let me add a few notes.

If a class extend Ens.Response or Ens.Request  is not necessary to extend %Persistent because is already inherited by Ens.Request/Ens.Response.
Edit: please see Antoine commnet below

If the desired XML tag correspond to the class name (without package), it is not necessary to add the XMLNAME parameter, like you did in App.Objects.Suppliers class.

Same goes for XMLNAME property parameter XMLNAME = "row" is not necessary because the property name correspond to the desired XML tag name.