This might be easier to do with XPath rather than a loop.

First, you'll need to create a %XML.XPATH.Document object, maybe using the create from string method:

set sc = ##class(%XML.XPATH.Document).CreateFromString(xmlstring,.mydoc)

Check that the status you get back from that is not an error. If it isn't, you mydoc should be an XPath document. Then you should be able to use the EvaluateExpression method of that document to get what you want, something like:

set sc = mydoc.EvaluateExpression("/Msg/Parties/Party[AgentId=1]/OrgCode","",.value)

If that status is okay, the value you're looking for will be in value, unless there are multiple XML nodes that match that path. W3 provides the XPath syntax specification here.

I've had to do this a time or two in a development environment. Sometimes you can find it under System Operation > Processes and terminate the process. If that doesn't work, you can look at the process ID of the process and kill it at the OS level (the kill command in Linux, or taskkill in Windows). Just be aware that depending on what it's doing and how the task was written, you may end up with some weird stuff.

You could create a new class that extends %ZEN.Component.toolbar, and override the ongetdata property to be a certain method name, then define that method in the class. Then you'd have your own custom tag to use in your zen pages. Here's more information on creating custom Zen components.

Inevitably, though, someone is going to come in here and tell you not to use Zen in any new development because it's deprecated, FYI. Which makes me sad, because I still really like working with it.

In the management portal, go to System Administration, Security, Applications, Web Applications and find your application. Under security settings, disable Unauthenticated, and enable Password.

Then, when you send your requests, you need to include a base 64 encoded basic authentication header with the username and password, or on the end of the URL include ?CacheUserName=username&CachePassword=password. Keep in mind, though, that if you aren't using HTTPS, you could end up transmitting a username and password in plain text or in a very easily decrypted way.

If you want only specific users to be able to access the API, consider creating a new Resource then setting that resource as the Resource Required in the security settings, then only giving that resource to people who need to access the API.

I think what you're looking for might be setting the isolation level to read committed. This will make the process wait for the in-progress changes have been committed, though you'll still want to make sure you handle SQLCODE -114 somehow, too. That's the code you get back if there's a timeout waiting for the lock. You should be able to set that using:

%SYSTEM.SQL.Util.SetOption("IsolationMode",1,.oldval)

If you do that before your query, the rest of the process will run at that isolation level.

You can use that same method to set the LockTimeout too, by the way. Default is 10 seconds.

Your tResult will have a property called %SQLCODE that gets set when the query is run. If %SQLCODE = 100, that means that the query ran successfully but returned no results or that you've reached the end of the result set. If %SQLCODE = 0, you have some results. If %SQLCODE is less than zero, that's an error code.

if tResult.%SQLCODE = 100{

//whatever you want to do for no results here

}