Hey Joel.

Absolutely - there are a couple levels of ambiguity for the IDE without throwing a #dim in to know what that response object could be.

The biggest being that the target of the call of ..SendRequestSync/Async is something that can, and for good practice should, be configured within the Interoperability Production. Therefore the IDE has nothing to work from with regards to identifying what the response object will be to then provide code completion. Even if it's not configured within the Interoperability Production directly but a developer has simply declared the Target Dispatch Name as a string within the code, the link between that name and the target Class is still contained within the Production and could also not yet exist in the production at the time of development.

It's great to see the effort put into improving the Language Server which has massively reduced the need to use #dim, but I'm not we will see the last of it for some time.

I did post an example last year of how I traditionally would use #DIM, and it was (rightly) pointed out that the scenario was no longer required due to how VSCode behaves these days (well, the Language Server extension used in VSCode).

However today I have found a more common example where #DIM seems to be needed for code completion, based around using Business Services/Processes within an Interoperability Production.

Class Some.Business.Process Extends Ens.BusinessProcess
{

Property OnwardTarget As Ens.DataType.ConfigName;

Parameter SETTINGS = "OnwardTarget";

Method OnRequest(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status
{
    //Some code above
	
	Set someReqMsg = ##Class(Some.Req.Msg).%New()
	Set someReqMsg.abc = "123"
	Set tSC = ..SendRequestSync(..OnwardTarget,someReqMsg,.someRespMsg)
	#; No autocomplete on someRespMsg.xyz without #dim before ..SendRequestSync
	
	//Some code below
	
	Quit $$$OK
}

}

  Without the #dim in the above, there is no context for the IDE to know what someRespMsg returned from the ..SendRequestSync() call will be.

That said, its use is certainly dwindling compared to pre-VSCode times and it's continued usage can be more from habit than necessity a lot of times (I'm certainly guilty of this).

This is really helpful to know. I think I have seen it not work like this in the past and picked it up as a habit, but can't say for sure.

To test this for myself, I have written out above pseudocode into real classes and found that the code completion doesn't kick in when attempting in the $$$TRACE, but does when attempting outside of the macro params:

   
I'll try get this logged via github later today assuming this isn't intended behaviour for the Language Server.

EDIT:

Logged here and I realise that my habit of using #Dim for Intellisense 100% comes from my historic use of Studio.

3. vscode connect failed.

It looks like your images failed to upload so it's not clear what (if any) errors you are getting when the connection failed.

Hey Jonathan.

The utility function ..CurrentDateTime() should be returning a value that is based on the servers local timezone. As you're in EST, I'm guessing you're getting UTC/GMT. You might want to look at addressing this early and not code around it just yet as this could then be corrected at an OS level and you're suddenly subtracting 50000 from the correct result.

I tend to break up my usage between SET when an object is being created within the class, and using #DIM when working with responses from another ClassMethod. For example:

Set SearchParams = ##Class(DM.EmployeeSearch).%New()
Set SearchParams.EmployeeID = 042114040518
#DIM Employee As DM.Employee
Set tSC = ##class(DM.Employee).EmployeeSearch(SearchParams,.Employee)
If '$ISERROR(tSC){
    $$$TRACE(Employee.Name) //Should return "Jim Halpert"
}

Thanks Jeffrey - it's certainly highlighted some hidden pockets of orphaned messages for me. I'm going to track this in a separate thread, but basically it seems there's a few edge cases where ACKs are being saved and don't end up in the IO log and don't get an entry in the Message Header table.

Based on this, is it fair to assume that the following alteration to the SQL query in Scott's above post would give a truer reflection of orphaned messages?

SELECT HL7.ID,HL7.DocType,HL7.Envelope,HL7.Identifier,HL7.MessageTypeCategory,HL7.Name,HL7.OriginalDocId,HL7.ParentId, HL7.TimeCreated
FROM EnsLib_HL7.Message HL7
LEFT JOIN Ens.MessageHeader hdr
ON HL7.Id=hdr.MessageBodyId
LEFT JOIN Ens_Util.IOLogObj ack
ON HL7.Id = ack.InObjectId
WHERE hdr.MessageBodyId IS NULL AND ack.InObjectId IS NULL

If you're looking to simply convert timezone codes to the UTC offset, I'd setup a simple utility that returns the desired string based on a case statement.

Something like:

ClassMethod DisplayTimezoneToUTCOffset(pInput as %String) As %String{
    Quit $CASE($ZCONVERT(pInput,"U"),
    "CEST":"+02:00",
    "CET":"+01:00",
    "BST":"+01:00",
    :"")
}

If you then want to build the entire string, you could do similar to above for the months, and then have the following:

Class Demo.Utils.ExampleUtils.TimeConvert
{
ClassMethod DisplayDateTimeToLiteral(pInput as %String) As %String{
    // Deconstruct the input string into it's logical parts.
    // Variables starting d are "display" values that will be converted later.
    Set DayOfWeek = $P(pInput," ",1) //Not used
    Set dMonth = $P(pInput," ",2)
    Set Day = $P(pInput," ",3)
    Set Time = $P(pInput," ",4)
    Set dTimeZone = $P(pInput," ",5)
    Set Year = $P(pInput," ",6)

    //Return final timestamp
    Quit Year_"-"_..DisplayMonthToLiteral(dMonth)_"-"_Day_" "_Time_..DisplayTimezoneToUTCOffset(dTimeZone)

}

ClassMethod DisplayTimezoneToUTCOffset(pInput as %String) As %String{

    Quit $CASE($ZCONVERT(pInput,"U"),
    "CEST":"+02:00",
    "CET":"+01:00",
    "BST":"+01:00",
    :"")
}

ClassMethod DisplayMonthToLiteral(pInput as %String) As %String{

    Quit $CASE($ZCONVERT(pInput,"U"),
    "JAN":"01",
    "FEB":"02",
    "MAR":"03",
    //etc. etc.
    "JUL":"07",
    :"")
}

}

Which then gives the following:

Hi Nezla.

As the URL starts out as "ac1.mqtt.sx3ac.com", suggesting that the API is using MQTT, is the %net.httprequest adapter the right way to go?

I think it'd be good to take a look at Using the MQTT Adapters to see how the adapter can be used if you haven't already.

Have you tried adding backticks to your double-quotes to escape them?

PS C:\Users\Colin\Desktop> irissession healthconnect -U user 'Say^ImplUtil(`"Your String Here`")'

Hey everyone!

• Name - Julian
• Where you’re from / based - United Kingdom
• What you do (your role / company / areas of interest) - On paper, I'm a developer in the NHS. However like so many here, I'm very much a jack of all trades.
• Expertise
  • HL7 (V2/FHIR)
  • Objectscript
  • OpenEHR
  • Poking around so many different clinical systems' front and back ends
• Fun Fact or Hobbies – I do enjoy flying FPV drones, but live in a country where the weather is constantly fighting against that enjoyment.
• LinkedIn - it's here however I must warn that my network is an eclectic mix of our industry, and then people in the space of event and crowd safety, with some drones thrown into the mix.

Out of interest:

• Are both instances running on the same version of Windows including architecture?
• Are both instances using the same license type for IRIS?
  • I'm not sure if one using a community/temp license vs a "full" license could have this effect, but thought it's worth asking.
• If you call $System.Util.CreateGUID() without writing it to the database, does the CPU still hit 100% on the single core (just thinking this could point to the CreateGUID call being the bottleneck instead of the DB write)