Recently one of my colleagues ran into a strange issue. When performing some actions on the POS that involved calling AX 2012 via Real Time Service, the call failed. In another environment with the same code base, the code succeeded. Also, the RTS failure happened only on certain calls, other calls against the same server worked correctly (the specific case: retrieving a previous sales order succeeded, but sending a completed return order to AX failed).
The event log on the RTS machine was quite confusing: the error message was “Cannot create a record in System parameters (SystemParameters). The record already exists.” But there was nothing wrong with the system parameters.
I captured the request from the POS to the RTS and wrote a small job in AX to call the respective class/method directly using the same request and this worked fine. Even more confusing.
The solution came after realising that the Real Time Service uses .NET Business Connector to connect to the AOS. From the architectural perspective, the Business Connector is like a regular AX client without a user interface. Recently the AX environment in question had been updated with new code – but the same code worked fine on another machine. Earlier I had seen weird issues on a regular AX client where the solution was to get rid of the user cache files. And this turned out to be the solution for the RTS too. Continue reading
I have been investigating most of the basic Dynamics 365 for Operations Modern POS (MPOS) & Cloud POS (CPOS) deployment scenarios on a windows 10 platform. Here are my findings showing when you can use the MPOS & CPOS, based on your LAN & WAN connection status and your deployment scenario.
Typical Deployment Scenarios
In all scenarios without WAN connectivity Real-Time service call are not available
If you are working offline in the POS Local only mode at the end of a shift without access to a channel database through the scale unit, it will not be possible to close the shift on the POS device and complete cash management tasks. Continue reading
Sometimes you are faced with debugging something where the debugger tool is not available on the system you are working on or you might need to collect some data that is not easily captured using the debugging tool.
In this situation you can consider instrumenting your code with trace statements. Clearly you would not normally do this is in a production environment but it sometimes a good and quick approach in a development system.
The code instrumentation can simply be with Info Log statements or outputting trace data to a file.
I have used this technique today (with Ax 2012 R2) when I wanted to analyse what RetailTransactionService methods get called by the Retail POS ‘Recall Order’ function. On all of the key methods in class RetailTransactionService that I thought might be used I placed my instrumented code. In this example the RetailTransactionService calls are made via the business connector and so I instrumented the code to write details of the methods to a file rather than use an Info Log. This enabled me to confirm that the Retail POS calls the following methods when you click on the Recall order function and search for orders: –
|Recall order –Search (having input customer and order number)
||RetailTransactionService::SearchCustomerOrderListAnd then followed by
|Gets a list of ordersGets details of each order
||Gets called to retrieve more details of order
I achieved this without using the debugger tool or debugging the POS. This gave me a quick way to confirm beyond all doubt what methods on the class are called by the Retail POS for the Recall order function.
Debugging is always about using the right approach at the right time….