TREP stripping AttribInfo from UPDATE_RESP messages using custom model

Options
david.heggie
david.heggie Newcomer
in RFA

We have noticed an issue with a provider we have written with the JAVA RFA API 7.2.1.
We are using a custom domain model (128) and when we send UPDATE_RESP messages through our TREP the AttribInfo is being stripped off. REFRESH_RESP messages traverse the TREP without modification.

Successful REFRESH_RESP

Provider sends

MESSAGE
	Msg Type: MsgType.REFRESH_RESP
	Msg Model Type: Unknown Msg Model Type: 128
	Indication Flags: REFRESH_COMPLETE | CLEAR_CACHE
	Hint Flags: HAS_ATTRIB_INFO | HAS_ITEM_GROUP | HAS_QOS | HAS_RESP_TYPE_NUM | HAS_STATE
	State: OPEN, OK, NONE,  "OK"
	Qos: (RT, TbT)
	Group: 0001
	RespTypeNum: 0(REFRESH_SOLICITED)
	AttribInfo
		ServiceId: 417
		Name: EXCH_STATUS
		NameType: 1
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 20002: 01

Client receives

MESSAGE
	Msg Type: MsgType.REFRESH_RESP
	Msg Model Type: Unknown Msg Model Type: 128
	Indication Flags: REFRESH_COMPLETE | CLEAR_CACHE
	Hint Flags: HAS_ATTRIB_INFO | HAS_ITEM_GROUP | HAS_QOS | HAS_RESP_TYPE_NUM | HAS_STATE
	State: OPEN, OK, NONE,  "OK"
	Qos: (RT, TbT)
	Group: 0001
	RespTypeNum: 0(REFRESH_SOLICITED)
	AttribInfo
		ServiceId: 417
		Name: EXCH_STATUS
		NameType: 1
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 20002: 01

Unsuccessful UPDATE_RESP

Provider sends

MESSAGE
        Msg Type: MsgType.UPDATE_RESP
        Msg Model Type: Unknown Msg Model Type: 128
        Indication Flags:
        Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM
        RespTypeNum: 0  AttribInfo
                ServiceId: 1
                Name: EXCH_STATUS
                NameType: 1
        Payload: 11 bytes
                FIELD_LIST
                        FIELD_ENTRY 20002: 02

Client receives

MESSAGE
	Msg Type: MsgType.UPDATE_RESP
	Msg Model Type: Unknown Msg Model Type: 128
	Indication Flags: 
	Hint Flags: HAS_RESP_TYPE_NUM
	RespTypeNum: 0	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 20002: 02

As you can see the AttribInfo has disappeared.

Does anyone have an idea as to what is going on?

Tagged:

Best Answer

  • Lars-at-Addicticks
    Lars-at-Addicticks Expert
    Answer ✓

    If the subscriber hasn't requested attrib-info-in-updates when he made the subscription, then AttribInfo will be left out from all UPDATE messages. So, this is by design. TREP will remove it because the subscriber didn't ask for it.

    A subscriber shouldn't really have a need for the information in AttribInfo on messages of type UPDATE, only on messages of type REFRESH, hence the feature exists to include it or not, and the default is that the subscriber must explicitly ask for it if he wants it.

Answers

  • umer.nalla
    umer.nalla LSEG

    Hi @david.heggie,

    You can set OMMMsg.Indication.ATTRIB_INFO_IN_UPDATES in your Consumer ReqMsg if you really want AttribInfo in your updates, but the generally this is avoided to minimise TREP bandwidth etc.

    See section 6.2.5 Indication Flags of the RFA Java Developers guide for more detail.

  • david.heggie
    david.heggie Newcomer

    Perfect, thanks for the help.

Categories