The mapping rules can be syntactically checked by selecting the Test Grammar button in the mapping rules configuration. The adapter checks the syntax, reports whether it found any errors, and reports the specific error to the best of its ability.

It is important to understand that the adapter will not check your rules for semantic accuracy, or check whether statements are accurate for your particular environment. For example, if you misspell a network name, the adapter is not going to check the networks in Network Configuration Manager and inform you of the misspelling.

It will only check the structure of the rules, not the meaning of the rules. Remember, in the case where no rule matches, the defaults will be used from the Synchronization Options, so it may not always be obvious there is an error in the mapping rules.

Once the structure is correct, the rules can be saved selecting the Save button. For your convenience, the rules are reformatted in a comma delimited format, making for easy import and export to a spread sheet. It may be easier to work in a spread sheet for complex rule sets, or if you are working offline.

Save the rules as a comma delimited format, and paste them into the text fields when you are ready to use them. The adapter will parse rules either delimited by commas or spaces.

Another aid for developing and debugging rules is the addition of a log file dedicated specifically to rule processing. In the same location as the main log, vc_smarts_adapter.log, you will find a rule processing log named vcsmarts_mapping_rules.log.

An entry in the log is made for every device processed by the rules engine during batch synchronization. It will indicate which rule was fired for each device, and the reason or match values that led to firing the rule. Using this log, you can understand what happened to each and every device during processing. Additionally, the log file is constructed in a strict comma delimited format so that you can import it into a spread sheet for analysis.

The structure is as follows, with the fields listed in order:

  1. Date

  2. Timestamp

  3. Timestamp millisecond counter

  4. Rule set or direction - V2S means Network Configuration Manager to Smarts Manager; S2V means Smarts Manager to Network Configuration Manager

  5. Device name

  6. Origin - IP Availability Manager or Network

  7. Destination

  8. Match type - No Match, IP, Name, None (no-op), Excluded

  9. Match value – the value matched causing the rule to fire

  10. Delimiter – indicates that following is the actual rule

  11. Actual rule fired (delimited as well)

    For easy examination, import the log into a spread sheet, and drop the first three columns. This view offers a clear re-enactment of the rule firings on a device-by-device basis. Note that NO MATCH and NONE are not the same thing. NO MATCH means that no rule was fired and the default destination was used. NONE means that the no-op filter was defined in the rule that was fired.

    Finally, if rule configuration and processing seems confusing, take it one step at a time. Remember that when executing the synchronization, devices go into Network Configuration Manager jobs and the pending list for Smarts Manager. You can delete these if they do not appear to be what you want before they execute. In Network Configuration Manager, deleting the actual auto-discovery entry will also delete the job created from it as well. That is the best place to delete unwanted entries. You can execute batch synchronization as many times as you like, provided the data set is not too massive.

    One approach to learning mapping would be to exclude everything but a single IP Availability Manager coming from Smarts Manager, and route that into a couple of practice networks in Network Configuration Manager. Execute the batch synchronization, and get comfortable with the rules and examining the log. Then, remove the pending list entries or auto-discovery entries in Network Configuration Manager, and expand the list of devices. You will find the rules easy to navigate.