@Konrad

In the client-server architecture, a non-interactive provide acts as a client application.

Therefore, for testing purposes, you can modify an ETA interactive provider (com.refinitiv.eta.examples.provider) to receive the data published by a non-interactive provider.

1. Modify the ProviderDirectoryHandler.processRequest method to return CodecReturnCodes.SUCCESS when receiving unhandled source directory messages (refresh and status messages)

...
            default:
                error.text("Received unhandled Source Directory msg type: " + msg.msgClass());
                return CodecReturnCodes.SUCCESS;
        }
    }

2. Modify the ItemHandler.processRequest method to return CodecReturnCodes.SUCCESS when receiving unhandled item messages (refresh and status messages)

...  
          default:
                error.text("Received Unhandled Item Msg Class: " + MsgClasses.toString(msg.msgClass()));
                return CodecReturnCodes.SUCCESS;
        }

3. Then, run the modified interactive provider with the following options "-x -p 14003". The -x option is enabled XML tracing so you will see the retrieved message. The -p 14003 is the listening TCP port on the interactive provider. 14003 is the default TCP port used by non-interactive providers to connect to the server

4. Finally, run a non-interactive provider to connect to the modified interactive provider

On the interactive provider's console, you will see the retrieved messages in the XML format.

Read message: 
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<UPDATE domainType="MARKET_PRICE" streamId="-1" containerType="FIELD_LIST" flags="0x08 (HAS_MSG_KEY)" updateType="0" dataSize="14">
    <key flags="0x03 (HAS_SERVICE_ID|HAS_NAME)" serviceId="1" name="IBM.N"/>
    <dataBody>
        <fieldList flags="0x08 (HAS_STANDARD_DATA)">
            <fieldEntry fieldId="22" dataType="REAL" data="39.93"/>
            <fieldEntry fieldId="30" dataType="REAL" data="12.0"/>
        </fieldList>
    </dataBody>
</UPDATE>


Read message: 
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<UPDATE domainType="MARKET_PRICE" streamId="-1" containerType="FIELD_LIST" flags="0x08 (HAS_MSG_KEY)" updateType="0" dataSize="14">
    <key flags="0x03 (HAS_SERVICE_ID|HAS_NAME)" serviceId="1" name="IBM.N"/>
    <dataBody>
        <fieldList flags="0x08 (HAS_STANDARD_DATA)">
            <fieldEntry fieldId="22" dataType="REAL" data="39.94"/>
            <fieldEntry fieldId="30" dataType="REAL" data="13.0"/>
        </fieldList>
    </dataBody>
</UPDATE>

Hi @Konrad

A NIProvider by its very nature cannot connect directly to a Consumer - as it is a Non-Interactive Provider - i..e it determines which if any instruments it publishes - regardless of any downstream interest and therefore it connects to the RTDS Components

For the scenario you are described, you can use an Interactive Provider - IProvider example instead - which waits for an incoming consumer connection.

You should be able to run some of the basic EMA Java Consumer examples directly connected to the various EMA Java IProvider examples provided.

e.g. from two consoles on the same PC, you can execute something like:

c:\Refinitiv\RTSDK-2.0.2.L1.java.rrg\Java> gradlew runiprovider100

and

c:\Refinitiv\RTSDK-2.0.2.L1.java.rrg\Java> gradlew runconsumer100

That should start up an instance of IProvider100 example and the Consumer 100 example. Consumer100 will request IBM.N from DIRECT_FEED service and IProvider will accept the login from the consumer, generate a dummy Refresh and Update Messages.

Hi @Konrad

I am not sure I understand your reply i.e. Why your application needs to stay non-interactive? Can you please expand on the requirements/design of your application?

Hi @Konrad

Thanks for confirming - I was asking for further information in an attempt to find a possible way forward.

As mentioned above, A NiProvider cannot connect directly to Consumer - as it does not accept incoming connections. It connects to the ADH.

A Consumer can connect to an Interactive Provider such as an ADS or other IProvider application.

HI @Konrad

I am not aware of any simple way of doing this - as it would require implementing certain aspects of ADH functionality.

The only thing I can think of is - for my personal testing of NIProvs away from an ADH, I run a local instance of our 'Real-Time Connector' product (in a local Linux VM / Docker instance) which is configured to accept a NIProvider source. I am then able to connect a Consumer to the RTC and test my NIProvider locally.

I mention the above, in case your organisation may possibly be licenced for the RTC - in which case your internal MarketData team could install and configure an instance of RTC for you to run locally?

Hi @Konrad

Yes - the RTC is a bit like a cut-down ADH and ADS rolled into one...

Your consumer connects to it as it was connecting to an ADS and the NIProvider as if to an ADH.

My local RTC is configured on the default ports 14002 for consumers and 14003 for NiProv.

So, for example in my NIProv code I would have something like:

OmmProvider provider( OmmNiProviderConfig().host( "localhost:14003" ).username( "user" ) )

and my consumer as

OmmConsumer consumer( OmmConsumerConfig().host( "localhost:14002" ).username( "user" ) );