go to post Jeffrey Drumm · Sep 4, 2019 As long as you can count on the message spec never changing, this works fine.If the originating system ever adds an NTE segment after the OBX, you'll have an issue. The message would still be valid from an HL7 standards perspective, though.
go to post Jeffrey Drumm · Aug 27, 2019 Hi Scott,The upgrade instructions for HealthShare/HealthConnect 2018.1.2 should be essentially the same as for Caché/Ensemble 2018.1.2. The documentation for the latter is here:https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls
go to post Jeffrey Drumm · Aug 22, 2019 Thanks, Leon. Good to hear that you're still active in healthcare integration, and I hope we'll see more of you here at the Developer's Community!
go to post Jeffrey Drumm · Aug 20, 2019 Hi Leon,You're actually looking to create a batch, with a batch header for your file output.To do this you'll need to define a batch class in your RecordMap, and in that class define your header (I'm assuming it's a fixed header, like field names).You'll then want to use EnsLib.RecordMap.Operation.BatchFileOperation (or BatchFTPOperation) to deliver the batches. There are a few ways to trigger the batch rollover; a schedule, a record limit, or a Batch Rollover Request depending on your needs.
go to post Jeffrey Drumm · Aug 19, 2019 I'm thinking that you may want quotes around the 0000 value ... you are, after all comparing it to a string
go to post Jeffrey Drumm · Aug 12, 2019 Are the DTLs referenced in routing rules or are they being called from custom Business Processes (or BPLs)? I verified the first option using a production at my current client and the DTLs are all there in the export list.
go to post Jeffrey Drumm · Aug 12, 2019 Hi Robert,You can actually export the entire production in a single go through the Export button found in the Actions tab of the Production Settings. You would then use the "Manage / Deployment Changes" page on the target system to deploy the entire production to the destination namespace.Other options include: Select "Files of type: DTL Document (*.dtl)" in Studio's Export option under the Tools menu (click "Add"), and select the entire list with shift-click (and similarly import through Studio), or use the ObjectScript class method $System.OBJ.Export("*.dtl","/path/to/exportfile.xml") and corresponding import method $system.OBJ.Load("/path/to/importfile.xml") in the target environment.The class methods work locally on your HealthConnect servers; if they're physically distinct hosts you'll need to copy the export file to the target server. Also you would run the export/load utilities in the namespace in which your production is located, of course ...
go to post Jeffrey Drumm · Aug 9, 2019 Ah, now it makes sense. The Document type you'd specified for the inbound message did not match the structure of the message itself, so the RemoveSegmentAt() method didn't know how to "find" the EVN segment ... it didn't exist in that schema.The recommended approach would be to use a schema/document type (custom if necessary) that matches the structure of your inbound message, making the segment to be removed optional in the definition. With that in place, the RemoveSegmentAt() method would have worked as expected.
go to post Jeffrey Drumm · Aug 8, 2019 I would expect to see that error on the original message (before the EVN segment was deleted) but not on the cloned/modified version. Are you sure you're looking at the right message?
go to post Jeffrey Drumm · Aug 2, 2019 You were close with you original code ... Set newreq = request.%ConstructClone() Set sc = newreq.RemoveSegmentAt("EVN") Set request = newreq the variable sc is the status of the remove segment operation; the EVN segment is actually removed from newreq.
go to post Jeffrey Drumm · Aug 1, 2019 You can use the Source property to identify the component that sent the message into the router:
go to post Jeffrey Drumm · Aug 1, 2019 I've cobbled together a little TamperMonkey/GreaseMonkey script that diddles with the style sheet without having to make unsupported changes to your installation's configuration. Adust the devattr, qaattr and prdattr variables to suit your color tastes, and the match arguments for the hostnames to identify your servers.// ==UserScript==// @name Management Console Banner// @namespace http://tampermonkey.net/// @version 0.2// @description Seems to work for both Chrome and Firefox// @author Jeff Drumm, HICG LLC// @include *://*/csp/sys*// @include *://*/csp/healthshare*// @grant none// ==/UserScript==function addGlobalStyle(css) { var head, style; head = document.getElementsByTagName('head')[0]; if (!head) { return; } style = document.createElement('style'); style.type = 'text/css'; style.innerHTML = css; head.appendChild(style);}var devattr = 'color-stop(0.0,rgb(95, 246, 18)), color-stop(0.5,rgb(20, 204, 51)), color-stop(1.0,rgb(232, 227, 226))'var qaattr = 'color-stop(0.0,rgb(248, 252, 10)), color-stop(0.5,rgb(204, 199, 20)), color-stop(1.0,rgb(232, 227, 226))'var prdattr = 'color-stop(0.0,rgb(255, 2, 49)), color-stop(0.5,rgb(204, 18, 18)), color-stop(1.0,rgb(232, 227, 226))'var curattr = ''if (window.location.hostname.match('^ensprod.*')) { curattr = prdattr;} else if (window.location.hostname.match('^ensqa.*')) { curattr = qaattr;} else { curattr = devattr;}addGlobalStyle('.portalTitle { background: -webkit-gradient(linear, left top, left bottom, ' + curattr + ') !important; } ');
go to post Jeffrey Drumm · Jul 29, 2019 Mmmyyyeaaaaaah, You're going to want to do that in a DTL:Create a rule that appends the text to the target.AlertText property:You can add conditionals to provide different alert explanation values based on the SourceConfigName or by parsing the source.AlertText text to find something interesting.Finally, stick the DTL in the Send rule for whatever operation you're sending alerts to.
go to post Jeffrey Drumm · Jul 29, 2019 Apparently there's a patch for the task so that it doesn't pollute the audit database when the <PROTECT> error occurs on a R/O database, but I don't think it's available for 2017.2.1.I've been told dev key MAK5003 in Caché/Ensemble 2018.1.2+ is the solution, but the next upgrade will be to IRIS, which should also have that fix.
go to post Jeffrey Drumm · Jul 28, 2019 Second followup: R/O mode did something bad to the "Update SQL query statistics" task that comes standard with Caché. Caused it to dump millions of <PROTECT> records into the Audit database, which ballooned in size and ran the application directory out of disk space. Terminating and restarting the job had the same effect. Not sure what's going on, have a ticket open with the WRC now.
go to post Jeffrey Drumm · Jul 26, 2019 Just a quick follow-up ... no issues at all with making the database R/O. Works just as well as I'd hoped!
go to post Jeffrey Drumm · Jul 26, 2019 That's a great suggestion, Eduard, and far simpler than my code-based solution. My only concern is that I will be extracting the messages from the retired Ensemble message database so that it can be deleted, and I'm not sure whether the task I've written to do this will require any temporary, behind-the-scenes global storage on the database itself. Easy enough to test, though, as I have two other environments with the same configuration (Dev and QA).
go to post Jeffrey Drumm · Jul 25, 2019 You could do it with an SQL query:DELETE FROM Ens_Util.LookupTable WHERE TableName = '<name of table>'You can create the query either via the Management Console (System Explorer | SQL | Execute Query tab) or from the SQL Shell JEFF>d $system.SQL.Shell() SQL Command Line Shell ---------------------------------------------------- The command prefix is currently set to: <<nothing>>. Enter q to quit, ? for help. JEFF>>delete from Ens_Util.LookupTable where TableName = 'facLookup' 1. delete from Ens_Util.LookupTable where TableName = 'facLookup' 3 Rows Affected statement prepare time(s)/globals/lines/disk: 0.1893s/11322/125529/16ms execute time(s)/globals/lines/disk: 0.0021s/29/408/0ms cached query class: %sqlcq.JEFF.cls27 ---------------------------------------------------------------------------
go to post Jeffrey Drumm · Jul 24, 2019 You can check to see if the internal web server is enabled with: %SYS>d ##class(Config.Startup).Get(.Prop) %SYS>w Prop("WebServer"),! 1
go to post Jeffrey Drumm · Jul 23, 2019 You could write a simple classmethod that starts and stops the offending component when an inactivity alert is received. It would do little more than executing: Do ##class(Ens.Director).EnableConfigItem("service name",0,1) Do ##class(Ens.Director).EnableConfigItem("service name",1,1) That would almost certainly reset the inactivity timer. As long as the class it's in extends Ens.Rule.FunctionSet, you'll have it available in the function selector in the Rule Editor drop-down list.