To ensure consistency of messages, IBM WebSphere InterChange Server Express has developed a message format. This section describes that format, including:
The format for each message is:
MessageNum Message
The message number (MessageNum) and the message itself (Message) must be on different lines, with a carriage return at the end of each line.
For example, a map's messages might include a message identified as number 23, whose text includes two placeholder variables, marked as {1} and {2}, as shown in Figure 119.
23 Customer ID {1} could not be changed: {2}
When the map calls a method that displays a particular message, it passes to the method the message's identifying number and potentially additional parameters. The method uses the identifying number to locate the correct message in the message file, and it inserts the values of the additional parameters into the message text's placeholder variables.
It is not necessary to write separate messages for each possible situation. Instead, use parameters to represent values that change at runtime. The use of parameters allows each message to serve multiple situations and helps to keep the message file small.
A parameter always appears as a number surrounded by curly braces: {number}. For each parameter you want to add to the message, insert the number within curly braces into the text of the message, as follows:
message text {number} more message text.
For example, consider message 23 in Figure 119 again. When the map wants to display or log this message, it passes to the appropriate method the identifying number of the message (23) and two additional parameters:
The method locates the correct message, substitutes the parameter values for the message's placeholders, and displays or logs the following message:
Customer ID 6701 could not be changed: greater than maximum length
Because the message text takes the description of the missing entry and its ID as parameters, rather than including them as hardcoded strings, you can use the same message for any pair of customer ID and explanatory text.
Precede each comment line in a message file with a pound sign (#). For example, a comment might look like this:
# Message file for the Address business object map.
It is good practice to start the file with a series of comment lines to form a short header. Include in the header data the name of the map and such information as the file creator and file creation date.