Unfortunately, this is a more general problem with any transport protocol and a data protocol handler that overwrites the request body. The original request body is lost almost immediately due to the data protocol filter on the Listen step itself. What gets saved to the 'lisa.vse.request' and 'LASTRESPONSE' properties is the VSE request *after* data protocol handlers have been run.
The best option is if the original request object was preserved intact, along with all its meta-data, attributes, etc. You can do this in 9.1, but it requires some surgery on your VSM. You have to separate your 'Listen' step from its DPH filters, moving them to a new step where you can create a copy of the request object before the DPHs are run. Then you need to insert a step before your 'Live Invocation' step to "revert" the 'lisa.vse.request' property to the copy of the original you made.
I tried this out and it works, but you have to be careful with step connections. Here's what my VSM looks like post-surgery:
I added a script step after the 'Listen' step, and *moved* all of the 'Listen' step's filters to the new step. You can click and drag filters to a new step to copy them, and then you have to delete the originals from their original step. I also had to make sure the 'If being efficient' assertion on the 'Listen' step went to this new step, and I copied that assertion to the new step as well.
Here are the contents of this first script step:
// get the request before any DPH is run
request1 = testExec.getStateObject("lisa.vse.request");
// create a new request and copy the original data over
request2 = new com.itko.lisa.vse.stateful.model.Request();
// there's no convenient copy constructor, so this has to be
// done piece by piece
request2.setOperation(request1.getOperation());
request2.setMetaData(request1.getMetaData());
request2.setArguments(request1.getArguments());
request2.setAttributes(request1.getAttributes());
// how to copy the body depends on whether it's binary or not
if (request1.isBinary()) {
request2.setBody(request1.getBodyAsByteArray());
request2.setBinary(true);
} else {
request2.setBody(request1.getBodyAsString());
request2.setBinary(false);
}
// save the request copy to a new testExec property
testExec.setStateObject("lisa.vse.request.backup", request2);
Before the 'Live Invocation' step I inserted another script step. I didn't have to mess with connections here; the way it arranged itself by default is good enough. Here are the contents of this second script step:
// get the original request
request2 = testExec.getStateObject("lisa.vse.request.backup");
// revert the testExec's request object to the old one.
testExec.setStateObject("lisa.vse.request", request2);
I wish I had a better answer but I this is the best I can come up with for now. We definitely need to take a look at this scenario for the next release and see if we can make it "just work". I'm seeing this issue pop up a lot now that we have an IBM MQ protocol that supports live invocation and lots of IBM MQ shops also dealing with Copybook.