I’m seeing some weird behavior with the On-Demand feature, and was hoping someone can help me out. I have a user permissioned for the IDN vendor service, the base PRODUCT WWDSINPSP, no static Exchange Subservice permissions, and the NYS On-Demand Subservice permission.
What I observe is the following:
Does anyone know what’s going on here? Is there a setting I need to turn on in DACS to make this work as expected (i.e. the second request should turn on NYS, so that subsequent requests return Allowed)?
It might be related to the DACS sink daemon version, the Open DACS application is connecting to. Could you verify the version of DACS Sink daemon? Also, you may modify your Open DACS application to connect remotely to the daemon running on your DACS server.
From my testing, if my Open DACS application connects to old version of DACS Sink daemon (6.3), my application gets the same result as yours. After the permission is granted with On-Demand flag = true, the application has gotten access denied with the On-Demand flag = false.
Unfortunately, I can't replicate this problem. Here there are my settings.
I followed your test step, but I got the different result from you (see the attachment).
What is the Open Dacs Java version that you are using? Is it 7.5.0.L1?
Per Reuters support, the issue was fixed by enabling usage logging for the Sink Daemon (per the instructions here).
However, even after that, the Subservice permission does not show up in the DACS UI until 30 minutes or so after the On-Demand request. The permission shows up immediately if a usage collection is performed in the UI.
Is this how it's supposed to work? I'm astonished by the fact that an On-Demand granted permission needs 30 minutes to propagate through the system!
To summarize, these are the issues that could use improvement:
1. On-Demand functionality does not work if usage logging for the sink daemon is not enabled. That's counter-intuitive and not well- documented. I don't see why usage logging should be needed for On-Demand to work.
2. After an On-Demand permission is granted, this fact is not immediately reflected in the DACS Web UI, which is confusing. The UI is correctly updated at the next usage collection. I assume this is related to #1 above.
3. Even after the new permission appears in the UI, a distribution is needed to propagate it to all services in the DACS system (i.e. servers and sink daemons). This partially defeats the automated nature of On-Demand, since a manual action is required to make the new permission fully effective. I think it would make sense to perform an automated distribution specifically for the user in question, right after an On-Demand permission is granted.