Have you tried exporting the production from the Management Portal's Production Configuration | Production Settings | Actions tab, then deploying it to the Test environment through Ensemble | Manage | Deployment Changes | Deploy?

Your best option for doing this is to create a new HL7 TCPIP Service Class that extends EnsLib.HL7.Service.TCPService that overrides the OnConstructReply() Method. The example below includes the necessary code, along with the convenience of being able to adjust the MSH:7 date format by supporting the reconfiguration of the value of MSH7AckDateFormat in the Production's configuration panel for the service. It uses well-known strftime() formatting conventions.

This works with Ensemble version 2017.2.1:

Class HICG.HL7.Service.TCPService Extends EnsLib.HL7.Service.TCPService

{

/// Allows Customization of the date format used in the ACK's MSH:7 field. Uses C strftime() tokens to construct
/// the date in the desired format. Default is HL7 date/time format, yyyyMMddhhmmss.

Property MSH7AckDateFormat As %String [ InitialExpression = "%Y%m%d%H%M%S" ];

Parameter SETTINGS = "MSH7AckDateFormat";

Method OnConstructReply(Output pReplyDoc As EnsLib.EDI.Document, pOriginalDoc As EnsLib.EDI.Document, ByRef pReplyCode As %String, ByRef pSC As %Status, pEarlyAck As %Boolean) As %Status

 {

       Set pReplyDoc=pOriginalDoc.NewReplyDocument(,..LocalFacilityApplication)

       Set pReplyDoc.Source = pOriginalDoc.%Id()

       Do:..#UseOriginalControlId pReplyDoc.SetValueAt(pOriginalDoc.GetValueAt("1:10"),"1:10")

       Do pReplyDoc.SetValueAt(##class(Ens.Util.Time).ConvertDateTime($H,"%q(3)",..MSH7AckDateFormat),"1:7")

       Set tMSA=##class(EnsLib.HL7.Segment).%New($LB("",1))

       Set tMSA.Separators=pReplyDoc.Separators

       Do tMSA.SetValueAt("MSA",0)

       Do tMSA.SetValueAt(pReplyCode,1)

       Do tMSA.SetValueAt(pOriginalDoc.GetValueAt("1:10"),2)

       Do:$G($$$ExpectedSequenceNumber) tMSA.SetValueAt($$$ExpectedSequenceNumber,4)

       Do pReplyDoc.AppendSegment(tMSA)

       Set pReplyDoc.IsMutable = 0

       Quit $$$OK

 }

}

There's also the ^DATABASE routine in %SYS for creating databases, but it provides no options for creating/managing namespaces.

%SYS>d ^DATABASE

 1) Create a database
 2) Edit a database
 3) List databases
 4) Delete a database
 5) Mount a database
 6) Dismount a database
 7) Compact globals in a database
 8) Show free space for a database
 9) Show details for a database
10) Recreate a database
11) Manage database encryption
12) Return unused space for a database
13) Compact free space in a database
14) Defragment globals in a database

Does it happen if she logs into the management portal as herself from another workstation? Have you tried starting her browser(s) in Safe mode (no add-ins/plug-ins loaded)? Have you cleared the browser's cookies and cache? Disabled anti-virus? Is it possible that she has JavaScript disabled?

If  you expect to be using regular expressions frequently, it might be worth your while to write a classmethod that extends Ens.Rule.FunctionSet and wraps $MATCH or $LOCATE in something that can be called from a business rule (or DTL for that matter).

/// Custom methods for business rules and DTLs
Class User.Rule.FunctionSet Extends Ens.Rule.FunctionSet
{

/// Accepts a string <var>pString</var> and regular expression pattern <var>pPattern</var>
/// as arguments; returns 0 for no match, and a positive integer indicating the match's
/// position if there is a match.
ClassMethod REMatch(pString As %String, pPattern As %String) As %Integer
  {
              Return $LOCATE(pString,pPattern)
  }

}

You could use $MATCH instead of $LOCATE in the method above, but $MATCH() assumes the supplied pattern is begin- and end-anchored. In other words, $LOCATE("this","is") returns the positive integer 3, which for all Cache boolean purposes evaluates as true. $MATCH("this","is") returns 0 (false) since "^is$" does not match "this".

If the class you create extends Ens.Rule.FunctionSet and resides in your production's namespace, it will be selectable from the function dropdown list in both the Business Rule and DTL expression editors.

When you say you can't telnet from your machine, do you mean that you don't have a telnet client installed and/or cannot install one?

Are you connecting to the server via a local LAN connection or through a VPN? There may be port-range restrictions for non-local IP addresses in the VPN server's configuration. Even if you're not using a VPN client to connect, there may be a firewall between your location and the server's location that filters traffic based on source network and/or destination port. Finally, there may be similar rules in the Caché host's internal firewall that could impact connections from specific local networks or hosts. This would explain why an Atelier connection works but a Studio connection does not.

It's also possible that your workstation's firewall/anti-virus may be blocking outbound traffic on specific ports or port ranges. If it's so locked down that you can't install a telnet client to test with, I wouldn't be surprised if this was the case.

What's the use case for this data? What sort of system(s) will it be delivered to? Have you discussed with their vendors how this data might be digested by the downstream applications?

You could write custom methods that query the source config item's properties for those values and call them from your routing rules. However, a more supportable solution would be to implement managed alerts, which will make those properties directly accessible to you in the Ens.Alerting.NotificationRequest object that's created from the Alert Manager business process.

See Configuring Alert Management in the documentation.

If your'e sure a result set of no more than 1 row will be returned, just call the %Next() method of the Snapshot object. That'll position the cursor on the first (and, hopefully only) row.

Hi Sean,

The hive you referenced is already there in the registry; I'm assuming it was created during the installation of the Caché client tools. It's in both HKEY_CURRENT_USER\Software\InterSystems\Cache Studio\Settings\Editor and HKEY_USER\(user key value)\Software\InterSystems\Cache Studio\Settings\Editor. The Hover key wasn't present, so I added it as a REG_DWORD value of 0.

The behavior is different, but it doesn't solve the OP's problem ... the "First Record" tip still displays, but it no longer changes when you move the cursor to a class or method where it would normally populate with helpful information.

As Atelier is an Eclipse plug-in, you really need to look at it from that perspective. And given that it's really Eclipse that we're talking about, there are so many useful plug-ins for Eclipse (never mind the multiple distributions it's available supplied as) that it's not an easy answer.

I/O performance trumps CPU speed, though, so you'll get the best results with a SSD. I'd say a minimum of a dual-core CPU manufactured within the last 8 years and 4-8 GB of RAM will work satisfactorily unless you're a demon coder. I run Atelier in the JavaScript-HTML distribution of Eclipse on a dual-core-emulated, Windows 7 64bit VM under VMWare 14 on a 32GB ThinkPad T460p (quad-core, 8 threads, 2.7GHz, 2TB SSD), and am usually running 3-4 VMs at a time. Performance seems fine, but I'm not head-down pounding out ObjectScript all day long ...

I'm currently trying to get Eclipse to install on a ThinkPad T420 running Ubuntu 18.04 Desktop to see what it's like but have yet to succeed in getting it to run. I think 18.04 may not be quite ripe enough yet ;)

When Caché was installed, a group was defined for users who may stop/start/restart it (most likely cacheusr). You'll need to make the non-root user a member of that group, unless you'd prefer to use sudo as previously mentioned.

$ sudo usermod <username> -G cacheusr -a

If the user is already logged in, he/she may need to run newgrp to select cacheusr as their primary group:

$ newgrp cacheusr

The setting is overridden on a primary mirror member such that all global updates are frozen on a journal write error anyway, so the setting really doesn't matter unless you're operating  in a non-mirrored configuration. I've yet to run across a healthcare implementation of Ensemble that wasn't mirrored, but I suppose they exist somewhere. For those cases, I would enable Freeze on Error. Better late delivery than data loss.

Hi Larry,

In a code rule, you'll need to concatenate the path string with the k1 variable, as such:

do source.GetFieldStreamRaw(.stream, "PIDgrpgrp(1).ORCgrp(1).OBXgrp("_k1_").OBX:5.1")