1. Edit “C:\Program Files (x86)\Mirth\conf\mirth.properties”  and make sure the database property is set to sqlserver2005

database=sqlserver2005

2. Login to SQL Server management studio and create an database called “mirthdb”

3. Inside SQL Server Management Studio, execute the script  “C:\Program Files (x86)\Mirth\sqlserver2005-database.sql” which creates all the necessary tables within mirthdb database.

4. Create an account called “mirthdb” and grant necessary priviledges to this account for mirthdb database.

5.  Edit “C:\Program Files (x86)\Mirth\conf\sqlserver2005-SqlMapConfig.properties” and add the username and password for the SQL Server user created above.

Thats it, restart the Mirth servcie and login to Mirth. It is as simple as that.

For brevity sake I am just going to showing the OBX segments that I am going to parse here instead of the whole message. The following two OBX segments are present in my message:

OBX|1|ST|HT^PATIENT HEIGHT||142.9

OBX|2|ST|WT^PATIENT WEIGHT||45.2

I want to create three variables, one to hold the height, one to hold the weight and one to hold the number of segments we parsed.

The first step is to create the channel. I am assuming here you already know how to create a channel. For my channel l have my source as a file reader and a database reader as the destination. I create a transformer for the destination. In the transformer, I paste my sample message in the template section and create a step with step being “Javascript”. Then I type the following script as my Java script:

var i=0;
for each (seg in msg..OBX)
{
       i++;
       var key = seg['OBX.3']['OBX.3.2'].toString()
       var obx_val = seg['OBX.5']['OBX.5.1'].toString() ;
       if(key.search(/HEIGHT/) != -1)channelMap.put(‘HEIGHT’, obx_val);
       if(key.search(/WEIGHT/) != -1)channelMap.put(‘WEIGHT’, obx_val);
}
channelMap.put(“obx_seg_count”, i);

 This script creates three variables, HEIGHT, WEIGHT and “obx_seg_count” that are now available to us in the destination for inserting in to a data base as follows.

 Assuming I have a table called ‘OBX’ and columns called ‘ht’ and ‘wt’, I insert the values in to the table as follows in the detonation tab….

expression = “insert into OBX (ht, wt ) values (‘” + $(‘HEIGHT’) + “‘ , ‘” + $(‘WEIGHT’) + “‘)”;
var result = dbConn.executeUpdate(expression);

The trick in this is the for each loop above. The expression in the parenthesis is simple XML E4X expression (see https://wso2.org/project/mashup/0.2/docs/e4xquickstart.html for more details). The other concept to grasp here is to note that the incoming message is available as ‘msg’ object and is just a XML object. Knowing this we can traverse the XML object with E4X and find the elements we are interested in which are OBX elements. The other concept to understand is the ‘maps’ in the Mirth. You need to populate the ‘channel map’ so those variable you create are available throughout your channel.

If you have unknown number of OBX segments in a message, like in a ORU message where you get a report, you can do two things, we can either loop through the way I did up here and concatenate each OBX segment to create on variable called ‘report’ with <cr> at the end and put that in to channel map. Or you could create several variables like following….

var i=0;
for each (seg in msg..OBX)
{
       i++;
       var key = “report_seg_”+I;
       var obx_val = seg['OBX.5']['OBX.5.1'].toString() ;

       channelMap.put(key, obx_val);
}
channelMap.put(“obx_seg_count”, i);

We are in the process of developing a toolkit with networking suport. We will post it hre when ready. Enjoy….

dicomfilereader

create mirth channel movie

I wonder why you want to use Java logging API when you can use log4j. Well if you want to or have to use Java’s bundled API for logging, it is not that bad. There are several good articles on the web that go it much more details on this topic then what I am going to cover her. So, look at the articles at the end of this article for links to some of those detailed articles.

So, what am I going to be covering in this article? Just few tricks that I found intriguing and somewhat hard to understand. First of all the logging.properties file. This file resides in the JRE directory as lib/logging.properties (/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/lib for Mac OS users). You can edit this file to control the behavior of the default loggers that get installed when JVM starts. This is definitely is not a good idea. You can copy this file to a user space and then can edit the copy to your liking and load this file as part of your program to control the logging. As I am working on a Mac I will copy the system properties file to my space as /Users/user/LogApi/mylogging.properties. Now, I would like to have two types of handlers, the standard Console Handler and a File Handler. I edit the file to install the two handlers. So, make sure that the following line is uncommented in your properties file

handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

I would like to log everything to a file but only the SEVERE and above log entries to my log console. By default, the FileHandler logs everything to the file, so we don’t have to do anything here. To make the ConsoleHandler log only entries higher thatn SEVERE, add line similar to:

java.util.logging.ConsoleHandler.level = SEVERE

Configure the FIleHandler handler with the following properties.

java.util.logging.FileHandler.pattern = /Users/user/LogApi/build/classes/javaapi%u.log

java.util.logging.FileHandler.limit = 50000

java.util.logging.FileHandler.count = 1

java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

java.util.logging.FileHandler.append = true

The first line specifies where the logging file is to be placed. Please see (http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/FileHandler.html) for other options and detials. The “%u” in the above line basically makes the log file rotate through “javaapi0.log” and “javaapi1.log”. The “count” option controls how many of these files the logger cycles through. Also don’t forget to set the append mode to true as the default this set to false. You are done. A simple program to exercise this is given below:

package logapi;

import java.util.logging.*;

/**

* A simple Java program, to understand the Java logging API

*/

public class Main {

private Logger theLogger = null;

public static void main(String[] args) {

Main hello = new Main("Hello world!");

hello.sayHello();

}

private String theMessage;

public Main(String message) {

theMessage = message;

}

public void sayHello() {

try {

//get my logger for this class.

theLogger = Logger.getLogger(Main.class.getName());

// log a message at INFO level

theLogger.info(“info message...");

// log a message at SEVERE level

theLogger.severe("severe message...");

} catch(Exception e){

// caught exception, lets log it

theLogger.log(Level.SEVERE,"Caught excepttion, ",e);

}

}

}

Once you compile this program using javac to Main.class, you will execute this program with the following command:

java -Djava.util.logging.config.file=/Users/user/LogApi/mylogging.properties Main

You are asking the jvm to load your own logger.properties file with the “-D” switch. This is the output of this program:

localhost:classes user$ java -Djava.util.logging.config.file=/Users/user/LogApi/mylogging.properties Main

Dec 21, 2008 8:55:08 PM logapi.Main sayHello

SEVERE: severe message...

localhost:classes user$

The program after execution also wrote a file called “javaapi0.log” and the contents of this file are:

localhost:classes user$ more javaapi0.log

Dec 21, 2008 8:59:32 PM logapi.Main sayHello

INFO: info message...

Dec 21, 2008 8:59:32 PM logapi.Main sayHello

SEVERE: severe message...

localhost:classes user$

Notice that on the console we only saw the “SEVERE” message but the log file has both the info and the sever messages.

If you don’t want to mess around with the properties files but rather want to control the logging programmatically, we can do that also. Although I advise not doing this as you have no control over the logging once the program is rolled out to the filed except re-compiling. However, I will show you how we can do this programmatically just for understanding sake. I hope you have read the other detail tutorial on the web and know the hierarchy of the loggers and their default behaviour. The basic behavior of the logger is when the message comes to it for logging, it checks with its filter and if the message passes the filter the message is handed over to the installed handlers and then the message is also passed on to the parent logger. The parent logger does the same thing till we hit the “root” logger. The root logger handlers are installed at the start of the JVM through the properties file sitting under JRE/lib directory. What we will do is install our own Console and File handlers and then disable the use of the parent handlers by calling the method “theLogger.setUseParentHandlers(false)”. That way we make sure that the only handlers the message passes through are the handlers we install. Here is the code for this:

import java.util.logging.*;

/**

* A simple Java program, to understand the Java logging API

*/

public class Main {

private Logger theLogger = null;

public static void main(String[] args) {

Main hello = new Main("Hello world!");

hello.sayHello();

}

private String theMessage;

public Main(String message) {

theMessage = message;

}

public void sayHello() {

boolean append = true;

try {

// create my own Handlers for file and console

FileHandler fh = new FileHandler("/Users/user/LogApi/build/classes/javaapi%u.log", 50000, 2, append);

//ConsoleHandler only if we need to log to Console

ConsoleHandler ch = new ConsoleHandler();

//get my logger for this class.

theLogger = Logger.getLogger(Main.class.getName());

// the logging gets bubbled up to the parent and the parent default

// handlers are used. Lets disable the use of the parent Handlers.

theLogger.setUseParentHandlers(false);

// set the formatting for the log file to the simple

fh.setFormatter(new java.util.logging.SimpleFormatter());

// install our own handlers in to the logger.

theLogger.addHandler(fh);

// ConsoleHandler Seetings only if we want to log to console.

ch.setLevel(Level.SEVERE);

theLogger.addHandler(ch);

// log a message at INFO level

theLogger.info("info message...");

// log a message at SEVERE level

theLogger.severe("severe message...");

} catch(Exception e){

// caught exception, lets log it

theLogger.log(Level.SEVERE,"Caught excepttion, ",e);

}

}

}

Compile this to Main.class and execute to get the same effect as the previous program.

Finally, the reason I had to deal with this is, we were working on a Java program to parse some files on a regular interval (every 2 minutes). This program got installed under cron. As you know, under cron anything that is written to the stdout or stderr gets emailed to the user under which the program is running. If you start logging a lot of messages to stdout/stderr (the console) you will get a lots of messages flooding your inbox. Worst yet, the /var/mail/user file may continue to grow and fill up the whole space if the program is left running for a long time without cleaning the messages. If we selectively log messages to the console, then you get an e-mail message for the critical messages that you want to see any ways.

http://www.onjava.com/pub/a/onjava/2002/06/19/log.html

http://www.crazysquirrel.com/computing/java/logging.jspx

http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html

]]> http://blogs.circlesource.com/2008/12/22/logging-with-%e2%80%9cjava-logging-api%e2%80%9d/feed/ 1