I have a custom RSSL Interactive Provider built using RFA 7.6.2.E2 (C++ edition)
When this Interactive Provider is added to TREP it registers onto DACS using the username under which the Provider's process is running e.g. something like the 'radmin' user on Linux. This appears to happen "under the covers" as there is no code in the Provider explictly setting the user name.
If I wanted to replace this default user name with "CONFIG-NAME" it is my understanding that I should populate a StandardPrincipalIdentity and pass this as the second parameter to Session::acquire (see the following code snippet). Is this the correct thing to do?
rfa::common::StandardPrincipalIdentity* principalIdentity = new rfa::common::StandardPrincipalIdentity();
principalIdentity->setName(rfa::common::RFA_String("CONFIG-NAME", 0, false));
principalIdentity->setAppName(rfa::common::RFA_String("256", 0, false));
principalIdentity->setPosition(rfa::common::RFA_String("x.x.x.x/net", 0, false));
rfa::sessionLayer::Session* session = rfa::sessionLayer::Session::acquire("SessionMP1", principalIdentity);
Even if this is the right thing to do, the RFA Developer Guide (C++ Edition) states that: "The Session interface allows specification of a Principal Identity when acquiring a Session. This feature has been deprecated starting in RFA C++ 7.2 and will be removed completely in a future release. OpenDACS should be used instead."
The OpenDACS Developers Guide isn't entirely clear about how this should be achieved for an Interactive Provider. Is the following code snippet using AuthorizationAgent::login() correct?
// Assume same StandardPrincipleIdentity as above
rfa::dacs::AuthorizationRequest* authRequest = rfa::dacs::AuthorizationRequest::create();
authRequest->setPrincipalIdentity(principalIdentity);
// Assume rfa::dacs::AuthorizationAgent* authAgent and rfa::common::EventQueue* eventQueue
rfa::common::Handle* loginHandle = authAgent->login(*eventQueue, *authRequest, *this, NULL);
If I do use this OpenDACS interface, will the Session interface (until it is removed from RFA) still login with the "default" user name if I don't pass a StandardPrincipalIdentity to Session::acquire?
Do you have any idea about when the Session/PrincipalIdentity interface will be removed from RFA?
1
●0 ●0 ●0
DACS name for Provider application (RFA 7.6)
11.3k
●25 ●8 ●13
Below is the information regarding the DACS connection and username.
- If DACS is enabled on ADH, when ADH connects to an Interactive Provider there will no User Login on DACS system. According to ADH Installation Guide document, DACS on ADH should be enabled for Non Interactive Provider and Posing purpose. This should imply that it doesn’t apply to Interactive Provider.
- RFA RSSL Interactive Provider doesn’t have any connection to DACS server. The DACS connection was for MarketData interface only. For example, the Session::acquire() with principal identity is only for MarketData Interface such as Managed Publisher.
- For Open DACS, the AuthorizationAgent::login() will login to DACS system. The username needs to be added on DACS system.
Anyway, the login normally is required when an application needs information regarding a user on DACS system. If your application just calls the getServiceAttributes() method, it doesn’t need any login() call and username on DACS system.
20.3k
●73 ●10 ●20
If you are developing an Interactive Provider using RSSL protocol, then the Principal Identify parameter does not apply. If you refer to the documentation it states 'for Market Data only' - which is not particularly clear but means it only applies to the legacy MarketFeed connection types.
For RSSL connections, the username is set at part of the MMT_LOGIN message - but since you are writing an Interactive Provider, the ADH will be mounting your Provider and therefore sending your application a Login Request - rather than you sending one to the ADH.
I am not a TREP expert, but I believe that to change the username you will need to ask your MarketData team to modify their ADH config (e.g. rmds.cnf file) entry corresponding to your servicename and specify the username in there.
e.g.
node*adh*route.route*userName : <dacs username>
If the above entry is missing, I suspect that the ADH may be defaulting to radmin which is the typical/common Linux account used to run the ADH and ADS components.
