OpenDACS CBE parameters clarification (itemName, PeList) and technical questions

jose.cruz

Hello, I'm using OpenDACS .NET,

And I need to verify the permissions of the end-users of my application for the data that I'm providing,
For that I believe that I need to use CBE (Content Based Entitlements) subscription check.

Exploring the CBE, I faced some parameters:
The serviceName is "ELEKTRON_AD", which is verified, because when I put others I get rejected.
Also, the position which is basically the user <ip address>/net. I have an appId as well.

But regarding itemName, I don't know what is this, at first I believed it to be the ticker, for example: "912828YB0=RRPS", but when I put a random number, I'm getting authorized as well. Could you maybe give an example and explain why am I getting authorized for random itemNames?

Also regarding the PeList, how do I find exacly which PE's do I need to check? I know we are going to fetch CME futures, bonds etc, but how do I map it exacly so I check the user properly.

Couple more technical questions:
- As I'm going to have multiple users connecting to my application, I need to login each one and check it's permissions multiple times. Is it a good practice to reutilize the EventQueue, AuthorizationSystem and AuthorizationAgent across DacsClients ?
- Does the user login have an expiration ? Or can I login them once and save in cache to check permissions?

Thank you,

Jirapongse

@jose.cruz

Thank you for reaching out to us.

To perform CBE entitlment checks via Open DACS API, the AuthorizationLockData (permission data) is required. An Item name represents a RIC, such as IBM.N.

Permission data can be retrived via the real-time feed after subcribing to items. For example, the following is the permission data (permData) of IBM.N retreived from the real-time feed.

<refreshMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="4" containerType="RSSL_DT_FIELD_LIST" flags="0x1FA (RSSL_RFMF_HAS_PERM_DATA|RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_HAS_SEQ_NUM|RSSL_RFMF_SOLICITED|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_HAS_QOS|RSSL_RFMF_CLEAR_CACHE)" groupId="1" seqNum="12976" permData="0301 0162 C0" qosDynamic="0" qosRate="2" qosTimeliness="1" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text=""  dataSize="1871">
    <key  flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)"  serviceId="5001" name="IBM.N" nameType="1"/>
    <dataBody>
        <fieldList flags="0x9 (RSSL_FLF_HAS_FIELD_LIST_INFO|RSSL_FLF_HAS_STANDARD_DATA)" fieldListNum="79" dictionaryId="1">
            <fieldEntry fieldId="1" data="3E"/> /*3E is 62*/
            <fieldEntry fieldId="2" data="40"/>
            <fieldEntry fieldId="3" data="494E 544C 2042 5553 204D 4143 4849 4E45"/>
            <fieldEntry fieldId="4" data="02"/>

The permission data can also be created from the service ID and a list of PEs. PE is associated with each RIC and it is the PROD_PERM field (FID 1) of the retrieved data.

DACS maps PEs to sub-services and sub-services are assigned to DACS users.

For more information, please refer to Open DACS Tutorials.

• Content Based Entitlements (CBE)

Regarding to your questions:

• Yes, it is a good practice to reutilize the EventQueue, AuthorizationSystem and AuthorizationAgent across DACS users.
• Each login has its own handle. The handle is valid as long as it is opened. You can can close the handle by logout. Yes, you can login each user once and use the handle of that user to perform multiple entitlement checks.