The reason this is happening is because your message specifies UTF-8 in MSH:18.  If you remove that from your test message, it will look correct.

When using the 'test' button to test a DTL, it will always try to use the encoding defined in MSH:18 to read the message.

When using a business service to read the message, it will try to use the encoding defined in MSH:18 if it is defined.  If it is not defined, then the 'Default Char Encoding' setting determines which encoding will be used.  You can force the 'Default Char Encoding' to override MSH:18 by putting a ! before it.

http://docs.intersystems.com/ens20161/csp/docbook/DocBook.UI.Page.cls?KE...

class Ens.Util.LookupTable has %Import and %Export methods.  You can use %Export to export an existing table to see the format expected by %Import.

Another option is to import a csv file using the SQL Data Import Wizard.  You can find that at System Explorer -> SQL and then click the 'Wizards' link at the top and choose Data Import.  I believe the csv file needs 3 columns: tablename, key, value.  The table name gets repeated for every row.  I'm not sure if this can be automated.

The last option is to edit the globals directly.  Ens.Util.LookupTable doesn't use standard default storage.  Instead, everything is stored in ^Ens.LookupTable with this format:

^Ens.LookupTable("TableName","key")="value"

The last two options break the abstraction barrier so if the way lookup tables are stored ever changes, they'll stop working.  %Import and %Export are preferred.

I just tested this in latest and it worked fine for me.  Here is the Message Structure Raw Definition I used:

Why does saving the content of the PID segment in a SQL table require you to convert it to JSON or XML?  What format does it need to be in in the SQL table?

You can extract the entire PID segment with something like source.GetValueAt("PID") depending on your DocType structure.  If you just need to wrap it in XML tags then set xml = "<PID>"_source.GetValueAt("PID")_"</PID>".

On top of that, for the field portion of the VDoc path, using a numeric reference will always work, even if the segment structure of the message doesn't match the schema.

In order to see how to reference the field by name rather than numeric, the best tool to use is the Interoperate message viewer.  This can be found in the management portal at Ensemble->Interoperate->HL7 v2.x->HL7 Message Viewer.

If you save your message as a file and open it using this message viewer, and set the DocType correctly, then you will see the message on the right side with all segment identifiers and fields highlighted in blue.  You can mouse over any segment identifier to see the exact segment path needed to reach that segment, and then you can mouse over any field to see the name that should be used to reference that field.

Here are some examples.  First is the settings I used to open the message, followed by the tooltip when I mouse over the OBX segment, followed by the tooltip when I mouse over the '39' field.

I do this in terminal all the time.  When you do this, you also need to manually set the DocType.  Here's an example:

ENSEMBLE>set msg = ##class(EnsLib.HL7.Message).ImportFromFile("C:\InterSystems\HL7Messages\ADT_A01.txt")

ENSEMBLE>set msg.DocType="2.3.1:ADT_A01"

ENSEMBLE>write msg.GetValueAt("MSH:9")
ADT^A01
ENSEMBLE>write msg.GetValueAt("PID:DateTimeOfBirth.timeofanevent")
19560129
ENSEMBLE>

There is a known problem with our documentation, scheduled to be fixed in 2017.1.

The class documentation for %Net.SSH.Session states: "Once connected and authenticated, the SSH object can be used to perform SCP (Secure Copy) operations of single files to and from the remote system".

This is not true.  There is no way to use %Net.SSH.Session to do a secure copy.

The example at this URL in the documentation shows how to create a REST business service which retrieves JSON data, converts it to a proxy object, and then extracts values from the proxy object to store in a response:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

Assuming you are retrieving your JSON data from a REST service, your use case is similar.  Instead of storing the values in a response, you would want to create a new request class to hold the values.  Replace pResponse in the example with an instance of your new request class, fill it with data from the JSON proxy object, then send it to a message router component with ..SendRequestAsync.

Then, in your message router, you can add a DTL which transforms your new request class into an ADT_A31 HL7 message.

<PROPERTY DOES NOT EXIST> means your code is trying to reference a class property that does not exist.  The rest of the error message should tell you which property you tried to reference that didn't exist.

After you added those 3 properties to the WeatherResponse class, did you save and compile it?

If you're not able to resolve this, can you post the complete error message?  What property is it telling you doesn't exist?

%Net.SMTP method Send handles connecting to the SMTP server, extracting all the necessary data from %Net.MailMessage, formatting it for SMTP, and writing it to the server.

If you copy this method and modify it to skip the connecting to server portion and instead have it OPEN and USE a file, then all of the write commands (well, $$$WriteLine commands) will write to a file rather than to the SMTP server.  This might be the simplest way to serialize the %Net.MailMessage