(dumb title? perhaps…)
Hi,
one general question about the creation of WATO rule pages:
The pages I have created for Robotmk are the result of hours/days/years/lifes of reverse engineering and copy/pasting. 
Regarding the structure I would say they are fine, but even small additions make existing rules to break like this:
I wanted to ask around about your “rules of thumb” to write WATO pages which produce more robust rulesets.
Thanks & regards,
Simon
There is a special “ValueSpec” class Transform that can be used if you need to change your WATO ruleset definition. There should be some examples in the checkmk code.
You basically define a function that “transforms” the old WATO rule value to the new definition.
In addition to @r.sander’s suggestion, i have some rules where most parameters are optional.
An if possible all the parameters are only entries in a plain dictionary.
The only problem i had are with removed parameters, only add new ones is no problem then.
I never got the point why these Transforms exist. Now I know it 
Thanks!
Yes, one thing I discovered to be not ideal is using simple lists and accessing the data only with indices.
The trade-off here seems to be to design a WATO UI which looks nice and logical, which at the same time produces a well-designed data structure …
=> Thanks, Andreas!
Hi, is there any drawback on using the Transfrom class? If not, any thoughts on using this by default?
The Transform class is meant to be used whenever your ruleset definition changes. Otherwise the user would have to enter all rules again with the new definition. I do not see a drawback here.
Ok… admittedly, this took me a while to look through… 
Let’s see if I got this right - and perhaps this can help others, too:
Instead of hard-wiring the data structures in rules.mk to WATO pages, there can be a layer between both by using the Transform class.
This class translates between the underlying data and their WATO representation.
forth = function for the representation in the frontendback = function to store in the backend.WATO --- back --> rules.mk
<-- forth --
I fiddled around with the rule “Citrix server load” which uses Transform and changed the forth and back lamdas as follows:
What happens now?
forth lambda represents it in WATO as the tuple (1,11).
back lambda stores a tuple of (2,22) in rules.mk.
Useless example, but the static values made it clear to my eyes
The (original) use case in the citrix rule is to let the user enter a number between 0 and 100 but store it as a float between 0 and 1 (back lambda). forth does the conversion in the opposite way.
As a conclusion, the abstract use case for Transform is to store the data in some other way than the WATO page produces it.
I really like this concept because it finally answers the question why robotmk bakery rules always look like an accident:
So, having a Transform “forth” function which can read an older rule format can reduce the risk of existing rules becoming unreadable when the WATO page changes.
In the case of Robotmk where the WATO page changes again and again, it is perhaps useful to always store the current version number within the rule. After an update, the forth function could then explicitly support migrations from an older major version to the current one.
I am leaving this open for discussion!
Best regards,
Simon
Thanks for the example. If I understand this correctly, when I use the Tranfrom I also need a fourth / back function. Or does the transform have a use on its own?
If you do not specify a function for forth or back, the Transform class simply passes the value through:
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
