Tuesday, 20 February 2018
Synchronization error due to SQL Plan Guides
Recently we had to create a plan guide in SQL Server (not a good long term solution). Everything seemed to be working fine until we had a production deployment and the database synchronization failed as shown in the screenshot below.
It seems that during synchronization a store procedure is recreated. As our plan guide was based on queries in the stored procedure, AX was unable to drop it. Only solution was to drop the plan guide (disabling the plan guide did not help) and re-create it after the synchronization.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
Sunday, 31 December 2017
SSL/TLS error when calling a web service
For one of our integrations we received the following error when it was enabled in production.
Could not establish secure channel for SSL/TLS with authority ''.
The web service requires some certificates to be installed which were correctly installed. The web service was working fine on development machines. Initial investigation did not find anything different between the development/production systems. We then traced the web service calls using Fiddler on both development and production machines and that's when we found out that the number of ciphers are different on both environment. Production did not had the ciphers highlighted below.
A quick search on internet pointed towards a windows KB (3172614) which adds new ciphers. Installing the KB fixed the issue.
Note: The KB requires restart of the machine.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
Could not establish secure channel for SSL/TLS with authority ''.
The web service requires some certificates to be installed which were correctly installed. The web service was working fine on development machines. Initial investigation did not find anything different between the development/production systems. We then traced the web service calls using Fiddler on both development and production machines and that's when we found out that the number of ciphers are different on both environment. Production did not had the ciphers highlighted below.
A quick search on internet pointed towards a windows KB (3172614) which adds new ciphers. Installing the KB fixed the issue.
Note: The KB requires restart of the machine.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
Labels:
Ciphers,
SSL,
TLS,
WCF,
Web Service
Thursday, 21 December 2017
Error "Data at the root level is invalid" when opening a report
Recently users reported that they receive an error when opening a particular report. The error is
"Data at the root level is invalid. Line 1, position 1."
The call stack of the error is
Even opening the report in Visual Studio was throwing the same error as shown below.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
"Data at the root level is invalid. Line 1, position 1."
The call stack of the error is
Even opening the report in Visual Studio was throwing the same error as shown below.
We exported the report from the AOT and analysed it ina text editor. It turned out that there was a CU/KB applied and the report was part of it. However the report was never upgrade and it had comments from the code upgrade tool. Fixing these comments in text editor, re-importing the report in to AX and deploying it fixed the issue.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
Monday, 7 March 2016
Error while activating inbound port
Last week we received an error while trying to activate a previously working WCF inbound port. The error message was
On investigation we found out that there was a code merge between two TFS branches and somehow one of the EDT used in the service contract was removed. When AIF was trying to generate service artifacts, it could not find the EDT and hence was throwing above error. Once the EDT was re-created, the error disappeared and service activated successfully.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
The service '<SERVICE_NAME_HERE>' could not be generated.\n Error: SysDictType object not initialized.
Stack trace
(S)\Classes\AifServiceDataTypeGenerator\generateType - line 76
(S)\Classes\AifServiceDataTypeGenerator\generateDataContractClass - line 127
(S)\Classes\AifServiceDataTypeGenerator\generateType - line 54
(S)\Classes\AifServiceDataTypeGenerator\generate - line 68
(S)\Classes\AifMessageContractGenerator\generate - line 22
(S)\Classes\AifServiceGenerator\generate - line 30
(S)\Classes\AifServiceGenerationManager\generateServices - line 102
(S)\Classes\AifPortManager\deployPort - line 22
(C)\Forms\AifInboundPort\Designs\DesignList\DeployPort\Methods\Clicked - line 12
The error message was shown on "AIF services" form "General" fast tab.On investigation we found out that there was a code merge between two TFS branches and somehow one of the EDT used in the service contract was removed. When AIF was trying to generate service artifacts, it could not find the EDT and hence was throwing above error. Once the EDT was re-created, the error disappeared and service activated successfully.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
Sunday, 21 February 2016
A call to SSPI failed, AX-BizTalk WCF service
Recently we developed integration between AX and an external system through BizTalk. The data flow from BizTalk to AX was using a WCF service. Everything worked fine in dev/test/uat systems. Once the code was deployed to production system and configured to talk to BizTalk we started getting the following error.
A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The target principal name is incorrect
On investigation we found that User Principal Name (UPN) was not setup properly on the BizTalk Send port. The UPN is usually the AD user under which AX service is running (in an email format e.g. axServiceUser@companydomain.com). It can also be viewed from the service WSDL URI. Find the service from the inbound ports and copy the WSDL URI.
Paste the URI in internet explorer and WSDL will be shown. Scroll to the end and UPN is shown (highlighted below).
Copy this value and paste it in the "Endpoint Identity" in the Send port of BizTalk application as shown below
The error message should disappear.
Note: There may be other causes (Kerberos/Double hop issues) of this error message. In our cause this was the only issue.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The target principal name is incorrect
On investigation we found that User Principal Name (UPN) was not setup properly on the BizTalk Send port. The UPN is usually the AD user under which AX service is running (in an email format e.g. axServiceUser@companydomain.com). It can also be viewed from the service WSDL URI. Find the service from the inbound ports and copy the WSDL URI.
Paste the URI in internet explorer and WSDL will be shown. Scroll to the end and UPN is shown (highlighted below).
Copy this value and paste it in the "Endpoint Identity" in the Send port of BizTalk application as shown below
The error message should disappear.
Note: There may be other causes (Kerberos/Double hop issues) of this error message. In our cause this was the only issue.
This posting is provided "AS IS" with no warranties. Use code at your own risk.
Labels:
AX2012,
BizTalk,
Dynamics AX,
WCF
Subscribe to:
Comments (Atom)







