New post
AllAccepted answers
Jeffrey Drumm · Mar 17

Looks like HealthConnect/IRIS for Health doesn't supply ISO-8859-4 ("Northern European"), or its successor ISO-8859-10. You can try forcing other character sets by preceding them with an exclamation point in the operation's Default Char Encoding property, but there may be characters that translate incorrectly:

Jeffrey Drumm · Mar 15

Here's how I would approach this using a DTL ...

  1. Create a counter variable to hold the number of occurrences of "Item Number:"
  2. Use a for each action to iterate over the OBX segments
  3. In the for each, create an if action that checks for the presence of "Item Number:" in OBX:5 (using ..Contains())
  4. If the action is true, increment the counter variable

Example:

On completion of the for each, you should have a value that indicates the presence of more than one "Item Number." Next, update the OBXs:

  1. Create another counter variable to track occurrences of "Item Number" to be used for comparison
  2. Add another for each action to perform the modifications to the OBX segments
  3. Use the $REPLACE() or ..Replace() functions to replace "REASON FOR REQUEST:" in each OBX:5 with an empty string
  4. Add an if action to check the OBX:5 field for "Item Number:"; increment the new counter variable if found
  5. Add an if action to evaluate the new counter variable against the original; if it's less than the original, add a line break (not actual $C(13)/$C(10) characters, but escaped representation such as \.br\ or \X0D\\X0A\; likely vendor-dependent)

Example:

Jeffrey Drumm · Mar 7

Likely significantly faster:


SELECT COUNT(DISTINCT SessionId)
  FROM Ens.MessageHeader
  WHERE ID >= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated >='2025-02-01 00:00:00.000' ORDER BY TimeCreated ASC)
    AND ID <= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated <='2025-02-28 23:59:59.999' ORDER BY TimeCreated DESC)

In my crude and hasty benchmarking, twice as fast on a sampling of  2.7M message headers.

Jeffrey Drumm · Mar 4

You can suspend the task via either ObjectScript or SQL.

Assuming you know the Task ID, and using 1001 as an example:

Set tsk = ##class(%SYS.Task).%OpenId(1001)
Set tsk.Suspended = 1
Do tsk.%Save()

or

Do ##class(%SYS.Task).Suspend(1001,1)

Resume the task with

Do ##class(%SYS.Task).Resume(1001)

Via SQL:

UPDATE %SYS.Task SET Suspended = 1 WHERE ID = 1001

or

UPDATE %SYS.Task SET Suspended = 1 WHERE TaskClass = 'Sample.Util.CreateTask'

Set Suspended to 0 to re-enable the task.

Jeffrey Drumm · Feb 25

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)
Jeffrey Drumm · Feb 15

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 😉