ARaja,
Block mapping is primarily intended for responses that contain repeating and/or nested multiline structures. If your response does not have any repeating structures in it, or are tables with rows and columns, then you should probably be focusing on the other technologies (pattern and table, respectively).
Here's a simple example of a response that block mapping is well-suited for:
Port Statistics for Switch: BERLINER-19
Port Ethernet1 Current state: UP
Input packets: 25 Output packets: 11536
Input bytes: 243396 Output bytes: 4994932
Last restart: 9/2/2008 13:02:23
Hardware address: 3A:44:70:1F:2B:C1
Port Ethernet2 Current state: DOWN
Input packets: 0 Output packets: 0
Input bytes: 0 Output bytes: 0
Last restart: 8/1/2008 00:02:25
Hardware address: 3A:44:70:1F:2B:C2 *
Port Ethernet3 Current state: UP
Input packets: 239393 Output packets: 393939
Input bytes: 34325664 Output bytes: 23349992
Last restart: 9/2/2008 13:02:24
Hardware address: 3A:44:70:1F:2B:C3
Port FastEthernet1 Current state: UP
Input packets: 593295 Output packets: 249944
Input bytes: 94595495 Output bytes: 12392925
Last restart: 9/2/2008 13:02:31
Duplex: FULL
Hardware address: 3A:44:70:1F:2B:D0
* These ports are currently unavailable
As you can see, this response contains a repeating structure, with several similar lines describing each port on a device. The structures are not all exactly identical, but this is a good candidate for block mapping.
Here is how I think about block mapping this thing:
1) What data do you want to get out of this response? In this response, we want to get the stats for each port. We probably want queries that get, for example, "input packets by port" where the port name is an argument to the query. We might also want to extract the switch name from the top line.
2) Are the structures identical? Well, not exactly, but pretty close. There is an extra line in the middle of the FastEthernet port information (about "duplex"). And Ethernet 2 has an extra "*" after the MAC address.
3) The overall structure looks like this. There is a banner at the top. Then there is a repeating structure, each containing several lines. Then there is a footer at the bottom. So we will end up with 3 blocks in the map. The second block will be a repeating block.
4) To build the map, we create a new response map file. We populate the sample provided. (It is even better if you can populate multiple representative samples, so that they can all be checked against your map.) Click on the "Block" link on the General page. On the Block page, add one block under "root" for the banner, port, and footer. Then work on each block. Start by copying the sample text for one of those blocks into the "Block contents" area. Then you need to work on the various properties for the block, its lines and its tokens. Most notable in this example is that the "port" block needs to be marked "repeating" so that we know that there could be multiple instance of this block appearing in the response.
5) Using the Response Map Editing perspective, you should see the Response, Queries, and Step Issues views that will help a lot as you debug your response map. When there are no step issues and the Queries view contains all of the information you want to be able to extract, you'll be done.
The trickiest part of block mapping is in dealing with variations in the structures. You may need to convert a token or sequence of tokens into a "wildcard" token. You may need to make tokens and/or lines optional. To deal with different variations, you sometimes want to create two different blocks that could either appear, or you can add tokens to the same block to deal with either variation and make these tokens optional, so that it can work either way.
If you download the example here, hopefully that will help you see what can be done. It only took about 3 minutes to complete the map for this example. (Think about how long it would take to write a full parser for this response, including the APIs for querying data by port!)
