The Document Routing Agent (DRA) is a client-side component for Dynamics that allows customers to connect their local printer resources with Dynamics so that printing from the server-side processes are directed to local devices. Details here. We have some customers utilizing very large deployments of these in order to facilitate quick turnaround time – especially in distribution scenarios where label printing timing is critical.
This article is a collection of known issues/workarounds that we have faced that might be valuable to you if you are working with the DRA.
“Key not valid for use in specific state”
This is an error you can hit if the underlying credentials used to connect to Dynamics have changed or expired. The article posted here describes renaming the entire installation folder here (C:\ProgramData\Microsoft\Microsoft Dynamics 365 for Operations – Document Routing), which is effectively forcing s complete re-install. Doing so we cause the installation process to create a new Guid for the ApplicationId and all previous printing registration mappings will be lost. For some deployments this can be hundreds of printer registrations and can be a significant time investment.
You can avoid this re-registering by only removing the TokenCache.dat file instead of the entire directory – this will remove the stored session credentials and allow you to reconfigure them in the app.
Alternatively you can do the complete reinstall and then afterwards update the ida:ApplicationId value in the Microsoft.Dynamics.AX.Framework.DocumentRouting.config config file in the same location. During the reinstall this value will be regenerated – but you can update the config file with the previously used Guid.
Polling Frequency
The DRA polls Dynamics every 3 seconds for new documents to print. This is fine for many of our customers, however large manufacturing and distribution customers often have very tight labeling requirements and expect the timing from scanning of a barcode to label printing to be less than 1 second. One option I have seen customers adopt here is to install multiple DRA clients – thus you will have multiple polling “windows” and likely reduce the overall wait-time to less than 3 seconds.
Another option is to utilize a “hidden” configuration option in the DRA. This default value can be overridden by adding the following key to the file: C:\ProgramData\Microsoft\Microsoft Dynamics 365 for Operations – Document Routing\Microsoft.Dynamics.AX.Framework.DocumentRouting.config
<add key=”ida:DocumentRoutingTimerNumSeconds” value=”X” />
This value can be as low as 1 (meaning it will poll every second).
Note that reducing this will have an impact on your Dynamics instance as a new OData call and DB connection will be initiated for every DRA polling event which could cause performance issues. Be mindful of this and only this this technique if you really have this low printing latency requirements.
Platform Warning
There is a strong connection between the DRA and the platform version used to run Dynamics – the DRA is actually built as part of the platform build. When you start the DRA after updating Dynamics to a new platform version (after a OneVersion monthly update for example) you will see the following warning message in the DRA:
Many customers view this message as an error and go through the process of reinstalling the DRA during each update cycle. While this is best practice to ensure compatibility it is not strictly required – the DRA is backwards compatible to all supported platform releases (meaning the previous three monthly releases). So if you want to avoid updating the DRA each cycle you can simply live with this warning.
Hope these tips were useful – I’ll update with more as I come across other interesting patterns.
