Hi,
I am trying to get the attached response map work but could not crack it. The error message does not necessarily help identifying the root cause. Would be of great help if someone can take a look and comment on what I am missing.
Thanks
Hi,
I am trying to get the attached response map work but could not crack it. The error message does not necessarily help identifying the root cause. Would be of great help if someone can take a look and comment on what I am missing.
Thanks
Wow! Super-complicated response. This is where you need ALL of your mapping skills!
If it were me, I'd be carving this one up into small blocks -- mostly one line at a time -- and creating a pattern for each. The exception might be for some of those repeating sections, where I might use a table map -- although that might depend on what you really need to extract.
I see that you've create a huge bunch of custom queries here as well. I'm assuming that these could adjust accordingly from data coming from the patterns.
The key, again, is that you don't really need a block map unless you have these multi-line repeating sections where you need to key off of certain data in one part to get other parts. In these examples, there aren't really repeating blocks. You just have a LOT of data to extract.
As Paul mentioned, one important decision to make is whether or not you want to extract ALL the data or just some of the data. This depends on whether or not you are trying to create the ONE response map that everyone will use and never have to touch again. The other option is to add individual pattern maps for each piece of information that you actually need, and update the response map when more is needed, this has the benefit that you don't do a bunch of work that needs maintaining when it isn't actually being used.
Thanks a lot for the suggestions.. this response map has evolved across three releases and the objective was to have me come up with the one response map that works for all. I would say that 80% of the extracted data will be used by one person or the other.The output has a top level block which has non repeating lines but has lot of optional text within each and also has the top-level key, there are multiple repeating blocks each of which has their own keys and there is one block which has nested blocks each with keys. From the look and feel it did appear that block map was the best to deal with nested o/p with keys. Sounds like I can do a mix of a) pattern+block - across multiple response maps b) pattern + table c) pattern + block within one RM. I did not find pattern map to be great when same line of o/p can have optional text - this could just be because I have not used pattern maps as much as I used the others. I could be missing something but I don't think b) is an option as there is no table style o/p. that leaves me with a) and c) - as long as I can tie the keys across the pattern and blocks - i will give it a shot at these options.
Also would it be fair to conclude that block maps alone may not handle such complex and varying o/p ?.
I believe block maps can be made to work. But as you get up to this level of complexity (not in any one response, but in the fact that there are so many variants of the response), you really have to be thinking a lot more about what is likely to create confusion in the block mapping process itself. As an earlier poster said, you will quickly have problems when you are using a lot of wildcard and/or optional tokens. As he said, you should, instead, try to use a container of alternative variants of blocks -- each of which has as little wildcard/optional stuff as possible.
I do recommend, however, that you spend a little more time with pattern maps. Once you get the hang of them, I think you'll find that they are a powerful weapon in your arsenal!
I haven't had time to try and create a working block map for you. However, taking a look at some of the blocks, I can offer the following advice:
Whenever a block has a number of optional lines in a row, that's a hint that perhaps you should create a number of different blocks with the various permutations that make sense. Optional lines are very expensive to handle, as are wildcards within a line. It also makes it much more difficult to figure out why a particular block isn't matching.
You should also ask yourself if you really need a block map. It seems that your possible responses vary greatly, otherwise you wouldn't have so many optional lines. If this is the case, and you just want to pick out a few statistics, then a pattern map might be easier to create and much faster to process.
No one has followed this question yet.