groupId RsslBuffer type to std::string

Hi @tinmyo.win,

EDIT: The answer below was based on testing against an EMA IProvider Training example that set the group ID. However, through further testing, it appears the example does not properly assign the group ID based on network byte order. I will need to confirm with the development team. Please refer to the first answer above for the actual algorithm to process the group ID.

First thing, I updated my answer above to correct the algorithm to properly extract the 2-bytes and store within an unsigned short. Instead of:

unsigned short id = (groupId->data[i] << 8) | groupId->[i + 1];

It now reads:

unsigned short id = (groupId->data[i] | groupId->[i + 1] >> 8);

To create a test case that has a series of 2-byte integers, one way is to utilize one of the EMA IProvider Training examples, specifically 250__GroupStatus__Fanout. In there, you can modify the code to add additional groupIds. For example, I defined a new ID called: 'secondaryGroupId = 19', i.e.

You can add as many as you want to test. Then I simply added the following line within the AppClient::processMarketPriceRequest() method:

You can then take your ETA consumer application and test it against this Provider and you should see 2 ID values (10 and 19) displayed.

Hi @tinmyo.win,

I understand you are strictly using the ETA API, but to setup a simple provider to test is the easiest way given the EMA examples are packaged alongside the ESDK package. You don't have to download / install any separate software to make this work.

That being said, if you have to setup a test that must be written in ETA, I would ask this as a separate question. It helps guide the community to find answers. We don't want to see multiple questions within one post.

Hi @tinmyo.win,

Yes, the first formula I gave didn't manipulate the bytes correctly. The 2nd formula is correct. What do you mean "unable to parse"? I just tried it again without issue.

Hi @tinmyo.win,

Yes, the value I see when testing against my ADS does come back as zero (0) for the 2nd algorthm - the 1st algorithm, the value I received was 1. The reason I believe the 2nd algorithm is correct is because when I tested the against the Provider, the values came back correct. The 1st algorithm resulted in incorrect values.

Why do you believe the value zero (0) is incorrect?

Hi @tinmyo.win,

The 2nd algorithm is the one that you should be using. I know you are seeing zero (0) for your environment but are you able to confirm that your TREP environment has defined group ID's other than zero? Have you tried testing against the EMA example I suggested above? It was that example that allowed me to define my own group ID's to verify that the 2nd algorithm was the one that produced consistent results.

I've reached out to the TREP infrastructure team to provide a setup where a group ID is defined to further verify. I will come back here once I finalize my testing.

Thanks @tinmyo.win for testing against the rmdstestclient tool. As it turns out, I found some convenient message dumping functions 'xmlDumpMsg.c' and 'xmlDump.c' that will output the groupID. After testing with these, I found the 1st algorithm I originally posted was correct. It appears that the EMA Provider example may have an issue with how it packs the bytes.

I've updated the answers above to reflect my findings.

Note: You may discover that when using the rmdstestclient tool, it displays the groupID in Octal. I can't confirm because I don't have the source code handy, but the ETA dump function prints out in decimal.