While you can create multiple productions in a single namespace, you can only run one at a time. There's really no good reason to have more than one production in a namespace ... and with each production in its own namespace, they can be running concurrently.

Inserting characters that are defined as HL7 delimiters to fields is likely to be problematic. It would be very helpful if you would provide an example of the source message and the desired result.

Something like this should do the trick:

ClassMethod GetConnectionStatus(pItemName As %String, ByRef pStatus As %String, ByRef pState As %String) As %Status [ Language = objectscript ]
{
	Set tStatement = ##class(%SQL.Statement).%New()
	Set tSC = tStatement.%PrepareClassQuery("Ens.Util.Statistics","EnumerateJobStatus")
	Return:$$$ISERR(tSC) tSC
	Set tRS = tStatement.%Execute(pItemName)
	If tRS.%SQLCODE = 0
	{
		Do tRS.%Next()
		Set pStatus = tRS.%Get("Status")
		Set pState  = tRS.%Get("AdapterState")
		Return $$$OK
	}
	Return $$$ERROR(5001,"Status not Found")
}

Call it with the status and state variables passed by reference:

Set sc=##class(My.Class).GetConnectionStatus("T_SPM_SIU",.status,.state)

The class Ens.MessageHeader has a classmethod Purge() that deletes message headers and bodies based on the number of days to keep along with a few other criteria; those are used in an SQL query to select the set of messages to purge. That query along with the associated purge code should work as an example to see what's involved in carefully removing messages without collateral damage ... search table indices need to be maintained, for example.

There's also the Ens.Util.MessagePurge task definition that is used for scheduled purges, it has much of the same code but offers a multi-threaded purge feature that leverages the work queue.

@Enrico.Parisi's solution moves the actual purge of the messages off to the scheduled Ens.Util.MessagePurge task for messages that exceed the DaysToKeep limit, as long as that is configured to delete bodies too. This is likely the safer solution and requires significantly less effort 😉

Does the operation have a job number in the Jobs tab on the right side of the Production page?

That should correspond to the task's process ID in Windows. You should be able to terminate it with Task Manager or the taskkill command.

I'm pretty sure the SegType property (deprecated, should be using DocType) should be set to just "2.7:OBX".

Since there are no ROL segments in the source message, your foreach never executes.

Just check for the existence of the ROL segment in the source, and if it doesn't exist, populate any field in a ROL segment in the target:

Are you looking to view the expected request and/or response? The %Net.HttpRequest Send() method has a test argument as its 3rd option; setting it to 1 outputs the request, 2 the response, and 3 the response headers.

It's unfortunate that this isn't described in the class documentation; you have to look at the source to figure out what the test argument does.

Sounds like a separators issue. I set that as empty on both the service and operation, which assumes the messages will be formatted with whatever separators are indicated in the ISA segment.

EnsLib.SQL.Snapshot has a GetData() method that takes the column number as its first argument (the second takes a row number but defaults to the current row). So that in conjunction with GetColumnCount() should allow you to iterate across columns.

Edit: And of course Marc beat me to it ... 😁

You can select from a number of Linux vendors/versions for an AWS installation. I would recommend you select Red Hat or Ubuntu rather than Amazon Linux; InterSystems officially supports those.

In my experience Red Hat is the more stable/compatible version and is the most widely used for IRIS implementations.

You would not install Ubuntu or Red Hat "on top of" Amazon Linux; you would select the Linux flavor when creating your EC2 instance.

Because it's a method defined with the [ Internal ] keyword, which the class documentation generator excludes. That keyword means that it's not recommended for use by anyone other than InterSystems. Its behavior may change or it may go away, and you're taking a chance by implementing it in your own code.

GetSegmentAt() provides the same functionality but is documented for use by anyone. It's defined in a class (EnsLib.EDI.Segmented) that is inherited by EnsLib.HL7.Message and other virtual document classes.

The conventional method is with an <assign> action. If the classmethod has output or byref variables in its signature, I think a <code> action would be appropriate (I've never tried to set context variables by reference in an <assign>).

This likely goes without saying, but context variables remain available/usable in a code action.

I think we'll need more information to provide an answer.

Since you've indicated that you're using Caché 2012, you don't have IRIS for Health, which you've tagged. Are you working with Ensemble, and looking to report on MRNs received via HL7 and/or other messaging formats into Ensemble?

Or are you working with a custom application built on Caché 2012?

Properties defined in the BPL class can be accessed as process.PropertyName, or as in your case, process.Scope.

You cannot import formatted text in Excel with a tab delimited text file as the source. The file must be created in either native Excel format or HTML.

There are many posts and articles on this Developer Community that discuss the generation of Excel-compatible files that will support text formatting; too many options to list them all here. Search for "Excel files" and you may find an answer that will work for you.

Yes, there's a "raw" syntax, but I think it's counterproductive in the long run. Segments and fields can be addressed numerically, i.e. target.{1:4} would reference MSH:4. Not very descriptive; one of the beauties of using the DTL editor and message DocTypes is that your transformations become somewhat self-documenting.

You could attempt to build an HL7 "SuperSchema" DocType/Category, I suppose, if your intent is to address message elements using the "symbolic" Virtual Document syntax. For that, you need a DocType.

Any of the tokens supported by the method FormatDateTime() in class Ens.Util.Time can be used to generate a dynamic value for the archive filename; the default of 1 uses the pattern %f_%Q, where %f is the original filename and %Q is the current time in ODBC format.

$E is the shorthand version of $EXTRACT ...

ConvertDateTime(source.{PID:DateTimeOfBirth},"%Y%m%d%H%M%S","%Y%m%d") should work just fine.$E(source.{PID:DateTimeOfBirth},1,8) by itself should provide the same result.

But ConvertDateTime($e(source.{PID:DateTimeofBirth},1,8)) is basically taking the 8-digit date returned from $E() and converting it without any input and output patterns ... which gets you the exact same 8-digit date.

I'm not sure why ConvertDateTime() failed; informat should be "%Y%m%d%H%M%S" and outformat "%Y%m%d" for your example transformation. Regardless, you can also use $EXTRACT(<sourcedate>,1,8). There's also the SubString() method in the DTL function list, which takes the same arguments.