Compose/Decompose Compound DACS Locks
I'm trying to understand how I may use the OpenDACS API to work with complex logical combinations of permission entities (PEs).
The DACSLOCK_devguide section 3.4 (Compression of DACS Locks) suggests that both AND and OR operators may be used in a single compound lock:
1027 & (456 | 985) & 5000The document goes on to explain how such compounds are compressed in binary coded decimal.
I can't see any way to compose nor decompose such a compound using the API (C++).
The logical operator can be specified in the AuthorizationLock class, but it only operates on type long PEs. I can use this to compose (1027&5000) and, separately, (456|985).
The AuthorizationLockData class allows for combining multiple AuthorizationLockData instances, but has no way to specify the logical operator.
How may I use the APIs to compose a lock of PEs: 1027 & (456 | 985) & 5000.
Or another example to compose: (123 & 456) | (321 & 654)
Will I instead have to work on the raw char* lock data buffer?
Hello @Craig Thomas,
You are looking to create compound locks.
It appears you are coding a publisher application in RFA C++. It then means you would be referring to the document
If that is the case, please see "operator". Operator is set when a lock is constructed, can be "&" or "|". We can appendPE(), and obtain lock data, our ultimate goal, using getLock().
AuthorizationData from multiple locks can be combined, using combineLock.
(Perhaps you are coding in ETA. Same concepts implemented for ETA C++ can be found in
Transport API C DACS Library Functions)
In terms of the API usage- RFA C++ or Refinitiv Real-Time ETA C/EMA C++, this should cover the requirements.
However, there may be more to the underlying logic of lock creation. The original lock could have an "|" between PE. Because the same item (for example IBM) can be permissioned via one of several PEs. Can also have an "&". Because multiple permissioned items can be included. When several items from multiple sources are combined into a compound item, in order to consume the item, the user has to be permissioned for all of the items included. I.e. "|" will not work. Essentially, it is "&" on compound, which is why combineLock() function works to derive the necessary compound lock.
If you are coding a new publisher, I would strongly suggest going with Refinitiv Real-Time ETA/EMA for the implementation, as these are contemporary APIs, having all of the latest features and actively evolving. RFA is a currently supported, but feature-complete API choice.
Let me know if this helps, or if this is not what you are looking for, please explain more of the use case and the API being used.
Thanks for the response @zoya.farberov.
Just to clarify, the AuthorizationLockData::combineLock() function essentially ANDs the AuthorizationLockData arguments (using the & operator)?
Hello @Craig Thomas,
The section of DACS Lock Guide "Compression of DACS Locks" describes and illustrates in detail the content that will ultimately be conveyed in the resulting DACS lock.
Yes, this is what is logically happening to the compound lock as it's being combined, and the reason why the approach works, hopefully is also more intuitive now.