It should be possible, but I do not believe it solves all of your issues. Let's not worry about the response until you get the request payload correct.
Assume you have the following input request (# & | already replaced)
#005020|XYZ_COMM|SPP_CO_STORE||Anotherfake (Pty) Ltd 1990010100 74 900101 Plot 12345 Phase 0 Wonderland ARandomtown BW P O Box 12345 ARandomtown BW 00000000 MadeUp False Surnames 0123454321 19900101Fake Surname 0101010101 19900101
In the Listen Step --> Filters,
Add a Scriptable DPH (it is already in your code). Remove the "\\x02" and replace it with "". Replace "\\x07" with "|". Technically, we don't need to deal with the first byte (i.e., x02)
%beanshell%
String theBody = lisa_vse_request.getBodyAsString();
// Change # back to x02
// completely remove the first delimiter, it is not needed
theBody=theBody.replaceAll("#","").replaceAll("\\x07","|");
lisa_vse_request.setBody(theBody);
Add a second DPH as a Delimited Text Data Protocol where the delimiter is the "|" symbol.
These two DPHs will parse a lisa_vse_request object having arguments val1 thru val5.
Request {id=0, operation="POST /TCP", arguments=val1=005020&val2=XYZ_COMM&val3=SPP_CO_STORE&val4=&val5=Anotherfake (Pty) Ltd 1990010100 74 900101 Plot 12345 Phase 0 Wonderland ARandomtown BW P O Box 12345 ARandomtown BW 00000000 MadeUp False Surnames 0123454321 19900101Fake Surname 0101010101 19900101 , attributes=HTTP-Segment-Attr-0=TCP&delimiter=|&recorded_raw_request=005020|XYZ_COMM|SPP_CO_STORE||Anotherfake (Pty) Ltd 1990010100 74 900101 Plot 12345 Phase 0 Wonderland ARandomtown BW P O Box 12345 ARandomtown BW 00000000 MadeUp False Surnames 0123454321 19900101Fake Surname 0101010101 19900101 &recorded_xml_request=<payload delimiter="|">
<val1>005020</val1>
<val2>XYZ_COMM</val2>
<val3>SPP_CO_STORE</val3>
<val4></val4>
<val5>Anotherfake (Pty) Ltd 1990010100 74 900101 Plot 12345 Phase 0 Wonderland ARandomtown BW P O Box 12345 ARandomtown BW 00000000 MadeUp False Surnames 0123454321 19900101Fake Surname 0101010101 19900101 </val5>
</payload>&nameValueTokenDelimiter=&nameValueDelimiter=&listOfValuesDelimiter=|&pattern=&fieldNamesPath=, metaData=HTTP-Method=POST&HTTP-URI=/TCP&HTTP-Version=1.1&Accept-Encoding=gzip,deflate&Content-Type=application/text&frms_source=FFQ&frms_appid=FFQAPP&frms_tid=abc123&client_secret=2549110ff1434f4dBA8D4FEC5B3C51AA&client_id=ad453309a88c4eeeb2d2cfacf206180e&frms_region=TSJ1&Content-Length=883&Host=localhost:9021&Connection=Keep-Alive&User-Agent=Apache-HttpClient/4.1.1 (java 1.5)&lisa.vse.request.client.id=127.0.0.1:52157, matchTolerance=Exact, binary=false, body=(non-binary)[0 bytes] <null>}
The issue lies in VAL5. There are no "|" delimiters but there appears to be many different fields.
My assumption is that the VSM also needs to parse these values.
Perhaps, an RDM DPH moves VAL5 to the Request Body. (The other arguments are not affected by this)
Then, follow the RDM with a DPH to parse out the remaining part of the payload.
Perhaps, a Copybook DPH could parse the entire payload or maybe you need some other code. There is not enough definition for us to be precise here.
The code would parse the content of VAL5 (which was moved to the request body by the RDM) into meaningful arguments holding values such as:
Val6 = Anotherfake (Pty) Ltd
Val7 = 1990010100
Val8 = 74
Val9 = 900101
Val10 = Plot 12345
Val11 = Phase 0
Val12 = Wonderland
Val13 = ARandomtown
etc., etc., etc.
Since we do not know the precise makeup of the incoming data payload, we cannot be specific about how this content needs to be parsed. This would be custom based on the variation that the consumer application can send to the service.