New post
AllAccepted answers
Gertjan Klein · Nov 27, 2020

As you're using Ensemble, you can use class EnsLib.EDI.XML.Document. I don't have version 2015, but the following works on IRIS. I hope this is present in Ensemble 2015 as well. (Note that, annoyingly, method domGetValueAt is marked internal, and therefore doesn't show up in the documentation. I don't know how to achieve the same result without using this method.)

Set XML = "<a><b><c>some content</c></b></a>"
Set Path = "/a/b"
Set Doc = ##class(EnsLib.EDI.XML.Document).ImportFromString(XML, .sc)
If 'sc Quit $System.Status.DisplayError(sc)
Set sc = Doc.domGetValueAt(.Value, Path, "fo", 1)
If 'sc Quit $System.Status.DisplayError(sc)
Write Value,!

This outputs "<b><c>some content</c></b>" as you want.

Hope this helps,
Gertjan.

Gertjan Klein · Sep 29, 2020

I don't know if try/catch is slow, and I don't care. I don't use it because it is too wordy to handle errors exactly where they occur. It encourages code like in your example, where the code in methods is wrapped entirely in a try/catch block. You say the error object has all the information, but I disagree. It has some low-level information, but often lacks the context I need to determine what the problem is.

My preferred way of handling %Status errors is to add a %Status in front of it with more details of what happened when the error occurred, and return this to the caller. Somewhere up the call chain something will then handle the problem, e.g. add something to the Ensemble event log. This is such a standard way of working for me that I created a macro specifically for prefixing the new status information.

For errors that "raise" I also prefer $ZTrap+$ZError; I don't see the added value of try/catch here either.

Gertjan Klein · Sep 28, 2020

I use %Status exclusively; I really, really don't like try/catch. The most important reason for me is that I want to add information about what went wrong to the status. In e.g. obj.%Save(), the returned status tells me that saving an object went wrong, and hopefully why. I want to add to this which object could not be saved, and possibly some other state that may be relevant for debugging the problem. I find this creates code that is easy to read and debug.

By the way, "If 'sc" is, to me, a lot easier on the eyes than "If $$$ISERR(sc)"...

Gertjan Klein · Jun 18, 2020

Ah, I see -- yes, I can reproduce this, and I would think this is a bug. (It does work as expected in an "if", but not in a "case".) You may want to take this up with WRC, to see what they think.

As a workaround, are you aware that you can use local variables? You could assign the value of source.Items.(i) to a local variable, and use that in the case statement. Something like this:

In a switch statement like yours, this would probably save some typing as well. It does mean the lines in the DTL no longer display properly, though. (Although they might not anyway here.)

Regards,
Gertjan.

Gertjan Klein · Nov 15, 2019

Studio behaves really annoyingly if it loses its TCP/IP connection, as you described. I don't know how to prevent that. You probably don't have to restart HealthShare, though. When the crash happens, don't close the dialog immediately. Instead, first remove all locks for the process Studio was connected to; it shouldn't be too hard to find. (Something like System Operation -> Locks -> Manage Locks, I don't have access to a HealthShare instance right now.) Then allow Studio to reconnect, which should now work without issues.

Gertjan Klein · Oct 29, 2019

I have enabled and used that feature in older versions as well; it is really useful. I have a PuTTY setup with a key pair that starts the IRIS terminal in docker on a remote machine, without any password, but still safe. (I wanted to use my regular account name as well, so I had to do some additional setup in the container, but the principle remains the same.)

Anyway, that explains why there's no need for a password anymore, thanks!

By the way, I have not een an announcement that 2019.3 became an official release, did I miss something? (I also see no Studio for 2019.3, and the 2019.4 preview Studio download doesn't work.)

Gertjan Klein · Oct 28, 2019

Thanks for that, Evgeny, that does clear up things a bit. I hope Luca responds as well about the Quiesce... and SetMonitorState calls. I get the impression that things relating to creating containers are still changing rapidly. I do find the backslash-escaped multiline commands annoyingly ugly; your post above made that a bit better, compared to what was there before. (I'm hoping some of the ugly boilerplate will be delt with by ISC "inside" the container eventually.) I'm going to play around with your template a bit when I get the time!

Gertjan Klein · Jun 3, 2019

That link works. But if I search with Google (or DuckDuckGo), the first link that comes up for me appears to point to the proper page, but opening it loads a page about  SOAP Session Management. Many other links from Google end up on that page as well. The key in the docbook URL is ITECHREF_macro, that looks ok, so it seems the ISC docs are broken somehow.

Gertjan Klein · Feb 22, 2019

If you massage the timestamp format a bit so it is ISO8601/XSD compatible, you can use the XSDToLogical method of %TimeStamp to do the conversion for you:

DEV>Set ts = "2018-02-01 00:00:00+0600"
DEV>Set ts = $Translate(ts, " ", "T")
DEV>Set ts = $Extract(ts, 1, *-2)_":"_$Extract(ts, *-1, *)
DEV>Write ts
2018-02-01T00:00:00+06:00
DEV>Write ##class(%TimeStamp).XSDToLogical(ts)
2018-01-31 18:00:00

Gertjan Klein · Apr 24, 2018

I have not run into this problem. Also, it appears that Caché already adds the Content-Length header:

  Set req = ##class(%Net.HttpRequest).%New()
  Set req.Server = "www.google.com"
  Do req.EntityBody.Write("test")
  Do req.Put("/", 1)

Yields:

PUT / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; Cache;)
Host: www.google.com
Accept-Encoding: gzip
Content-Length: 4
Content-Type: text/html; charset=UTF-8
test
 

I suspect Content-Length isn't the actual issue. I don't have any ideas about what is, though. (Perhaps you should at least check if your Caché sends it.)

Gertjan Klein · Aug 17, 2017

It appears to be enabled when I try here, but I haven't used recordmaps much so I don't have one fully configured. I see another setting for the encoding in the record map properties itself; perhaps this is where things should be configured? (That would also explain why the adapter setting is disabled: you want to configure this only once.)