Mirth 3.0.1.7051
Java 1.7.0_51
Server 2008 R2 x64
I have read several threads on how Mirth does not remember state. If you reprocess a message that uses the variable ${originalFilename}, the file will be named timestamp.dat.
How does one recover from an error and reprocess a message maintaining the original filename? without having to externally resend the message for reprocessing.
I suppose you could pre-process the file by storing the file and filename to a database and tracking delivery yourself, but this seems les than ideal being as Mirth is already storing the file and several other metadata components.
Am I missing something or is there a clever way to maintain the filename for reprocessing?
I had one interface with a tab delimitated text file that contained the filename. I was able to assign a transformer variable with the filename and use that to name the file on first pass and reprocess event. This would not work with a PDF file.
maybe I am missing something, but one of the benefits of using Mirth is the notion of "Durable Message Delivery" and email alerts if there is a problem.
As I understand the message Queue/Retry settings
Never: if there is a connection error, the message will fail and you can not reprocess because the file will have timestamp.dat for the filename. An alert can be sent and you know about it.
Attempt first: will try and then queue the message giving you settings for the retry count on an interval ultimately resulting in the same condition. Requiring you externally reprocess the file so Mirth can have another go at it. again, an alert can be sent and you know about it.
Always: removes the retry count, so the message will retry indefinitely on interval. If it takes three days for you to login and notice there are queued messages and you fix the connectivity problem the message will process with the correct filename?? but there is no alert email in the meantime??
Java 1.7.0_51
Server 2008 R2 x64
I have read several threads on how Mirth does not remember state. If you reprocess a message that uses the variable ${originalFilename}, the file will be named timestamp.dat.
How does one recover from an error and reprocess a message maintaining the original filename? without having to externally resend the message for reprocessing.
I suppose you could pre-process the file by storing the file and filename to a database and tracking delivery yourself, but this seems les than ideal being as Mirth is already storing the file and several other metadata components.
Am I missing something or is there a clever way to maintain the filename for reprocessing?
I had one interface with a tab delimitated text file that contained the filename. I was able to assign a transformer variable with the filename and use that to name the file on first pass and reprocess event. This would not work with a PDF file.
maybe I am missing something, but one of the benefits of using Mirth is the notion of "Durable Message Delivery" and email alerts if there is a problem.
As I understand the message Queue/Retry settings
Never: if there is a connection error, the message will fail and you can not reprocess because the file will have timestamp.dat for the filename. An alert can be sent and you know about it.
Attempt first: will try and then queue the message giving you settings for the retry count on an interval ultimately resulting in the same condition. Requiring you externally reprocess the file so Mirth can have another go at it. again, an alert can be sent and you know about it.
Always: removes the retry count, so the message will retry indefinitely on interval. If it takes three days for you to login and notice there are queued messages and you fix the connectivity problem the message will process with the correct filename?? but there is no alert email in the meantime??
.dat files -- reprocessing
0 commentaires:
Enregistrer un commentaire