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.

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. :-)

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.

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>

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.