Database Reference
In-Depth Information
+" ackReceiptID:"+ackReceiptID
+" ackDateReceived:"+ackDateReceived
+" ackDateProcessed:"+ackDateProcessed
+" ackTradingPartnerID:"+ackTradingPartnerID
+" ackFileName:"+ackFileName
+" ackReferenceNumber:"+ackReferenceNumber
+" ackMessageID:"+ackMessageId
+" ackMessageStatusCode:"+ackMessageStatusCode
+" ackEventCode:"+ackEventCode
+" ackEventDescription:"+ackEventDescription
+" ackEventSource:"+ackEventSource
+" ackAction:"+ackAction;
}
When we talk about Message Header, we assume that it will be based (if not compatible)
on the SBDH standard. For Acknowledge , there are no publicly accepted standards, but
the structure of an existing, common Logging service (and its storage) could be a good
start. In this design, a traditional log4j library was used for technical errors and a log
DB structure was standardized long before the creation of this Message Broker. In addition
to this, the function-related LogHandler is responsible for choosing an appropriate way
to register business events (type of information, warning, and error).
Naturally, WS realization will be the most atomic and modular, therefore LogHandler
has the capability to select the logging procedure. However, there were some concerns re-
garding possible performance deprivation. Logging level and realization are the paramet-
ers settled during servlet's initialization, and the default values are in the web.xml
descriptor. We must remember that parameters acquired during the init phase will stay
active during the servlet's life. Therefore, the logging level of the process must be config-
urable from the execution plan's header:
// Implementation of the task logger in LogHandler
public void log(String ipMsgtype, Task currtask) throws
java.io.IOException {
try{
log(ipMsgtype,
getLogEventDescription(currtask),
currtask.getMsgId(), currtask.getSenderTPId(),
currtask.getTaskEngine(),
currtask.getXDIInstanceID(),
Search WWH ::




Custom Search