This kind of thinking should be mandatory - if you care enough about
your MQ message to use make it persistent and use syncpointing, then you
should also care enough to log details of it at every point that an app
tinkers with it. Support people / developers have a far easier time
avoiding the finger-pointing, and bean counters can ask for all kinds of
numbers to be generated from the log records.
Darren
Roger Lacroix wrote:
Hi,
Actually, I recently designed and built some middleware glue to do just
that for a client.
The message flow was:
1) External client -> (A) transformation engine (B) -> Business logic
2) Business logic -> (C) transformation engine (D) -> External client
I wrote some Java middleware that the transformation engine called to do
the MQ messaging (points A, B, C & D). A complete transaction included a
request message ('1') and a response message ('2'). There are also cases
where a 'one-way' response is sent to the external client ('2').
In both cases, each transaction has a unique transaction ID.
The Java middleware glue uses an Oracle table to record everything and it
is keyed off the unique transaction ID.
Java middleware glue description:
- Point A inserts a record into the table with column 'ClientIn' with the
current time
- Point B puts a message to a queue with COA & COD, a special 'Reply-To-Q',
ApplicationData has the transaction ID and AccountingToken has the 'DB
ColumnName'. It also updates the column 'BusinessIn' with the current time
of the DB record.
- Point C updates the record in the table with column 'BusinessOut' with
the current time
- Point D puts a message to a queue with COA & COD, a special 'Reply-To-Q',
ApplicationData has the transaction ID and AccountingToken has the 'DB
ColumnName'. It also updates the column 'ClientOut' with the current time
of the DB record.
All of the COAs and CODs go to the same special 'Reply-To-Queue'. I wrote
a Java Daemon ('CO Daemon') that handles reading all of the incoming COAs
and CODs. It runs 7/24.
Now the real trick: When MQ sends either a COA or COD, it includes the
MQMD values from the original message.
So the Java 'CO' Daemon reads a message from the 'Reply-To-Q' and retrieves
the transaction ID from the ApplicationData field and retrieves the
ColumnName from the AccountingToken field and then updates the appropriate
column's COA or COD field of the DB record.
To make this middleware glue super fast, every night all records in the
'current table' are moved to the history table'.
I also wrote a simple GUI interface to lookup transactions in the database.
So when an external client or the business people phone about a 'lost
message', we ask for the transaction ID and in 2 seconds we know the
complete history of the transaction.
Of course, now that people are getting used to having this information, the
client has asked for alerts to be generated if 'client hasn't picked up
their message in 30 minutes' - i.e. missing COD message.
They want stats on what is the average transaction time, what is the
average transformation time, what is the average time for the business
logic component, etcâ¦
This middleware glue really keeps the finger pointing to a minimum.
On a different note, I learnt a lot about Oracle and hard-parsing. :)
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
On Fri, 23 Mar 2007 08:31:20 -0400, Glen W Brumbaugh <[EMAIL PROTECTED]>
wrote:
As a follow to my response, we have all wished for what, in messaging
terms, is called non-repudiation. That is the ability to prove that a
message was sent and that it was received. This would, occasionally, be
an awesome feature. The only way to support this would be to log the
messages. Wait! We already do that when using linear logs. An
enhancement (SWG guys from the lab - any comments?) or SupportPac that
processed log files for messages would save both developers and
administrators a lot of team as well as being a significant value add to
the product.
Regards,
Glen W. Brumbaugh
Glen W. Brumbaugh
Solutions Architect - WebSphere Messaging Based Solutions
IBM
Global Technology Services
To unsubscribe, write to [EMAIL PROTECTED] and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to [EMAIL PROTECTED] and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
To unsubscribe, write to [EMAIL PROTECTED] and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
