Data Contribution is a means of sending your pricing data to Refinitiv, from where it can be fanned out globally. Leading market participants, such as banks and brokers, use Refinitiv to publish and distribute their information to the community of financial professionals.

The Contributed Data is sent directly from the client to Refinitiv and not via a financial exchange.

From a programming perspective, the functionality used for Contributing data is known as Posting.

There are two forms of Posting supported by the ADS:

• On-Stream Post: Before sending an on-stream post, the client must first open (request) a stream for an existing data item. After opening the stream, the client application can then send a post for the data item.
•  Off-Stream Post: In an off-stream post, the client application can send a post for an item via an open Login stream, regardless of whether a data item stream first exists.

Prerequisite

• The name of the Service (as defined by your Internal Market Data team) that you will be Posting to
• The name of RICs (as agreed with your Internal Market Data team) that you will be Posting to
• For both types of Post interactions, we need to have already created a Websocket connection to the ADS and successfully Logged in.

Table of Contents

• On-Stream Posting

• Off-Stream Posting

On-Stream Posting

For an On-Stream Post we need to first send a Request message for the existing Item we want to Post to. The Request message would be the same as standard Data request message as discussed in the earlier. However, it is unlikely the service you are Posting to would be the default JSON service on the ADS (e.g. ELEKTRON_DD) – rather it would be the name of a cache service or Contribution service - setup by your internal Market Data team. Therefore, the Request message will almost certainly require a Service to be specified:

Here we are requesting the existing data item ‘UMER.TST’ from the ‘NIPROV’ service – note the stream ID of 2.

The exact service name and RIC naming will be determined by your internal Market Data team – who should be able to advise you.

If the requested RIC exists in the cache we should receive a Refresh Response:

Now that we have an open stream for the data item we can then use the stream ID of 2 to push our data to the cache:

A few things to note:

• We set the ‘Ack’ attribute to true – this tells the ADS to send us an acknowledgement confirming receipt of our Post
• We do not specify a Service name or item name, just the stream ID of 2, so the Post will be targeted at the previously opened item of ‘UMER.TST’ from ‘NIPROV’
• The internal payload message type is ‘Update’ as we are updating two fields of an existing item
• The internal payload message has an ID of 0 – since it does not have its own event stream.
• The outer message type is ‘Post’ to indicate that it is actually a Post message (containing an Update payload)
• The unique PostID value of 1 - this is the AckID we will receive back in any Ack message from the server (see below)

Assuming the Post message content is valid, we should receive an ‘Ack’ message back from the ADS which should look something like:

Note the AckID of 1 which corresponds to the PostID of 1 we specified in the Post message we just sent to the server. We can use this value to identify which Post the Ack relates to. Therefore, we should use unique PostIds for each Post message we send.

On-Stream posting makes sense when we want to consume the existing data items we are posting to. If however, we are only interested in pushing values to the cache without consuming it – we can use Off-Stream posting.

Off-Stream Posting

For an Off-Stream Post we don’t need to have previously opened a stream for the item we want to post to - indeed the item may not even exist and we want to use the Post to create the item. We do need an open Login stream and therefore need to be successfully logged into the server.

Assuming you have already created your Websocket and performed a successful Login – we can send an Off-Stream Post using the Login Stream ID of 1.

Notice the following:

• We must specify the Service name and RIC code of item that we are posting the data to - 'NIPROV' and 'FRED.TST'
• The internal Refresh message payload we use an ID of 0 as we do not have an open stream for the item.
• We set the ‘Ack’ attribute to true – this tells the ADS to send us an acknowledgement confirming receipt of our Post

Post a Refresh or an Update?

In the examples above I have posted a Refresh and an Update – purely for demonstration purposes. However, your choice of which to use will depend on your requirements:

• If we wanted to create a new item in the cache service we would Post a Refresh payload
• To add or remove the actual Fields contained within an item we would Post a Refresh with the revised Field list
• If we had experienced some temporary data issue which is now resolved and we want to force consumers to overwrite any locally cached fields, we should send a Refresh. This ensures any existing consumers of our data get a clean set of values for all the fields in the item
• To change values for one or more fields of an existing item we can Post an Update message

If we try to post an Update to a non-existent item we will get an ‘Ack’ response but with a NakCode e.g. if we try to post to a non-existent item ‘DAVE.TST’ we get:

There are other situations where you can get a NakCode e.g. permission issues, stream not open – a list of the NakCode attribute can be found in the WebSocket API Try it Now! Documentation - some of which I have listed below:

• AccessDenied: The user is not permissioned to post on the item or service.

• DeniedBySrc: The source being posted to has denied accepting this post message.

• GatewayDown: A gateway device for handling posted or contributed information is down or unavailable.

• InvalidContent: The content of the post message is invalid (it does not match the expected formatting) and cannot be posted.

• None: No Nak Code.

• NoResources: Some component along the path of the post message does not have appropriate resources available to continue processing the post.

• NoResponse: There is no response from the source being posted to. This may mean that the source is unavailable or that there is a delay in processing the posted information.

• NotOpen: The item being posted to does not have an available stream.

• SourceDown: The source being posted to is down or unavailable.

• SourceUnknown: The source being posted to is unknown and unreachable.

• SymbolUnknown: The system does not recognize the item information provided with the post message. This may be an invalid item.

Click Closing Summary to continue