User Formats with String Messages

How many of you saw our post about the addition of User Formats to the message editor, MQEdit, and thought, “That doesn’t apply to me, all my messages are string messages (MQSTR)”?

Well, I have news for you. Not only does it apply to you, but it might be very useful!

Using string messages is a very common practice with MQ Applications. After all it keeps things nice and simple, MQ does all the work for you when messages need to be data converted from one platform to the other, and you don’t need to build data conversion exits that need to know the shape of your message formats.

However, it is rare that such a string message is completely free-form. There will be some kind of structure to the message. Sometimes this structure will be XML or EDIFACT (which are also supported by MQEdit) and sometimes this structure will be a set of fixed fields.

There are many advantages of using user formats when viewing or editing even your string messages.

  • You can see each field displayed with a label to indicate what it is.
  • It is easier to edit one field in the message without inadvertently changing another.
  • In the list of messages, you can choose which field(s) are shown rather than simply seeing the first n bytes of the string message. (This is done with the summary option)
  • You can have different detailed views of your message, by indicating that certain fields are for low, medium and high detail views. This can be very handy if there are a lot of fields in the message that you don’t often need to look at, and you want to de-clutter your view when looking at the message.
  • It is easier to see when messages are badly formed (see below).

Example of viewing a malformed message

As an example, imagine your application expects that the first 20 characters are the customer name; next there will be three 30 character chunks with the address lines 1, 2 and 3; and so on.

You can define such a fixed string message format to MQEdit as well, just like this:

struct CUSTADDR; Customer Address
{
  char Name[20];
  char Address1[30];
  char Address2[30];
  char Address3[30];
}

Now since your format is MQSTR, and probably all your MQSTR messages are different shapes, you can’t use the MQMD.Format field to tell MQEdit the shape of your messages, so instead, you tie the user format structure you just created, to your message, by tying it to the queue name like this:

queue APP1.CUSTOMER.ADDRESS
{
  struct CUSTADDR;
}

Then, instead of you having to remember what all the offsets inside the message are, when you are looking at what the receiving application contends is a badly formed message, you can instead have MQEdit display it to you making it easy to see the problem. Compare the two screen shots from MQEdit below. Which do you think is easier to use to spot what’s wrong with the message?

MQEdit String Message Unformatted

MQEdit showing a String Message Unformatted

MQEdit String Message Formatted

MQEdit showing a String Message Formatted

This view makes it really easy to see that the message is badly formed because there is a missing space and so the first address line is not starting at the correct offset.


If this feature interests you and you’d like to try it out for yourself, you can download MQEdit from the MQGem website and if you don’t currently have a licence, you may email support@mqgem.com to request a trial licence. Let us know what you think once you’ve had play with it.

Advertisements

The team at MQGem would love to hear what you think. Leave your comments here.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s