About the Message Editor Window


Use the Message Editor window to configure the request and response messages used in an Advanced Data DMF. Request-Response message pairs are contained in Command controls, and you can open this window with the View/Edit buttons on the client and server sides of a control. The message that is ultimately transmitted can be a combination of a variety of elements: explicit static content that you can compose on the editing sub-tabs or import with a Test Data File, static filler content that you can use to expand the size of a message payload, and dynamic content that is provisioned from values received in another message or from values calculated by the test. You can customize the messages from a default DMF, an imported message trace, a message flow built with the Protocol Wizard, or start with a new control and a blank slate.

NOTE: You may sort the information in the Auto-fill Fields pane based on the Offset Column.

NOTE: When using the Fireball DMFs (fb_http and fb_https) and selecting Automatic Padding with Zs, the filler value will be filled with Zero (0x00) not the character "Z".

 

NOTE: A message displays if the Padded Message Size is less than or equal to the user-defined message data, as this results in no padding.

For example, the following shows the same message viewed in Auto-Fill Viewer and CRLF Viewer.

Auto-generated Message/A 0d0aHeaderName: HeaderValue0d0aContentSize: 00d0a0d0a
Auto-Fill Viewer <CR><LF>0dHeaderName: HeaderValue<CR><LF>0dContentSize: 0<CR><LF>0d<CR><LF>0d

In the CRLF Viewer

HeaderName: HeaderValue<CR><LF>

ContentSize: 0<CR><LF>

<CR><LF>

IMPORTANT: When a message with the correct protocol is received and it does not match the expected response defined in the current Command control, the test will compare the message to all responses defined in any subsequent Command controls in the DMF. If it finds a response that is not verifiable (verification is disabled), the test assumes that the received message is a valid response for that Command control.

Message Content

 

The Message Editor gives you the ability to define any type of message from a simple packet with a specific number of bytes using one of the provided protocols to a message that defines the headers and payload for a custom protocol. You can include dynamic content that is unique for each message flow, packet, or MN, define any required binary encoding, and import files for use as payloads.

Static Content

You can explicitly define some or all of the message content on the Hex-Ascii, Text Editor amd MQTT Helper sub-tabs. These editing sub-tabs are normally used to define application-level control messages, as shown in the FTP example above, and to define packet headers for custom protocols. When you insert dynamic content in the message, it is inserted into this portion of the message. A maximum of 1500 bytes can be defined on these sub-tabs, and the available bytes remaining is displayed above the ASCII portion of the Hex-Ascii sub-tab. You can also import a text file to use for this portion of the message with the Browse button.

Use the Hex-Ascii tab to compose the message if the protocol is not text-based. The left column displays the row number, the center column displays the hex value of the bytes arranged by row and byte position, and the right column displays the ASCII translation. Values that cannot be represented by an ASCII character are shown with a square.

Use the Text Editor tab to compose the message in plain text. The text in the Text Editor is converted to hex, and you can still use the Hex-Ascii tab to insert bytes for any encoding that the protocol requires. The example to the right shows the hex message used above in the Text Editor.

If text can be used in the message without regard to the content, you can use the Automatic setting in the Filler Data pane to pad the message with "Z" characters. You can start the filler at a particular byte (Content Start) and define the total size of the final message, including any dynamic content inserted into the message and the literal portion of the message defined on the editing sub-tabs, with Content Size. The Auto-Fill Viewer sub-tab (see the Dynamic Content section below) displays the placeholder for the filler data positioned within the message content as specified.

With the Test Data File setting, you can select a data file that has been imported into your Test Library, and the file will be inserted into the message beginning at Content Start. Data files can be up to 500KB (512,000 bytes) and can contain text, graphic, or multimedia data. If there is any overlap between filler data and bytes defined on the editing tabs, the remaining bytes from the editing tabs are appended to the filler data.

When the message's total size is larger than the Segment Size defined for the DMF, the message will be sent using multiple packets. If you have defined header fields in the editing sub-tabs, this information will be included in every packet when you check Include All Data Before Content Start As Header In Every Segment.

 

Use the MQTT Helper tab to compose messages that are supported by the mqtt protocol. For mqtt protocol, the text and auto-fill tabs are not available. The message format is a combination of binary and ASCII.

 

Dynamic Content

You can use Auto-Fill Fields to insert values that are unique to the MN, the MN's data session, or the message flow into your message. Fields are also provided that enable you to capture a value from a received message — the session ID or the port to be used for a data connection, for example — and insert it into subsequent messages or use it to provision other settings in the test. Defined fields are listed in the Auto-Fill Fields pane and are also displayed, embedded within the message content, on the Auto-Fill Viewer sub-tab as shown in the example. Fields that insert content are shown in red and fields that capture content are shown in yellow.

You can use the Add and Remove buttons to manage the fields, and you can also add new fields by using the context menu. Right-click in one of the editing sub-tabs, select Add Auto-Fill, and a field is added at that position. If you select a series of characters in the Text Editor sub-tab first, the field will replace the selected characters.

The position of a field that inserts content is defined by its Offset. Fields that capture values from a message can be targeted by position using Offset or they can use a Search Pattern to find the target anywhere in the message. The Current Offset of your cursor is displayed near the tops of both editing sub-tabs, and it can aid you in confirming the exact placement of a field. If you add content to the editing sub-tabs after adding fields, any affected Offset values are automatically adjusted, keeping them in the same position relative to the surrounding content.

See Auto-Fill Fields for more information about the types of fields available and how you can use them in a test.