Fix #309: make channelName available in Postprocessor script - #395
Conversation
cfe7bcb to
0de1890
Compare
|
@ggiannola, this works in the post processor. logger.info(ChannelUtil.getChannelName(channelId))Not that your PR is "wrong", but based on this trivial workaround it seems unnecessary. |
jonbartels
left a comment
There was a problem hiding this comment.
Approved.
I have a non-blocking comment - Are there other fields missing from the post-processor?
You found that channelName was missing. Are there other common fields from other scripts that are missing that could also be added in this PR?
Thanks @pacmano1 agreed. Worth noting the postprocessor scope already tries to supply channelName; it was wired in deliberately back in 2015 (2fd0148, MIRTH-1763) and has silently been null ever since because Message.getMergedConnectorMessage() never populated the field. So this is a latent bug rather than a new feature. It's also broader than the variable, message.getMergedConnectorMessage().getChannelName() is public userutil API and returns null in every postprocessor, which ChannelUtil doesn't address. 4 lines, no API change. But if you'd rather leave it, happy to close. |
|
@ggiannola , I'll defer to the other maintainers. I am wishy washy on it, lol. |
tonygermano
left a comment
There was a problem hiding this comment.
Looks good to me. Thanks for the fix and added tests!
…essor script The Postprocessor scope derives channelName from message.getMergedConnectorMessage().getChannelName(), but Message.getMergedConnectorMessage() never populated channelName on the merged ConnectorMessage. As a result the channelName variable was null in Postprocessor scripts, even though it is available in Deploy, Undeploy, and Preprocessor scripts. Populate channelName on the merged connector message from the Message's own channelName, falling back to the source connector message's channelName (which is reliably set during processing). Adds MessageTest covering the three cases. Signed-off-by: Giovanni Giannola <giogiannola@globalesm.com>
New files in this project use SPDX headers attributing copyright to the contributor, rather than the legacy Mirth Corporation header carried by pre-fork files. Signed-off-by: Giovanni Giannola <giogiannola@globalesm.com>
0de1890 to
c556c59
Compare
Summary
Fixes #309. The
channelNamevariable was not available in Postprocessor scripts, even though it is available in Deploy, Undeploy, and Preprocessor scripts.Root cause
The Postprocessor scope (
JavaScriptScopeUtil.getPostprocessorScope) deriveschannelNamefrommessage.getMergedConnectorMessage().getChannelName().However,
Message.getMergedConnectorMessage()built the mergedConnectorMessagesettingchannelId,messageId,serverId, andreceivedDate— but neverchannelName. The value therefore resolved tonullin Postprocessor scripts.This also explains why the other script contexts were unaffected: they receive the channel name directly (Deploy/Undeploy via
getDeployScope/getUndeployScope, Preprocessor from the connector message) rather than through the merged connector message.Fix
In
Message.getMergedConnectorMessage(), populatechannelNameon the merged connector message:Message's ownchannelNamefield, andchannelName, which is reliably set during processing (see theConnectorMessageconstruction inChannel).The fallback matters because the
Messagecreated during processing does not always carrychannelName, while the source connector message does.Tests
Added
MessageTestcovering three cases:channelNamefrom the source connector message.Message-levelchannelNamewhen set.channelNamestaysnullwhen unavailable, so the fix does not fabricate a value.Verified with
./gradlew :donkey:test: 21 tests pass, 0 failures (MessageTest3,StatisticsTest9,JdbcDaoTest8,ChannelTest1).