exportData content regarding channel not returning on API 'Get Channels' call

[rp-ryanwilson]

Is there a way to force Mirth to always include the 'exportData' tag content in the XML it returns from the get channel API call? If you log into the GUI Admin it always contains this data, but it's not consistent on the API call directly.

[jonbartels]

exportData has information like channel dependencies, metadata, tags, and code template libraries.

Just pass includeCodeTemplateLibraries = true in your API calls. The implementation shows how it works

connect/server/src/com/mirth/connect/server/api/servlets/ChannelServlet.java

Line 148 in 5a2e912

addExportData(clonedChannel, includeCodeTemplateLibraries);

[rp-ryanwilson]

Thanks for the reply. I don't see that as an option in the REST API call though, not sure how to pass that as a parameter. Also we don't want all of our code templates included, only the export data that includes pruning settings.

[jonbartels]

Oh!

I understand how Mirth tracks the pruner settings. I did a LOT of work around that recently. What happens is that some data like channel dependencies, tags, pruner settings, are stored in the MC config table NOT the channel table.

The easiest way to see this is to look at how the UI and CLI build the export data. Look at the CLI code. See how it gets the channel then makes a second call to get the dependencies?

The channel dependencies are retrieved from the config controller. Then they are appended into the export data before the channel export is returned to the CLI. The UI makes similar calls but they are harder to read because of the UI layers.

Since the CLI and UI make two calls to the REST API, you also need to make two calls to the REST API and amend the exportData in a similar way.

[rp-ryanwilson]

Thanks. I see how it stores the data now and it makes sense why it doesn't come out on the 'get channel' REST API call. The thing is someone must have noticed and fixed this because in our engines that are running on 4.0.1 we get the export data returned to us on just the one REST API call. But in our 3.5.1 environment the same API call doesn't return it with just the one.