Database Reference
In-Depth Information
currtask.getEdiProcessReportLevel()
);
}
catch(Exception ex) { ex.printStackTrace(); }
}
//Implementation of the basic logger in LogHandler
public void log(String ipMsgtype, String ipMsgtext,
String ipMsgcode, String ipUsermsg, String ipMsgsrc,
String ipMsgjobid, String ipLoglvl) throws
java.io.IOException
{
EventLogHandler logwriter = new EventLogHandler();
logwriter.log(ipMsgtype, ipMsgtext, ipMsgcode,
ipUsermsg, ipMsgsrc, ipMsgjobid, ipLoglvl);
}
....
//Typical use
logger.log( "INFO", "Rule engine in use : " +
RuleEngineType , mheader.getXDIMsgId(),
mheader.getXDIUser(),
"XDI.RuleEngine", mheader.getXDIJobRefId(), "3" );
Although the realization of the Logger WS is pretty straightforward, it also has two dis-
tinctive paths: either you write data directly into the DB or enqueue the message into Ad-
vanced Queue. Anyway, it is a one-way service and must not disrupt message processing.
It is important to mention that Log4j (or a newer SLF4J library if you choose to use it)
also has its own configuration for level and layout, which we set in a LogHandler.
Now, after the helper's initiation, our first task is to recognize an inbound message. There
are two possible strategies here, based on the XML parsing: DOM and SAX . Obviously,
each strategy has its own pros and cons, but if we require really high performance, we
should rely on MsgID recognition by the SAX parser. We instantiate the SAX cm-
dHelper in the servlet's processRequest and execute the SAX parsing function.
The SAX parsing sequence is presented by the following code snippet:
//In XDIServlet, processRequest
MessageCommand cmdHelper = helper.getCommand();
Search WWH ::




Custom Search