2

I am trying to find a better way to generate XML RPC requests to be sent to a device with NETCONF tags in it.

We know how request should look like, so what I am doing is, just hard coding the XML-RPC request XML with placeholders in it. Those placeholders can be replaced with actual input later.

Eg:

<rpc message-id="">
  <get-config>
    <source>
      <running/>
    </source>
    <filter type="subtree" base_path="">
      <wing-stats>
        <device>
          <lldp>
            <dev_id/>
            <local_port/>
            <neighborId/>
            <Neighbor_port_id/>
          </lldp>
          <mac>@device_mac</mac>
        </device>
      </wing-stats>
    </filter>
  </get-config>
</rpc>

Here in this example, @device_mac will be replaced while send the request. But some how I felt I am hardcoding the request XML. Is there any better way of generating the request XML?

Netconf data will be modelled using YANG/YIN files. Is there a way I can make use of these files to generate NETCONF request part atleast?

predi
  • 5,528
  • 32
  • 60
Bala
  • 105
  • 1
  • 10

2 Answers2

1

Bala,

I'd say there are two ways to do this: you can either use any of the date model driven toolkits that are available and I know that at least one of them generate model-oriented APIs and hide the detailed XML (DOM) manipulation. The second direction is to make use of the YANG to DSDL mapping defined in RFC 6110 as implemented by the pyang tool. Now, the latter one requires that your tools can work with DSDL which is essentially a combination of Relax NG and Schematron.

Hope this helps.

Community
  • 1
  • 1
  • I too would recommend using pyang DSDL plugin to create a Relax NG schema and then generate rpc messages from it somehow. Such schema are ment to be used for validation of existing NETCONF content though and generating content from them may require some effort to implement. I know I had trouble finding tools which would help me work with RNG in Java. The mapping is defined in RFC6110.. – predi Apr 11 '12 at 11:36
0

I'd say that it all depends on your context. If your application meant to support this particular model and this particular rpc only then it'd be probably an overkill to use any more sophisticated, model-independent API for such a small use case.

On the other hand if your application has to support many models and rpcs or even if it needs to support new models added at runtime then definitely you should explore the solutions that may be applied to any model such as those mentioned by Carl.

Piotr Babij
  • 837
  • 5
  • 12