Hi @thanhqlptit96

Assuming they are both using the same RSSL transport - then an RFA Interactive Provider should be able to communicate with an EMA Consumer.

I have just done a basic test connecting the \StarterProvider_Interactive example from RFA with Consumer100 example from EMA - connecting directly to the Provider and it appeared to work fine.

If you are connecting via an ADH/ADS etc that should also work fine.

Hello @umer.nalla,

Related to your reply about doing a basic testing, would it be possible if you can provide a code snippet or direct me to a documentation on how you did your testing so I can verify as well on my side?

Please assist us on this matter. Thanks.

Hi @support6

I compiled and ran StarterProvider_Interactive and configured it using the attached config files

ExampleRFA.cfg.txt

StarterProvider_Interactive.cfg.txt

Renamed to .txt for upload.

The key changes to the above were to change the port to 14006 in the ExampleRFA.cfg(I am already using 14002 locally for something else) and change the service name to RFA_FEED in the application cfg file(already using DIRECT_FEED locally).

Note that I also had to modify the Provider code to read the .cfg files rather than the Registry (which is the default on Windows builds).

I then modified my EMA C++ Examples\Training\Consumer\100_Series\100_MP_Streaming\Consumer.cpp file as follows:

int main( int argc, char* argv[] )
{ 
    try { 
        AppClient client;
        OmmConsumer consumer( OmmConsumerConfig().host( "localhost:14006" ).username( "user" ) );
        consumer.registerClient( ReqMsg().serviceName( "RFA_FEED" ).name( "ESZ1m" ), client );
        sleep( 600000 );                // API calls onRefreshMsg(), onUpdateMsg(), or onStatusMsg()
    } catch ( const OmmException& excp ) {
        cout << excp << endl;
    }
    return 0;
}

and then started up the RFA IProvider exe, followed by the Cons100.exe

The Cons100 was successfully able to request the dummy RIC ESZ1m from RFA_FEED on port 14006.

Hi @support6 and @thanhqlptit96

I just ran up the EMA Java Viewer example connecting to my RFA Provider on localhost and it was able to consume RICs from RFA_FEED

Hi @thanhqlptit96

I don't see why the above would not work.

Do you see any dictionary related warnings or error messages?

I did configure my EMA Java viewer example to use local dictionary files..

To do this for the Cons 100 example you can change the EMAConfig.xml to use Dictionary_2 (which in the default version of the EMAConfig.xml is for local dictionary files in the same working directory).

<DefaultConsumer value="Consumer_1"/>
    <ConsumerList>
        <Consumer>
            <!-- Name is mandatory -->
            <Name value="Consumer_1"/>
            <!-- Channel is optional: defaulted to "RSSL_SOCKET + localhost + 14002"-->
            <!-- Channel or ChannelSet may be specified-->
            <Channel value="Channel_1"/>
            <!-- Dictionary is optional: defaulted to "ChannelDictionary"  -->
            <Dictionary value="Dictionary_2"/>
            <XmlTraceToStdout value="0"/>
        </Consumer>

You will then need to ensure the dictionary files are available in the working folder.
If you are using the Gradle commands to execute runConsumer100 - then this should take care of copying the dictionary files into the same folder e.g. RTSDK-JAVA\Java\Ema\Examples - but you should double check.

Hi @thanhqlptit96

I was also able to get the EMA examples working with ChannelDictionary by testing with the more comprehensive Provider_Interactive RFA example - so I suspect there is some limitation in the Starter example which does not interact well with an EMA Consumer Login attempt.

If you continue to see issues, I would recommend enabling low-level trace in your RFA and EMA application to see what is going on at the wire level:

# for RFA config
\Connections\Connection_OMMProv\traceMsgToFile            = true
\Connections\Connection_OMMProv\traceMsgDomains            = "all" 

# for EMA JAva
<Channel value="Channel_1"/>
    <Dictionary value="Dictionary_1"/>
    <XmlTraceToStdout value="1"/>
... and so on 

This may help shed some light on why they are not talking to each other well.