Hi lynn,
A filter, e.g. a CLI show | select statement, a NETCONF, JSON-RPC, MAAPI query etc. is something that is transformed to a filter that the ConfD core engine understands.
You want to get this “filter” that ConfD use and pre-filter in your data provider application, but there is no API to pass the “filter” to your data provider in ConfD.
So if you absolutely cannot live with the ConfD core engine doing the filtering for you, but must pass a filter to your data provider application to do some more efficient pre-filtering depending on what the manager types in the CLI, you can for example implement your own CLI pipe command.
The pipe command implementation can then pass the filter parameters in some way of your choice to your data provider for “pre-filtering” before your data provider pass the data back.
E.g. create a commands-c.cli config spec file that looks something like this:
<clispec xmlns="http://tail-f.com/ns/clispec/1.0" style="c">
<operationalMode>
<modifications>
<addPipeFlags src="show">filter</addPipeFlags>
</modifications>
</operationalMode>
<configureMode/>
<pipeCmds>
<cmd name="filter">
<info>filter</info>
<help></help>
<options>
<pipeFlags>filter</pipeFlags>
</options>
<callback>
<capi>
<cmdpoint>showfilter</cmdpoint>
</capi>
</callback>
<params>
<param>
<type>YOUR INPUT TYPE HERE</type>
<info>&lt;SOME HELP&gt;</info>
<help>SOME HELP</help>
<name>PARAMETER NAME</name>
</param>
<params>
</cmd>
</pipeCmds>
</clispec>
The “cmdpoint” showfilter specifies the name of the C-API action to be called. For this to work, you need to register an actionpoint with the ConfD daemon at startup (besides the callpoint).
If you don’t want to implement this as an actionpoint you can run an executable (e.g. a shell script or a c-program) instead that pass the filter parameters to your data provider application.
<callback>
<exec>
<osCommand>SOME PATH/showfilter.sh</osCommand>
</exec>
</callback>
See man/man5/clispec.5 and examples.confd/cli/show_templates/confd.cisco.cli for a somewhat related example.