Sunday, October 27, 2013

AX for Retail: AX code changes not being reflected in POS operations

Issue: When making customizations to the AX for Retail POS class in AX 2102 [Classes\RetailTransactionService] (also known as the AX RTS class), the changes are not being reflected in the operations coming from the POS.

Example of issue: The AX RTS class is modified show additional information in the POS which is time sensitive data and must be retrieved from the headquarters at the time of inquiry (when RTS should be used). The changes are made but the POS is operating like the old code was, not the new code.

Solution: The Retail Transaction Services service (or Commerce Data Exchange in 2012 R2+), which the POS is using to talk to AX, must be restarted for the new code to be seen in the POS. The POS will only use the code as it existed in this class the last time the service was restarted.

Reason: Not entirely sure why this is the case but it appears the code is cached somewhere for the POS instances to use. It doesn't use the code in AX as it changes. I can speculate on why it was designed that way (e.g. performance) but other than that, I'm not 100% sure why it operates that way.

It is pretty common to have the AX developer say an issue is fixed (when in this code) and then have the POS tester see no changes to the code if the RTS service is not restarted. It can create some friction or headaches if you don't know why that is the case. Odds are the AX dev is testing from within AX using a job at which point the RTS component is not utilized so you will get inconsistent results. Once you get into the groove of things, its just one of those things you need to remember to do.

Hope the above helps!

No comments:

Post a Comment