# How to Identify operations in application? **URL:** \ **Category:** Core Engine and APIs\ **Created:** [September 8, 2015, 12:49pm UTC](https://dmap-community.ductus.global/t/how-to-identify-operations-in-application/199 "2015-09-08T12:49:20Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\ **Post date:** [September 8, 2015, 2:14pm UTC](https://dmap-community.ductus.global/t/how-to-identify-operations-in-application/199/2 "2015-09-08T14:14:12Z")
1. To continue from [this post](http://discuss.tail-f.com/t/how-confd-interacts-with-the-application/191/2), two common ways are for example to from your configuration change subscriber implement an `iter()` callback that you register through `cdb_diff_iterate()` or you can call `cdb_get_modifications()` For a `cdb_diff_iterate()` example see: `$CONFD_DIR/examples.confd/cdb_subscription/iter_c/cdbl.c` From the ConfD confd\_lib\_cdb man page `$CONFD_DIR/man/man3/confd_lib_cdb.3`: > The cdb\_diff\_iterate() function can be used to iterate over the changes made in CDB data that matched the particular subscription point. > > The user defined function iter() will be called for each element that has been modified and matches the subscription. The iter() callback receives the confd\_hkeypath\_t kp which uniquely identifies which node in the data tree that is affected, the operation, and optionally the values it has before and after the transaction. The op parameter gives the modification as MOP\_CREATED, MOP\_DELETED, MOP\_MODIFIED, MOP\_VALUE\_SET, MOP\_MOVED\_AFTER. For a `cdb_get_modifications()` example see [this post](http://discuss.tail-f.com/t/can-i-use-cdb-get-modifications-to-extend-the-1-2-3-intro-example-to-display-subscriber-changes/149) From the ConfD confd\_lib\_cdb man page `$CONFD_DIR/man/man3/confd_lib_cdb.3`: > When cdb\_get\_modifications() returns CONFD\_OK, the results are in values, which is a tag value array with length nvalues. > The tag value array differs somewhat between how it is described in the confd\_types(3) manual page, most notably only the values that were modified in this transaction are included. In addition to that these are the different values of the tags depending on what happened in the transaction: > • A leaf of type empty that has been deleted has the value of C\_NOEXISTS, and when it is created it has the value C\_XMLTAG. > • A leaf or a leaf-list that has been set to a new value (or its default value) is included with that new value. If the leaf or leaf-list is optional, then when it is deleted the value is C\_NOEXISTS. > • Presence containers are included when they are created or when they have modifications below them (by the usual C\_XMLBEGIN, C\_XMLEND pair). If a presence container has been deleted its tag is included, but has the value C\_NOEXISTS. > By default cdb\_get\_modifications() does not include list instances (created, deleted, or modified) - but if the CDB\_GET\_MODS\_INCLUDE\_LISTS flag is included in the flags parameter, list instances will be included. Created and modified instances are included wrapped in the C\_XMLBEGIN / C\_XMLEND pair, with the keys first. Deleted list instances instead begin with C\_XMLBEGINDEL, then follows the keys, immediately followed by a C\_XMLEND. 1. The ConfD transaction state machine: You can register with ConfD to participate in different phases of the transaction. A few of the common ones are: • **Subscriber** : An application using the CDBAPI that has requested to be notified when an operator modifies parts of the configuration that the application is interested in, e.g. set hostname or add an entry to the interface table. Called in the commit phase. • **Data Provider** : An application that knows the current value of something in the data model. ConfD will contact this application through the DPAPI to get the current value when requested by an operator, e.g. show CPU temperature. Called in the read phase. • **Validator** : An application that participates in the validation, i.e. determining if the configuration that results when applying a certain transaction is valid. A validator can respond “Yes, this is fine”, “No, this configuration is invalid because …” or “Warning: This configuration is valid, but are you aware that … (proceed/abort) ?” Validators use the MAAPI since they need to see the upcoming configuration the same way an operator sees it, not the configuration currently stored in the database. Called in the validation phase • **Two-phase subscriber** : A subscriber application that is also participating in the prepare phase using the CDBAPI. It can thereby reject upcoming configuration changes. • **Transaction hook and set hook** : An application that is invoked when an operator wants to commit a transaction, in the validation phase before the validation starts (transaction hook), or each time the operator in the write phase sets a value in a transaction (set hook). The application can then modify or extend the transaction with further modifications on behalf of the operator. These modifications are usually done in parts of the data model that are invisible to the operator. Hooks use the MAAPI since they are modifying transactions on behalf of the operator. --- _[View the full topic](https://dmap-community.ductus.global/t/how-to-identify-operations-in-application/199)._