Depends on how the attachment is stored by the sender. If it's a binary attachment, the file data will be represented as a stream object in Part.BinaryData. If it's text data, Part.TextData. You just need to create a %Stream object and copy Part.BinaryData (or Part.TextData) to it:

Set stream=##class(%Stream.FileBinary).%New()
Set sc=stream.LinkToFile("/path/to/"_Part.FileName)
Do stream.CopyFrom(Part.BinaryData)
Do stream.Flush() // may not be necessary
Do stream.%Save() // ditto, but better safe than sorry ya know?

You can determine the type of data in the Part via the IsBinary boolean property ... 

If you're trying to get the 4 digit year from an HL7-formatted time string (YYYYmmddHHMM), your method should look like this (using GetYear rather than DateTime as method name for clarity):

ClassMethod GetYear(pDate As %String) As %String
{
   If ($LENGTH(pDate) > 4)
   {
      Return $EXTRACT(pDate,1,4)
   }
   Return ""
}
}

You would then call that class as follows:

Set Year = ##class(CUSTSOM.Training.Functions).GetYear(source.GetValueAt("PIDgrpgrp(1).PIDgrp.PID:7.1"))

The variable Year should then contain the 4 digit year, or the empty string if the value in PID:7.1 is 4 characters or less.

Hi Scott,

You can get a list of message body IDs (and their associated event types) that have no corresponding header record with this query:

SELECT HL7.ID, HL7.Name FROM EnsLib_HL7.Message HL7 LEFT JOIN Ens.MessageHeader hdr ON HL7.Id=hdr.MessageBodyId WHERE hdr.MessageBodyId IS NULL AND HL7.OriginalDocId IS NULL

And yes, this query can take a very long time to run ... long enough that it will usually time out in the Management Console SQL UI. It shouldn't time out if you run it from the Caché (or IRIS) SQL Shell though.

What would you want to use for WHERE or ORDER BY criteria? The list of "fields" (properties) available to reference directly via SQL can be viewed in the Body panel of an HL7 message displayed in the Message Viewer, but their usefulness in determining what made them orphans is limited.

The problem with orphans is that knowing "where they came from" is a bit challenging. The source and destination services/processes/operations in the Production are stored in the message header table and not the body table; the reason the messages are orphans is because they're no longer linked (by MessageBodyId) to any records in the Message Header table.

The most common reason for orphans is the configuration of the message purge task. There's a "bodies too" checkbox that, if left unchecked, will prevent message bodies from being deleted. The headers still get deleted, though, and that makes the bodies "orphans."

This looks like a job for a regular record map with a batch class rather than a complex record map ...

Do you have a corporate mail server that supports SMTP relay? You would need to get the details from the administrator of the mail system. Some require TLS, some don't. Some require credentials, others don't. 

You can use GMail, in which case you would need a configuration of something like this:

Mail server? smtp.gmail.com 
Mail server port? 587
Mail server SSLConfiguration? <SSLConfigName> <-- You would need to create this in Security | SSL/TLS Configurations
Mail server UseSTARTTLS? 1 
 

You will also need to supply your Gmail email address for the username, and an app password (created in your Google Account Security settings) for the Set Authentication option.

Your best bet would be to discuss your email delivery requirements with the mail server administrator of your organization; they should be able to provide you with the required values. If this is for a private/personal installation of Caché or IRIS, GMail is probably the easiest to configure and best documented.

If you're interested in seeing what the actual request looks like, use the value 1 for the 2nd parameter to the Get/Post/Put/etc. call.

USER> Do objHttpRequest.Get("location",1)

This will output the request to the local device, so it's handy for terminal-based troubleshooting.