NI Provider login fails

Hi team!

I've written an NI provider application using RTC. Now I'm trying to login on a pre-production RTDS system.

I'm getting the following two logger messages which seem to indicate that the connection is established correctly, but login fails ("non-consumer attempting login"):

loggerMsg
    TimeStamp: 10:29:22.803
    ClientName: ChannelCallbackClient
    Severity: Success
    Text:    Received ChannelUp event on channel smds006@HZAE_via_jmp01
	Instance Name Provider_1_1
	Connected component version: ads3.8.1.L1.linux.rrg 64-bit
loggerMsgEnd

loggerMsg
    TimeStamp: 10:29:22.886
    ClientName: LoginCallbackClient
    Severity: Error
    Text:    RDMLogin stream was closed with status message
	username 
	usernameType 1
	position <not set>
	appId <not set>
	applicationName <not set>
	singleOpen 1
	allowSuspect 1
	optimizedPauseResume 0
	permissionExpressions 1
	permissionProfile 1
	supportBatchRequest 0
	supportEnhancedSymbolList 0
	supportPost 0
	supportRtt 0
	supportViewRequest 0
	
	State: Closed / Suspect / Usage error / 'Login rejected. Non-consumer attempting login.'
loggerMsgEnd

I developed the app using EMA. The OmmProvider instance is created using an adjusted EmaConfig.xml andOmmNiProviderConfig().applicationId(APPLICATION_ID).username(USER). As mentioned before, I used RTC during development, and never had any connection issues there.

I also tried to set up a consumer connection to the same channel, using the same app ID and username. This seems to succeed - I get a similar "ChannelUp" message as above, followed by a status "Closed/F10: Not In Cache", which is expected.

This looks like a configuration issue to me, either on my side or on the remote side. I would be grateful for any hint regarding the steps that are necessary to fix it.

Thank you in advance,

Helmut

Find more posts tagged with

trep

ema-api

non-interactive-provider

#technology

Accepted answers

Jirapongse

@hdoll

When using a login stream for posting, the application must ensure that the stream is properly opened.

This is why the login stream is retrieved and checked in the callback method.

void AppClient::onRefreshMsg( const RefreshMsg& refreshMsg, const OmmConsumerEvent& ommEvent )

{

…

if ( refreshMsg.getDomainType() == MMT_LOGIN && 

		refreshMsg.getState().getStreamState() == OmmState::OpenEnum &&

		refreshMsg.getState().getDataState() == OmmState::OkEnum )

	{

		_pOmmConsumer->submit( PostMsg().postId( postId++ ).serviceName( "DIRECT_FEED" ).name( "TRI.N" ).solicitAck( true ).complete().payload(

		RefreshMsg().payload( FieldList().addReal( 25, 35, OmmReal::ExponentPos1Enum ).complete() ).complete() ), ommEvent.getHandle() );

	}


…

}

All comments

Jirapongse

@hdoll

Thank you for reaching out to us.

NI Providers and Consumers connect to different TCP ports. By default, consumers connect to 14002 (distribution_rssl_sink) TCP port and NI Providers connects to 14003 (distribution_rssl_source) TCP Port.

distribution_rssl_sink     14002/tcp

distribution_rssl_source   14003/tcp

Please make sure that you have configured RTC to support NI Providers. Please contact the RTC support team directly via LSEG Support for the RTC configurations.

Otherwise, a consumer can use posting to contribute data to RTDS. I am not sure if you would like to use a NI Provider or posting.

hdoll

Hello @Jirapongse,

thank you once again for your quick answer.

I'm sorry for misleading you by mentioning RTC - I used RTC during development, and everything worked fine. The issue occurred when I tried to connect to the pre-production system on the client's site.

The last sentence in your reply lead me to the solution: apparently, the client's system doesn't support connections by NI providers (for reasons I do not comprehend). So I rewrote my app to open a consumer connection, and publish PostMsg objects, into which I wrap my Status, Refresh, and Update messages.

And here I have a follow-up question:

I submit the messages by "off-stream posting", i.e. using a login handle instead of an item handle. I obtain the login handle by registering a pseudo-client (an empty derivation of OmmConsumerClient):

void* closure = (void*)1;
m_loginHandle = m_consumer->registerClient( ReqMsg().domainType( MMT_LOGIN ), m_client, closure );

This solution actually works - the market price messages I submit with this handle are accepted and processed by the destination system - but it seems somewhat cumbersome to me. Is there a simpler, more "natural" way to get a valid login handle?

Thank you,

Helmut

Jirapongse

@hdoll

When using a login stream for posting, the application must ensure that the stream is properly opened.

This is why the login stream is retrieved and checked in the callback method.

void AppClient::onRefreshMsg( const RefreshMsg& refreshMsg, const OmmConsumerEvent& ommEvent )

{

…

if ( refreshMsg.getDomainType() == MMT_LOGIN && 

		refreshMsg.getState().getStreamState() == OmmState::OpenEnum &&

		refreshMsg.getState().getDataState() == OmmState::OkEnum )

	{

		_pOmmConsumer->submit( PostMsg().postId( postId++ ).serviceName( "DIRECT_FEED" ).name( "TRI.N" ).solicitAck( true ).complete().payload(

		RefreshMsg().payload( FieldList().addReal( 25, 35, OmmReal::ExponentPos1Enum ).complete() ).complete() ), ommEvent.getHandle() );

	}


…

}

EXPLORE OUR SITES