We have to Virtualize flat file request to xml response in IBM MQ. What is the data protocol needs to used and how the arguments are identified in VSI. Please help on this.
What exactly do you mean by "flat file"? Do you have an example?
If you're talking about a database flat file format, then you could probably use the Delimited Text Data Protocol.
It is a mainframe FLAT file. I have attached sample FLAT file for reference.
Is there some sort of specification for what the fields in this file mean and what their lengths are? Does this example have every field filled in, or are some of them left blank? What should the XML response for that request look like? How does your application parse it?
You might be able to use the Delimited Text data protocol in some way, but it's tough to say without any context for what that data actually means.
Thanks for the suggestion Kevin. In our case we have different length for each fields separated with whitespace filler. So we have used Regex matching field = (\b[^\s]+\b) in Delimited Text data protocol and it worked for our case. Please let us know is there any other best approach/solution for this case ?
In the absence of some kind of specification that can assign semantic meaning to those fields, then that regex can do in a pinch. But your VS is going to be fragile.
Bear in mind that the arguments created by the Delimited Text DPH are just an ordered list, with the name of each field simply generated from the index under which it appears in the list. This can present some problems if you're just using white space to separate fields.
If one field is left blank then it won't appear in the list. The Delimited Text doesn't know it's supposed to be there; it just looks like an extra long space before the next field. The index of all subsequent fields will be off by one, and the list will be one field shorter.
Even worse, if request A has one field but is missing another, and request B has the second field but is missing the first, then their argument lists will be the same size but some of their fields will be in different places in the list. Their signatures are indistinguishable to VSE without some additional work.
If fields are never left blank then you don't have a problem.
If fields *can* be left blank, but you have a large enough transaction list, then you might be okay with the first issue. The second issue is much harder. You will need either a transaction list that includes the *exact* transactions that the VS will receive at playback time, or you will need some more sophisticated matching or a custom DPH that actually knows what the fields are and how long each one is.
Thanks Kevin. We will follow your suggestions.