Jerome Lefebvre

Localizing the AF Example kits - Part 2 – Fixing analysis mapping after import

Blog Post created by Jerome Lefebvre on Aug 31, 2016

This is an ongoing series introducing the various code examples I and others have created in the goal of localizing the various AF example kits.


Part 0: URI Builder data reference in AF 2016

Part 1: Localizing the AF Example kits - Part 1 - Exporting a database

Part 2: This entry

Part 3: Localizing the AF Example kits - Part 3 - Reset to Template


Objects in AF tend to have configuration string, it is a way to serialize the object and is what allows you to export your favorite AF Template and share it with friends and family grateful coworkers.


As you progress in your path towards AF mastery, your knowledge of each of these configuration strings will surely grow and I will talk more about then in future entries to this blog series. This time, I want to highlight one configuration string that gave me pause at the beginning of this project to localize the AF Example Kits, the one underlying the AFVariableMap object.


The AFVariableMap object is what allows the analysis service to know where to save the output of expressions. That is, it what keeps track of the left and right side of the lines in a expression calculation.



When you look at the configuration string of an AFVariableMap, by say exporting a database to a XML file, you can see it looks like the following.



I can see the name of my variables, TotalFlowToday and ConstantNumber as well as my mapped attributes, TotalFlow and SixtyFour. The mapped attributes don’t just have their name stored, but their attribute id is stored. This is good as it allows you to rename the attributes, and the mapping will still work; if analysis tries an attribute lookup by name and fails, it will then attempt to do a look up via attribute id.

The issue is now, those ids are only valid in the database in which the elements were created. Those ids will be totally different if your were to recreate this configuration in any other database. Thus, if you export the element which contains this analysis and import it in a new database, everything will look correct as the lookup by attribute name will continue to work, but internally, these cached ids will be all wrong. This explains why renaming no longer preserves mapping for imported databases.


In AFSDK, there is happily a way to resolve this issue using the function AFAnalysisRule.RefreshConfigurationAndVariableMapping

It will look at the AFVariableMap object and update the GUID for whatever it now happens to be. To make use of it, it is quite simple, all you need to do is loop over all analysis in your freshly imported database and call this method on them.


foreach (var analysis in db.AnalysisTemplates)


The full code can be found here: