Thank you for the example; I was able to get that command working without any hiccups. However, correct me if I am wrong, but the output (at least considering the format NwCheckpointProcess) is being post-processed somewhere internally before passing it into the XML parser, as the NwCheckpointProcess at least print the events in key-value pair format, whereas the XML parser expects basic comma-separated format without the keys. As a result, a NwCheckpointProcess output with, say, 20 key-value pairs might end up into an XML message definition with 50 fields, where 30 of those fields are simply passed into temporary/transient variables, which do not get mapped into nwdb, as the values do not exists in the fetched event.
So to me it seems that if we have a NwCheckpointProcess output of
key_1=value_1,key_2=value_2,key_3=value_3,...,key_n=value_n
it will get internally mapped to the following format
value_1,value_2,value_3,...,value_m
where n is most probably smaller than m, thus leaving empty values in the latter format.
Then again I might be wrong and the underlying format is the latter all along, but NwCheckpointProcess simply prints things out in the former format. I am still interested in any listing (e.g. a file where the mapping between the two formats is defined, if that even is reality) that would correspond to the latter format, i.e. what is the list of all keys and what is their ordering in the latter format. From the XML parser alone this is really difficult if not impossible to see, since no message definition is using m keys, and all non-used keys/values are handled with variables such as "fld80", thus masking out what the field would contain were it not empty.
