Summary:
The infoType
structure is used as a generic container for name/value pairs, and for the text messages that may require localization.
Type specification:
Name |
Min/Max |
Type |
Description |
|
|
|
The original message in the official language of the developer. The text may contain references to parameters in the following format: %param_name%. The parameter name always begins and ends with a percent sign. The values of the parameters are not included in this element but supplied in the |
|
|
|
If present, indicates that the message contains words in a natural language and, as such, may require a translation to the language of the user. |
|
|
The values of the parameters specified in the The value is linked to the parameter using the The parameter may also be used as a simple name/value container. |
|
|
|
|
Parameter name. |
Example:
<info>
<message>T3BlcmF0b3IgJW9wZXJhdG9yJSBhdCAlZWlkJSBzdGFydGVk</message>
<name></name>
<translate/>
<parameter>
<message>ODQ5YzliZTktNWZiYi00ZTdkLWIxMDAtZjg0MWY4NmMxNTBl</message>
<name>eid</name>
</parameter>
<parameter>
<message>dnphX2NvbmY=</message>
<name>operator</name>
</parameter>
</info>
In order to decode the message above, you first have to decode the base64-encoded values that the message contains. The following is the same message with the values decoded to plain text.
<info>
<message>Operator %operator% at %eid% started</message>
<name></name>
<translate/>
<parameter>
<message>849c9be9-5fbb-4e7d-b100-f841f86c150e</message>
<name>eid</name>
</parameter>
<parameter>
<message>vzl_conf</message>
<name>operator</name>
</parameter>
</info>
To process this message, you have to take the following steps:
translate
element is present in the packet. In our case, the element is present (which makes sense because the message contains words in a natural language, English in our example), so depending on the target locale, you might want to translate the text portion of it.%
). If there are parameters in the packet, get their values by matching a parameter name to the corresponding name in one of the parameter
elements that follow the message
element. In the packet listed above, the first parameter is %operator%
and its name (operator
) is contained in the second (from the top) parameter
element. The value of the parameter is contained in the parameter/message
element and is vzl_conf
. The next parameter (%eid%)
is processed in the same exact manner. If you substitute the parameter references in the original message with their values now, the message will read as follows:Operator vzl_conf at 849c9be9-5fbb-4e7d-b100-f841f86c150e started.
So, the original message that we received essentially means that the vzl_conf
Agent operator has been started on the server with the Server ID 849c9be9-5fbb-4e7d-b100-f841f86c150e
.
Sometimes the structure is used as a simple generic container for the name/value pairs. For example, the following XML fragment contains information about a server from a backup archive. As you can see, the message
element in the beginning of the structure does not contain any value, which means that the packet does not contain any message. The underlying parameters simply describe the different properties of a server such as hostname, IP address, operating system, etc.
<ns2:info>
<ns2:message></ns2:message>
<ns2:name></ns2:name>
<ns2:translate/>
<ns2:parameter>
<ns2:message>SG9zdC0xMDY=</ns2:message>
<ns2:name>hostname</ns2:name>
<ns2:translate/>
</ns2:parameter>
<ns2:parameter>
<ns2:message>MTAuMTMwLjEuNg==</ns2:message>
<ns2:name>ip</ns2:name>
<ns2:translate/>
</ns2:parameter>
<ns2:parameter>
<ns2:message>VGVzdC1WRTY=</ns2:message>
<ns2:name>name</ns2:name>
<ns2:translate/>
</ns2:parameter>
<ns2:parameter>
<ns2:message></ns2:message>
<ns2:name>os</ns2:name>
<ns2:parameter>
<ns2:message>TGludXg=</ns2:message>
<ns2:name>platform</ns2:name>
</ns2:parameter>
</ns2:parameter>
<ns2:parameter>
<ns2:message>ODllMjc5NjAtOTdiOC00NjFmLTkwMmYtNTU3YjRiMTY3ODRi</ns2:message>
<ns2:name>parent_eid</ns2:name>
<ns2:translate/>
</ns2:parameter>
</ns2:info>