emeadaxsupport: Unable to connect to the Transaction Service - The case of the missing or mismatched passphrase

[Blog bot]

Источник: http://blogs.msdn.com/b/axsupport/ar...operation.aspx
==============

Multiple operations within the AX for Retail POS application rely on the Retail Transaction service to perform real-time lookups against the headquarter database. This includes inventory lookup, creating customer, stock counts and more.

During the intial configuration of AX for Retail the transaction service is installed and configured. Once present we create a transaction service profile in AX that specifies the name (or IP address) of the transaction server, the port the service is running on, the language and a passphrase. The image below shows an example of this setup. Note the passphrase is stored in an encrypted state.



Once this information is configured in AX, the profile is assigned to POS terminals and when scheduler jobs run they will push the transaction service profile data out to the POS systems. When a cashier performs a transaction service operation the POS then reads this profile to know what server/IP to contact and on which port. As part of its request for data the POS will include the encrypted passphrase it was sent. When the transaction service receives this request it will pass this to AX and there will be some comparisons done to ensure the passphrase the POS is aware of matches what is configured in AX.

The Transaction Service sometimes give errors that are cryptic and difficult to track down. Often the misunderstood Transaction Service passphrase is the source of these problems. There are two reasons for this:

1. Even if as passphrase has not been entered the window makes it look like one is present.
2. You only have to enter the passphrase on this window – you don’t have to enter it anywhere else (a change from earlier versions)

When errors are encountered with the transaction service the first thing to check is the RetailLog table in the POS database. That would be the PosisLog table if you are on AX 2009. The error shown to users at the POS is likely fairly generic, but in this table an administrator is likely to find a much more descriptive error. In some cases you may also need to check the Transaction Service's log file.

In this blog I want to address a couple specific errors I've run into that were preventing POS users from using the transaction service operations that can easily be resolved with a simple configuration change. The scenarios here have to do with the transaction service passphrase. Depending on the scenario encountered you would run into one of the following errors in the RetailLog table when the call to transaction service fails. In these cases the errors will only be apparent in RetailLog and the Transaction Service logs would not have additional details.

Microsoft.Dynamics.Retail.Pos.TransactionServicesInterface.PosRemotingException: ClientChannelSink.ObtainKeysForClient, the server response headers does not contain a signature

Microsoft.Dynamics.Retail.Pos.TransactionServicesInterface.PosRemotingException: ClientChannelSink.ObtainKeysForClient, the server response headers contains an invalid signature

After close review of the errors, you'll notice there is only a slight difference in the messages. The first of these states the response header does not contain a signature, while the other states it contains an invalid signature. To further understand what the message is telling us and how to resolve each one, we first need to understand a little more about how the POS and Transaction Service communicate with one another.

If you are at a point where one of the two errors is occurring then we know that the server and port are setup correctly and that no firewalls are blocking traffic from the POS to the service. You may have already deciphered from the focus here on how the passphrase is used that issues with the passphrase configuration are the root cause of the two errors regarding the ClientChannelSink.ObtainKeysForClient operation.

The first of these errors was stating that there was not a valid signature. This error means that the passphrase at HQ (in AX) is blank. The profile form is misleading, because whether you have entered a passphrase or not it will display the ************ value.

To correct the error where the header does not contain a signature enter a valid passphrase and then run a scheduler job (N-1090 is one) that will send the updated profile to the POS. Note that if the POS is running you must completely exit the POS and then restart the application once the profile has been updated via a scheduler job. The profiles are read at startup and cached beyond that so this is the only way to ensure it picks up the new passphrase from the database.

The second error states the signature is invalid. In this case it means that the passphrase at AX does not match the passphrase at the POS. This typically would occur if the passphrase was updated at HQ and the change has not yet been pushed down to the store. It could also occur if the change has been pushed but the POS application has not restarted.

To resolve the invalid signature error only requires that the scheduler job be ran to push the current profile to the store and that the POS application gets restarted.




Источник: http://blogs.msdn.com/b/axsupport/ar...operation.aspx