Data dictionaries (dicts) are meant to ease with translating codes, symbols, IDs and other dictionary-like information between systems.
For instance, in ISO 4217 Swiss franc has a code of CHF but its numerical symbol is 756. Let’s now imagine that one system connecting to Zato sends data using the former while the recipient of such messages uses the latter.
Data dicts allow Zato to translate codes between the two without manual coding, i.e. the web admin’s features discussed below are used to define the mapping and services uses the API to actually translate incoming data.
A translation is always performed between elements generically dubbed System1, Key1 and Value1 into System2 and Key2 and its result is a Value2.
Note that the names of systems and keys may contain only letters, digits and underscores.
A dictionary entry needs to be created for each triple of System, Key and Value.
A translation is created between the triples of System, Key and Value.
A form is provided to test out how a service translates values - this uses exactly the same API a service uses and it’s a great way to find out why a translation may misbehave.
Translations can be exported into a format that can be later imported into a cluster. Not that importing an export wipes out any previously declared translations.
An export is a bzip2-encoded JSON file which can be update manually but to import it onto environment it needs to be bzip2-compressed again.
Import is an either-or operation performed as an atomic Redis transaction. Either all translations are imported or none is.