Internationalization
The NAS 3.50 supports the internationalized alarms published by probes supporting the new NIS Configuration-Item bindings. The incoming alarm PDS is expanded with i18n_token and i18n_data elements. The NAS will, if internationalization is enabled, store the i18n_token and the base64 encoded PDS byte-stream i18n_data in the database. The get_alarm command-interface and the event-publisher will decode the base64 PDS into a valid PDS called i18n_data. ***The i18n tokens cannot be used as auto-operator filters, and is purely meant for the UI’s.***
Summary:
Nas is NOT INTERNATIONALIZED yet many probes are. And there are specific fields probes want to send through to the UMP console without having Nas contaminate them. Thus, these special fields are base64 encoded as they are processed coming into Nas. These strings are stored in the DB in this form. And, just as they are about to be sent out of the Nas on “cooked” alarm messages, they are decoded .
Details:
The probes want to send some internationalized character set information through.The message arrives looking like this…
Nas knows that UMP console would like to use/see specific fields so they must be preserved…
/* Only decode i18n data if told to */
if (gConfig->i18nActive) {
pdsGet_CPCH (udata, "token",i18n_token);
pdsGet_CPDS (udata, "values", &i18n_pds);
if (i18n_pds) {
i18n_dsize = pdsDataSize(i18n_pds);
if (i18n_dsize) {
i18n_data = Base64Encode(pdsData(i18n_pds),(constsize_t)i18n_dsize);
i18n_dsize = strlen(i18n_data);
}
pdsDelete(i18n_pds); i18n_pds=NULL;
}
}
Now that our selected fields are preserved (i.e. flattened out in base64), it is guaranteed that we can push them around in the Nas without damaging them. Internal to the Nas are DBs, and all kinds of non-internationalized sections of code. This would include the pre-processor scripts, regexp for pattern matching on filters/profiles, and lots more.
Under specific conditions on the alarm like new, close, update (every 100th alarm) a “cooked” message will be sent out by the Nas of the form alarm_new, alarm_close, alarm_update, respectively. Right before these messages are sent, the base64 message will be decoded and sent to the spooler. Here is an example of an alarm_new message where the i18n_* fields were expanded back into a PDS structure.
Now, when the messages arrives at the UMP alarm console, it will lookup in the message catalog based upon the i18n_token name and substitute the $xxxxx values contained in the i18n_data section.
- Nas is not internationalized so the “Activate support for internationalization” is a bit misleading. It is only for a select set of fields required by the downstream GUI.
- Pre-processing (using LUA or alarm_enrichment) can modify the content of the message. The former, LUA cannot affect these “select” fields. It is only allowed to modify a different set of fields.Alarm_enrichment is wide open, be careful not to modify the ‘token’ or ‘values’.