Server Instrumentation Library (SIL) Development
Server Instrumentation Libraries (SILs) contain your code that hooks the YANG data models into the system, to perform the device and network changes associated with the configuration changes, report operational data and create notifications.
Tools provided with all versions of YumaPro SDK automate the process of developing this instrumentation by creating the protocol binding, encoding and transaction engine code for you. This allows your developers to focus on their area of expertise, your platform code, and leaves the YANG and protocol work to our experts at YumaWorks.
Step 1: Define a common YANG module
The operations and database contents are defined in a YANG data model module. The SIL code for this module will be protocol and encoding independent, providing NETCONF, RESTCONF, and CLI interfaces for the content defined in the YANG module.
Step 2: Generate the SIL code stubs
To generate the source files for a YANG module named ‘address’, use the ‘make_sil_dir_pro’ script. This uses yangdump-pro to generate the individual C and H files.
make_sil_dir_pro –split address
The file y_address.c contains the glue code to hook the user callback code into the transaction engine. This file should never be edited.
The file u_address.c contains the user callback functions needed to hook the YANG defined configuration data to the underlying system. The code stubs in this file typically contain system-specific function calls to commit database changes.
Step 3: Decide which transaction phases need user callback functions.
- Validate Phase: A user callback is only needed here if system validation or “description statement” validation is required. All machine-readable YANG statements related to validation are handled automatically by the transaction engine. The validate phase has to complete without error for all modified object instances. No system resources should be allocated or modified during this phase.
- Apply Phase: A user callback is only needed here if system resource reservation is supported. The target database is modified by the transaction engine using fully recoverable edits, whether that is the candidate or running database. The user callback code may support recoverable resource reservation during this phase. After this callback is invoked, either the commit or rollback phases will follow, allowing the user callback code to commit or cleanup any system resources.
- Commit or Rollback Phase: A user callback for the commit phase is needed to apply configuration changes to the system. Once the commit callback has been done for an object instance, no further callbacks will be done for the current transaction. Either the commit callback or the rollback will be invoked, but not both. The transaction engine will construct a new edit to undo configuration changes if a commit partially finishes and some completed edits need to be rolled back.
Step 4: Hook your system callbacks into the edit function.
Distributed SIL (SIL-SA)
Asynchronous Distributed Transactions:
Server instrumentation code can run in the main server or in multiple sub-agents. SIL-SA and YControl libraries link with your process and handle all communication and transaction management with the main server.
The difference between SIL & SIL-SA is that SILs are synchronously connected to the server in the same process and the SIL-SAs are asynchronously connected to the server so that they can instrument different processes such as line cards in a chassis based device. There are many server APIs that are only available to the SIL libraries.
For more information on SIL-SA, refer to our Knowledge Base: