Hi - this leads on from this previous query:
In brief, we have an application team using an application coded with RFA6 which is unable to contribute via SSLInserts on RCC (Contributions Channel). They receive a postMsg NAK which complains about containerType RSSL_DT_OPAQUE.
In the previous query we were advised to approach the RTDS team and we have since had the following response back from them:
"Please see our developer's update for this query:
From the ads.dbg, there are several SIPC message dump,
Sipc message Received: Len: 128 HdrLen: 6 Flags: 0 ProtId: 0 FD: 32 Thu Aug 05 12:52:56 2021 MsgLen 128 Flags 0 Opcode 24 HdrLen 5 SSL Insert Request. srvcId: 2 ReqId: 215386792
ItemName: DE000BC0AVW4=BARL DataLen: 97
Data(97):
1c35 1d2e 4445 3030 3042 4330 4156 5734 .5..DE000BC0AVW4
3d42 4152 4c2e 4e61 451f 301e 3638 1f31 =BARL.NaE.0.68.1
3320 4465 6320 3230 3231 1e37 381f 4445 3 Dec 2021.78.DE
3030 3042 4330 4156 5734 1e32 3735 1f31 000BC0AVW4.275.1
3232 2e39 371e 3339 331f 3132 302e 3937 22.97.393.120.97
1e39 3638 1f42 4152 434c 4159 5353 501c .968.BARCLAYSSP.
00 .
The first byte is 0x1c and the last byte is 0x00, which is wrong, the last byte should be 0x1c. <FS> in hex is 0x1c.
When converting SSL insert to RSSL post message, we have to scan the payload to determine if Marketfeed (or not) as SSL inserts do not contain a container type.
To determine if Marketfeed (or not), we look at the first byte and last byte of the payload for the <FS> start and terminator (that’s it) and if <FS> is not in the first and last byte, we assume it’s not Marketfeed and set the container type on the RSSL post message to RSSL_DT_OPAQUE and of course we will not be convert to RWF.
As the last byte is not 0x1c, ADS assumes it is not Marketfeed and sends RSSL_DT_OPAQUE to TRCC which of course it rejects.
So it seems the consumer application is adding an extra byte onto the end of the Marketfeed which is causing this.
Remove the 0x00 and have a try again"
Do you have any advice for our application team about how to remove the 0x00?
