Email us : sales@yumaworks.com

Server APIs

Developer APIs

YumaPro netconfd-pro APIs:

(1) Utility APIs

  • Notification functions provide control over notifications.
  • XPATH Handling/Validation functions can be used to manipulate XPATH expressions.
  • Error Handling functions provide various alternative ways to record an error.
  • Transaction Management functions provide control on the transaction and can be invoked within, before, and after the transaction.
  • Timer Service functions allow some SIL code that may need to be called at periodic intervals to check system status, update counters, and/or send notifications.
  • YANG Object Tree manipulation functions let you retrieve object properties without accessing them directly.
  • Extension Access functions allow to manipulate with custom YANG extensions.
  • YANG Data Tree manipulation functions provide access functions to the data nodes.

(2) Server Instrumentation Library (SIL) Utility functions provide control on SIL libraries and allows them to be used more efficiently.

(3) YControl and DB-API Interface functions provide control on subsystem and DB-API interfaces.

(4) System Callback functions allow the creation and use of general system SIL libraries.

(5) Database Access functions allow validation, manipulation, and management of your database.

(6) Access Control functions allow configuration and enforcement of a vendor specific access control model (ACM).

(7) SYSLOG and Log functions allow customized logging preferences.

 

Main Transaction Management APIs
API Description
EDIT-1 callback agt_cb_fn_t: First generation callbacks are generated by yangdump-sdk using node-based APIs. An edit function is generated for every node, including terminal nodes (leaf, leaf-list, anyxml). The GET-1 API is assumed for read-only data, so code to generate virtual read-only nodes (Make Read Only MRO) is included in an EDIT-1 callback. This is the default in yangdump-sdk and make_sil_* scripts.
EDIT-2 callback agt_cb_fn_t: Second generation callbacks are generated by yangdump-sdk using container or list-based APIs. An edit function is generated for “parent” list and container nodes only. The terminal child nodes are handled by this callback. Each nested container or list has its own EDIT-2 callback. This is generated in yangdump-sdk or make_sil_* scripts using the –sil-edit2 parameter. The same callback function signature as EDIT-1 is used, but the registration function and procedure is different.
GET-1 callback getcb_fn_t: Not used in an edit transaction but GET-1 virtual nodes for operational data are created by SIL code when the configuration node parent of the operational data is created.
GET-2 callback getcb_fn2_t: Not used in an edit transaction. GET-2 callbacks are independent of EDIT-1 or EDIT-2 callbacks. Not virtual read-only nodes are used if operational data uses GET-2 callbacks.
Candidate Reload callback cfg_reload_candidate_cb_t: There can be one callback registered to be invoked each time the candidate datastore is reloaded from the running datastore, such as the operation.
Module Load callback ncx_load_cbfn_t: There can be multiple callbacks registered to be invoked when a module is loaded into the server. A transaction to set module defaults will also be generated, in addition to this callback.
Module Unload callback ncx_load_cbfn_t: There can be multiple callbacks registered to be invoked when a module is loaded into the server. A transaction to set module defaults will also be generated, in addition to this callback.
Configuration Replay Start or Finish callback agt_replay_fn_t: There can be one callback registered that is called at the start and again at the end of a configuration replay transaction.
Commit Complete callback agt_commit_complete_t: There can be one callback registered that is invoked when the operation or the internal operation completes without errors.
NV-Load callback agt_nvload_fn_t: There can be one callback registered that is invoked when the server needs to retrieve the configuration contents from non-volatile storage.