Jon Bartels jonbartels

## Managing SSL Connections in MC.md

      
              1 file
            
          
              2 forks
            
          
              7 comments
            
          
              21 stars
            
          
                jonbartels
                / Managing SSL Connections in MC.md
            
            
              Last active
              May 30, 2024 18:08
            
              
                Mirth Connect has many ways to manage SSL connections. This gist provides a primer on how to manage them. Edits, contributions, and corrections are appreciated!
              
          
    Mirth Connect is awesome! One common question on the forums and Slack is how to manage SSL connctions. These questions mainly focus on HTTPS but also include TCP connections.
The quick rundown is:

The built-in MC HTTP Sender connector will do HTTPS if:


The endpoint has a certificate which is signed by a CA already present in the JVM truststore and has the right DN or SAN for the hostname. This is logically equivalent to the "green check" if you open the URL in a browser.
The certificate has been added to the truststore for the JVM that MC is running under
Changes to DNS or host files allow a hostname to match the DN or SAN already present in the cert (not reccomended)
The connector may flag these connections with a warning or red x. Test the channel first as the validator makes assumptions about SSL that may not apply in this case.


The built-in MC HTTP Listener connector will not do SSL directly. A plugin or a proxy is necessary.


Tony Germano has a plugin implemented for SSL l


## mirth-db-schema.xhtml
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<!DOCTYPE html>
<html lang='en-us' xmlns='http://www.w3.org/1999/xhtml' >
<head>
<title>mirth</title>
<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'/>
<meta name='viewport' content='width=device-width, initial-scale=1, shrink-to-fit=no' />
<link rel='shortcut icon' href='https://dbschema.com/images/favicon.ico'>
<style>
/*!

## gist:c91a8965788b80029812d32b45acc58d
jonb  11:31
I would do many dirty deeds if globalMap and globalChannelMap and configMap had a lastUpdated flag. I have a use case with a large-ish object in the map and don’t want to re-load or re-parse it if it hasn’t changed. (edited)

pacmano  11:39
We manually put that in there.   That would be really nice.

chris  11:51
lastUpdated flag, or timestamp-of-last-update?
11:51
And do you want that per-key, or per-map?

## Rhino Shell for Mirth Connect.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                jonbartels
                / Rhino Shell for Mirth Connect.md
            
            
              Created
              June 3, 2022 14:49
            
              
                Launch Rhino with Mirth Connect 
              
          
    From - nextgenhealthcare/connect#5193 (comment)
PS C:\Program Files\Mirth Connect\server-lib> java -jar .\rhino-1.7.13.jar Rhino 1.7.13 2020 09 02
js> x = <A/>

js> x += <B/>
<A/>
<B/>


## russow-mirthsync.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                jonbartels
                / russow-mirthsync.md
            
            
              Last active
              July 14, 2022 18:04
            
              
                Adrian Russow notes on MirthSync
              
          
    How we use it (I may be overly devops-ey, and I’m also not the closest to this implementation right now) :
We break up specific integrations (like for instance a specific health system) into different repositories.
Each integration is in it’s own channel group.
Dev Workflow:
a developer works on the dev environment, building his channels and testing it in that environment
When he is ready to push it to the higher environments, he runs a ‘mirthsync’ command to pull down the channels from dev, and place them in the local git repo
they make a PR against the dev branch of the repo

  
## mc-recent-messages.sql
do $$
	DECLARE r record;
	declare stmt text;
begin
	drop table if exists temp_last_message;
	create table temp_last_message  (chan text, cnt INTEGER);
	FOR r in select c.name::TEXT as chan, dc.local_channel_id as local_channel_id from d_channels dc inner join channel c on c.id = dc.channel_id
	loop
		stmt := format('INSERT INTO temp_last_message select ''%s'' AS name, count(*) as cnt from d_m%s as messages_last_2_weeks where received_date >= now() - interval ''2 weeks''', r.chan, r.local_channel_id);
		--raise notice 'generated %', stmt;

## mc-source-queue-evil.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                jonbartels
                / mc-source-queue-evil.md
            
            
              Last active
              April 24, 2023 16:07
            
              
                Mirth Connect Source Queues are Evil
              
          
    Source queues in MC are Evil

I was called out on Slack this week for my long standing assertion that "source queues are evil". I will cede that this is said somewhat jokingly, but it is based in fact. I have never been able to quickly explain my position so I wrote this gist to organize my thoughts.
Brief Listing


source queues are hard to manage compared to destination queues
Destination queues will retry if the downstream channel is down for some reason.
Destination queues allow the engineer to add or reduce threads to process the message volume at the desired rate
source queues trigger message recovery which is slow


## mirth-cert-report.sql
with channel_xml as (
    select
        name,
        xmlparse(document channel) as channel_xml
    from channel c
)
, destination_connector_xml as (
    SELECT
        name as channel_name,
        unnest(xpath('//destinationConnectors/connector/name/text()', channel_xml))::TEXT as connector_name,

## convert-to-db-configmap.js
/*
I did a thing.
I wrote a channel that reads the current config map and then writes it to the Mirth DB so that you can switch from file backed config maps to DB backed config maps.
Just let the code run in a JS Reader and then flip the mirth.properties entry whenever you’re ready to change over.
*/
// read mirth.properties and check the configurationmap.location property
var classpathResource = com.mirth.connect.server.tools.ClassPathResource.getResourceURI('mirth.properties');
var propsInputStream;
var configmapLocation = 'Could not read!';
try {

## create-mc-metadata-indexes.postgres.sql
--see https://github.com/nextgenhealthcare/connect/issues/4320
-- this generates create index statements for the metadata columns in MC excluding the default columns
-- the user SHOULD NOT BLINDLY CREATE ALL INDEXES
-- MC is update/insert heavy and having indexes can slow that performance.
-- These indexes should be used only on metadata colums which are searched frequently, on large tables, and where constraining by other indexed columns is not practical
-- Further, if you're searching on large tables you should run the damn pruner. see https://gist.github.com/MichaelLeeHobbs/40b4b7cf70ecbe30b73eed763367e626
SELECT t.table_name, c.column_name, format('CREATE INDEX CONCURRENTLY metadata_hax_%1$s_%2$s ON %1$s("%2$s");', t.table_name, c.column_name) as create_stmt
FROM information_schema.tables t
INNER JOIN information_schema.columns c ON c.table_name = t.table_name AND c.table_schema = c.table_schema
WHERE t.table_schema='public'
	<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
	<!DOCTYPE html>
	<html lang='en-us' xmlns='http://www.w3.org/1999/xhtml' >
	<head>
	<title>mirth</title>
	<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'/>
	<meta name='viewport' content='width=device-width, initial-scale=1, shrink-to-fit=no' />
	<link rel='shortcut icon' href='https://dbschema.com/images/favicon.ico'>
	<style>
	/*!
	jonb 11:31
	I would do many dirty deeds if globalMap and globalChannelMap and configMap had a lastUpdated flag. I have a use case with a large-ish object in the map and don’t want to re-load or re-parse it if it hasn’t changed. (edited)

	pacmano 11:39
	We manually put that in there. That would be really nice.

	chris 11:51
	lastUpdated flag, or timestamp-of-last-update?
	11:51
	And do you want that per-key, or per-map?
	do $$
	DECLARE r record;
	declare stmt text;
	begin
	drop table if exists temp_last_message;
	create table temp_last_message (chan text, cnt INTEGER);
	FOR r in select c.name::TEXT as chan, dc.local_channel_id as local_channel_id from d_channels dc inner join channel c on c.id = dc.channel_id
	loop
	stmt := format('INSERT INTO temp_last_message select ''%s'' AS name, count(*) as cnt from d_m%s as messages_last_2_weeks where received_date >= now() - interval ''2 weeks''', r.chan, r.local_channel_id);
	--raise notice 'generated %', stmt;
	with channel_xml as (
	select
	name,
	xmlparse(document channel) as channel_xml
	from channel c
	)
	, destination_connector_xml as (
	SELECT
	name as channel_name,
	unnest(xpath('//destinationConnectors/connector/name/text()', channel_xml))::TEXT as connector_name,
	/*
	I did a thing.
	I wrote a channel that reads the current config map and then writes it to the Mirth DB so that you can switch from file backed config maps to DB backed config maps.
	Just let the code run in a JS Reader and then flip the mirth.properties entry whenever you’re ready to change over.
	*/
	// read mirth.properties and check the configurationmap.location property
	var classpathResource = com.mirth.connect.server.tools.ClassPathResource.getResourceURI('mirth.properties');
	var propsInputStream;
	var configmapLocation = 'Could not read!';
	try {
	--see https://github.com/nextgenhealthcare/connect/issues/4320
	-- this generates create index statements for the metadata columns in MC excluding the default columns
	-- the user SHOULD NOT BLINDLY CREATE ALL INDEXES
	-- MC is update/insert heavy and having indexes can slow that performance.
	-- These indexes should be used only on metadata colums which are searched frequently, on large tables, and where constraining by other indexed columns is not practical
	-- Further, if you're searching on large tables you should run the damn pruner. see https://gist.github.com/MichaelLeeHobbs/40b4b7cf70ecbe30b73eed763367e626
	SELECT t.table_name, c.column_name, format('CREATE INDEX CONCURRENTLY metadata_hax_%1$s_%2$s ON %1$s("%2$s");', t.table_name, c.column_name) as create_stmt
	FROM information_schema.tables t
	INNER JOIN information_schema.columns c ON c.table_name = t.table_name AND c.table_schema = c.table_schema
	WHERE t.table_schema='public'