These links should help you get started learning about programming with YumaPro APIs.

Is there a Callback starter document?


YumaPro provides pre-transaction, in-transaction and post-transaction APIs to manage behavior of a database edit transaction, such as its functionality, order, etc. This section list all the callbacks available in the server.


Database Transaction Callbacks

Check the Online Manual for Up to Date Information

Database Operations

Edit Transaction Examples



The following transaction management APIs are used to manage an object that is being edited or retrieved. They are used to provide a callback sub-mode for a specific named object.

  • EDIT-2 callback: 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 callback.
  • SIL-SA EDIT2 callback: The SIL-SA EDIT2 callback usage is the same as the EDIT2 callback except EDIT2 MERGE handling. The difference is only in the children edits access APIs.
  • GET-2 callback: Used for the <get> operation. There is 1 GET2 callback for the object, not each instance in the data tree. GET, GETNEXT, and GETBULK operations are supported.
  • GET2 All In One (AIO) callback: AIO GET2 callbacks follow exactly the same template as regular GET2 callbacks, they use the same registration API and are getting invoked the same way for SIL and SIL-SA as regular GET2 callbacks. The main difference is that there will not be any callback invocations and there will not be any callbacks at all for any of AIO node children.


In Transaction Callbacks

Check the Online Manual for Up to Date Information

In Transaction Callbacks


In-transaction capabilities are being added to the netconfd-pro server API to allow an application to update the configuration data and perform additional actions while the transaction is in progress. This can be a vital solution to implement many services in switch/router management operations.


The following diagram illustrates what callbacks are invoked and when to expect them to be invoked during the transaction.



The following callback APIs are supported:

  • Set Hook: Similar to the EDIT2 callbacks, except this callback is only invoked once at the start of the edit for a particular data node. This callback can alter the data in the current edit and also add new edits to the current transaction. This callback will be invoked BEFORE EDIT2 callbacks for the same object.
  • Post Set Hook: Similar to the Set Hook callback except that it is invoked when an object is modified but AFTER EDIT callback is done for the same object. This callback will be invoked AFTER EDIT2 callbacks for the same object.
  • Transaction Hook: Similar to the Set Hook except this callback is invoked just before the data is committed to the running datastore. This callback will be invoked after EDIT1 or EDIT2 callbacks for the same object.
  • Transaction Start: The callback that is intended to provide access to the transaction control block and its parameters right before the transaction is started.
  • Transaction Complete: The callback that is intended to provide access to the transaction control block and its parameters right after the transaction is completed. Called for every transaction completion, not just transactions that complete without errors.  
  • Validate Complete: The callback is intended to allow manipulations with the running and candidate configurations (equivalent to completion of Validation Phase during <commit>).
  • Apply Complete:  The callback is intended to allow manipulations with the running and candidate configurations (equivalent to completion of Apply Phase during <commit>).
  • Commit Complete: The callback is a user/system callback that is invoked when the <commit> operation completes without errors or the internal <replay-config> operation completes without errors.
  • Rollback Complete: The callback is the user/system callback that is invoked after and if the Rollback Phase has been processed during the <commit> operation.
  • Set Order Hook: Set the secondary SIL priority for instances of the same list object that is being set in the same edit.  This allows the instance SIL callback order to be set in addition to the object priority.
  • Startup Hook: The callback function that is invoked before any changes done to the <startup> datastore. It is invoked only if the <startup> capability is enabled.
  • Dynamic Default Hook callback: The callback function that is the user/system callback that can be used to set up dynamic default value to the non-default leafy nodes during load or edit-config operations. It is invoked when the server checks if the node has any defaults and if there is no any YANG defined defaults the server can update the node with custom “system” default value.


The following API functions are supported that can be called from the Set Hook or Post Set Hook callbacks:

  • Add Edit (agt_val_add_edit): Add an edit operation to the current transaction.
  • Get Data (agt_val_get_data): Retrieve an instance of a data node from the server.

The following API functions are supported that can be called from SIL-SA code for the Set Hook or Post Set Hook callbacks:

  • Add Edit (sil_sa_add_edit): Add an edit operation to the current transaction

  • Get Data (sil_sa_get_data): Retrieve an instance of a data node from the server.


Manipulation with configuration data is only allowed for Set Hook and Post Set Hook callbacks, however. If Transaction Hook, Start/Complete Transaction, or Commit Completeness callbacks are trying to adjust configuration data via add_edit() API, the operation will be skipped. However, this action will not generate an error, just a warning message in the log with log-level equals debug2.


The netconfd-pro provides the following SIL-SA support for In-Transaction APIs:

  • SIL-SA Transaction Start: The callback that is intended to provide access to the transaction control block and its parameters right before the transaction is started. For SIL-SA usage the server does not provide transaction control block, instead it passes the transaction ID for reference and some crucial information about the transaction, such as the information about whether the current transaction is for the running datastore, is the transaction for validate operation, or if it is  for Rollback Phase.
  • SIL-SA Transaction Complete: The callback that is intended to provide access to the transaction control block and its parameters right after the transaction is completed. Called for every transaction completion, not just transactions that complete without errors. For SIL-SA usage the server does not provide transaction control block, instead it passes only the transaction ID for reference.
  • SIL-SA Set Hook: The callback that is intended to alter the data in the current edit and or add new edits to the current transaction. For SIL-SA version of this callback the transaction control block is not available, instead the server provides all necessary information as a set of parameters.
  • SIL-SA Post Set Hook: The callback that is intended to alter the data in the current edit and or add new edits to the current transaction after the EDIT callbacks for the same node. For SIL-SA version of this callback the transaction control block is not available, instead the server provides all necessary information as a set of parameters.
  • SIL-SA Transaction Hook: The callback that is intended to provide validation point for specific node(s). For SIL-SA usage the server does not provide transaction control block, instead it passes the transaction ID for reference and some crucial information about the transaction, such as the information about whether the current transaction is for the running datastore, is the transaction for validate operation, or if it is for Rollback Phase.
  • SIL-SA Validate Complete: The callback that is intended to provide validation point after the Validate Phase is completed. For SIL-SA usage the server does not provide running and candidate values, instead it passes the transaction ID for reference and Get Data API can be used to run additional validation if required.
  • SIL-SA Apply Complete: The callback that is intended to provide validation point after the Apply Phase is completed. For SIL-SA usage the server does not provide running and candidate values, instead it passes the transaction ID for reference and Get Data API can be used to run additional validation if required.
  • SIL-SA Commit Complete: The callback that is intended to provide validation point after the Commit Phase is completed. For SIL-SA usage the server passes the transaction ID for reference, commit type and Get Data API can be used to run additional validation if required.
  • SIL-SA Rollback Complete: The callback that is intended to provide validation point after the Rollback Phase is completed. For SIL-SA usage the server does not provide running and candidate values, instead it passes the transaction ID for reference and Get Data API can be used to run additional validation if required.



In-Transaction callbacks are NOT part of the yangdump-sdk code generation. After the make_sil_dir_pro script is run, In-Transaction callbacks will NOT be auto-generated. All the In-Transaction callbacks are optional and merely intend to provide more efficient way to manipulate with the database and give an access to the database at the specific phase, transaction, and an edit.



System Callbacks

The callback functions described in this section are invoked as part of a normal server operation.


They can be registered from the yp-system library module or a SIL module. Refer to the file /usr/share/yumapro/src/libsystem/src/example-system.c for examples of the callbacks in this section.



  • Candidate Reload callback: There can be one callback registered to be invoked each time the candidate datastore is reloaded from the running datastore, such as the <discard-changes> operation.
  • Module Load callback: 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: There can be multiple callbacks registered to be invoked when a module is unloaded from the server. A transaction to remove module configuration data will also be generated, in addition to this callback.
  • NV-Load callback: There can be one callback registered that is invoked when the server needs to retrieve the configuration contents from non-volatile storage.
  • NV-Save callback: There can be one callback registered that is invoked when when some config needs to be saved to Non-Volatile storage.
  • Periodic Timer Service: The timer callback function is expected to do a short amount of work, and not block the running process.
  • Session Hook callback: The session hook callback function is a user callback that is invoked when a session starts and ends.
  • Shutdown callback: The shutdown callback function is a user callback that is invoked when the server is about to restart or shutdown.
  • Command Complete callback: The command complete callback function is a user callback that is invoked when the server has completed an RPC operation and the response has been generated to the client (may not have been sent yet).
  • NACM External Groups callback: The NACM External Groups callback function is a user callback that is invoked when the server creates a new client session for NETCONF or RESTCONF sessions. It is used to retrieve a list of group names that should be used for the specified username, just for that session.
  • User Defined Data Types callbacks: User defined data types are supported with callback functions that apply to all YANG leaf or leaf-list nodes using a specific data type.