question

Upvotes
Accepted
3 0 1 2

Connectivity issue with Reuters from Murex test environment

This is with regards to connectivity testing with Reuters from Murex. We currently encountered an issue on RFA client (Murex Application using reuters-rfa-config-editor-rfaj7.2.0.E3.jar). We find that the communication with RMDS cannot be established. Can you advise if one of the parameters from the configuration file is wrong, or the sessionName used by Murex is not the right one? Do let us know if you need more information. Specifically, there seem to be something wrong during authentication and below is the exception:

java.lang.RuntimeException: Fatal exception: Could not acquire the RFA Session for [session name = Murex::RSSL]

The configuration xml is as attached (Refer rfa_configuration.xml in attachment). We have loaded the configuration file into the RFA configuration editor successfully: (Refer doc file in attachment). Please find attached logs for your reference (Refer rtbsrfa_35577_HBDMXUAT1APP3.log in attachment ).

Attachment (Attachments.zip)

attachments.zip

treprfarfa-api
attachments.zip (122.2 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvote
Accepted
14.3k 23 8 12

Hi @Nitin.Patil

Please be informed that the RFA Java session name is "case sensitive". Regarding the rfa_configuration.xml file, the session name is "Murex::RSSL". But the log file shows

2017-08-09 11:12:34,760 INFO  - sessionName = MUREX::RSSL
...
Fatal Error: Could not acquire the RFA Session : MUREX::RSSL 

which means the Murex application sends session name "MUREX:RSSL" to the API, so the API cannot find this session in the configuration database.

I have populated your rfa_configuration.xml to my local environment and replicated the issue with RFA Java StarterConsumer example. The results are following:

  • with _session = Session.acquire("Murex:RSSL");, the example works fine
  • with _session = Session.acquire("MUREX:RSSL");, the application encounters the same error.

I suggest you change the session name in your application from "MUREX:RSSL" to "Murex:RSSL" instead.

If you still encounter the problem after changed the session name, please give me your application source code that acquire RFA session.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Good catch. :-)

Thanks for your response @wasim I noted that after posting the issue here. I've changed it and tried re-testing it with one more change on port i.e. RSSL on 14002 as suggested by Lars-at-Addicticks . Now I'm able to connect Reuters but not sure why it is not fetching the rates. Trouble shooting further. I'm sharing your and below response with Murex. Thanks for your help

One more thing to notice i.e. We were able to connect only via SSL on 8101 whereas RSSL on 14002 was still unable to fetch data from Reuters. Any reason for the same.

The interface which Murex has created will either be using the SSL protocol or be using the RSSL protocol. If it uses the former it must connect to your TREP on port 8101, if it uses the latter it must connect to your TREP on port 14002. Only Murex can tell you if their interface is using SSL or RSSL. (beware when you talk to Murex technician because most likely to him the letters 'SSL' means something entirely different than what it means in the Thomson Reuters world). Murex' application is unlikely to support both protocols. Their documentation will hopefully tell you more.

Upvotes
1.5k 3 5 7


The XML file looks ok. I'm guessing the problem has to do with the storage of preferences or perhaps more specifically the user under which you execute this particular Murex module vs the user where you do the RFA config. They need to be the same.

But why all this config complexity?, you may ask. Why can't you have your RFA config in a traditional config file somewhere next to all your other Murex config files? Right now your RFA config is somewhere out of sight, pretty well hidden unless you know where to look.

This is a long explanation and has to do with Oracle's default implementation of Java Preferences which RFA - unfortunately - uses as default config solution. In order to use an application that uses RFA Java you'll need to know a lot about Java Preferences. Much more than you care to. Very few people have deep knowledge on Java Preferences and the internals behind it.

The good news is that you can add Preferences2Go jar to your application (in this case Murex's module). This way you can have your RFA config in an XML config where ever you want, meaning the way most IT operators would prefer. You'll never again wonder what RFA config it will pick up and moving host is easy. Just like for any other application. Enjoy.

Hope this helps.

----

Ohh, one more thing. Murex (the company) seems to have misunderstood the concept of a service in RMDS (or TREP as it is called nowadays). There is no reason why you would need to specify serviceList. Your application (Murex) doesn't connect to a specific service on TREP, it just connects to TREP. Once connected an application can consume from any service for which it is permissioned. Likewise for Murex.

This is a common misunderstanding that third parties do. Murex is not alone on that. They've typically constructed their interface to TREP in such a way so you'll need to run one of their interface daemons for each service you want to consume from on TREP. So you'll end up having Murex daemon "RFA1", "RFA2" and so on. Many operating processes for something that should only be one. Also, TREP will see it as multiple physical connections. All this could have been done with only one.

Well, that was a side track. If your TREP only has one service anyway, IDN_RDF, and your Murex only needs to consume from that and never more, then the misunderstanding made by Murex will never really bother you. :-)

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks Lars. I'm sharing your response with Murex for their troubleshooting.

Upvotes
1.5k 3 5 7

Once you've solved the 'where-is-RFA-picking-up-my-config-from' problem (described above), I can see there may be another problem. You are using RSSL protocol to connect to your TREP installation. The default port for RSSL is 14002, not 8101. Pretty sure you would run into that problem once you've solved the other problem. Unless of course you really run your TREP in such a way so that exposes RSSL on port 8101, but I doubt it.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
14.3k 23 8 12

Hi @Nitin.Patil

The given rfa_configuration.xml shows the API is configured to connect to ADS via the RSSL connection via port 8101

 <node name="rssl">
   <map>
      <entry key="connectionType" value="RSSL"></entry>
      ...
      <entry key="portNumber" value="8101"></entry>
      <entry key="serverList" value="{your ip}"></entry>
      ...
   </map>
</node>

Basically, port 8101 is the default SSL port on ADS server and the default RSSL port for ADS is 14002 (both of them can be configured in ADS configuration file). I suggest you check the ADS server for the following points

  • Does the ADS enable the RSSL connection?
  • What is the RSSL port on that ADS?

Then configure the rfa_configuration.xml to match the ADS RSSL port.

If you still cannot connect and consume data from the ADS via RSSL port, please give us the RFA log files and the error or status messages that return from the API.

You can add the following RFA Java configurations to the rfa_configuration.xml rssl node to enable the log file

<entry key="ipcTraceFlags" value="7"></entry>
<entry key="mountTrace" value="True"></entry>
<entry key="logFileName" value="{path to log file}\RSSL_%U.log"></entry>
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

rfa-configuration.zipWe have already changed the port to 14002 over RSSL. Attaching revised rfa file for your reference. Do let me know incase you see anything which is stopping us from connecting on RSSL.

Upvotes
14.3k 23 8 12

Hi @Nitin.Patil

The given RFA configuration looks fine. Please give me the RFA and application log files when the problem occurs. You can enable the RFA log file with the following configuration

<node name="rssl">
	<map>
		<entry key="connectionType" value="RSSL"/>
		<entry key="dacs_CbeEnabled" value="false"/>
		<entry key="dacs_GenerateLocks" value="false"/>
		<entry key="dacs_SbePubEnabled" value="false"/>
		<entry key="dacs_SbeSubEnabled" value="false"/>
		<entry key="downloadDataDict" value="true"/>
		<entry key="portNumber" value="14002"/>
		<entry key="serverList" value="172.17.4.36"/>
		<entry key="serviceList" value="IDN_RDF"/>
		<entry key="ipcTraceFlags" value="7"></entry>
		<entry key="mountTrace" value="True"></entry>
		<entry key="logFileName" value="RSSL_%U.log"></entry>
	</map>
</node>

The log file named RSSL_0.log should be in the same folder as the application.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.