Open rbeckman-nextgen opened 5 years ago
Or possibly the transformer could just return a Status (including Filtered?). I don't think the return value of the transformer is currently used for anything.
Imported Comment. Original Details: Author: agermano Created: 2018-07-05T08:44:04.000-0700
I can see where this would be very useful fro stats tracking. If I were to use a programmatic method to remove the message from a destination, I would like the destination to mark it as filtered.
Imported Comment. Original Details: Author: stormcel Created: 2019-05-01T11:50:13.000-0700
I've come across multiple scenarios where in the transformer a value needs to be retrieved from another system/channel to include in the current message. If that value is not available at the current time (remote server outage, value does not yet exist, etc...) it would be very helpful to have a way to indicate to the destination connector that the message is not fit to be sent at this time. connectorMap.put('mirth_force_status', Status.QUEUED) would be an easy way to set it.
Currently my workaround is to find a field in the connector properties that I can set to a velocity variable. During processing, that variable is set to the valid value if I want the message to complete processing. It is set to a value that I know will cause the connector to error when I want to queue, and then I must check in the response transformer if it is a valid error or forced. If it was forced then I update the status to queued.
Besides being cumbersome, this leaves the error artifact behind when looking at the queued message in the message viewer, and it remains even after the message finally is sent. It also generates events that appear to be errors and are caught by any Alerts that may not be set up to specifically exclude this error. The error itself is different for each connector type since you can't break them all in the same way.
Imported Issue. Original Details: Jira Issue Key: MIRTH-4255 Reporter: agermano Created: 2018-03-30T09:52:50.000-0700