#1 If you experience a warning in the eventlog (application), Event ID 110 on the BizTalk Server saying "An X++ exception has occurred. Unable to lock resource channel '<channel name>'" (see sample below), I would suggest to look at how you have defined channels, action policies, document services etc. with regards to what is defined in the different company accounts since this can in fact lead to conflicts. We first related this to installing AX 2009 SP1 since it was the only change recorded in the same time frame and we didn't see this while we worked with the RTM release. The solution was to clean up in the AIF configuration using the AX client, but the cause is at the time beeing not known (it could be SP1, but that's only a theory at the time beeing).
Update 2008/12/17:
After looking into the details, I also noticed a change of the warning logged by BizTalk for the same issue. Sample of the warning logged initially (figure 1) and a new version of the same message (figure 2) is shown below. I guess that something changed in SP1 and that the problem can be related to a required reboot of the BizTalk Server after applying AX 2009 SP1 (not logged or notifyed by the installer).
#2 Disparsed documentation. The documentstion for AX 2009 is quite good for AIF configuration, but is's very sparse when you are looking for details about the configuration of the transport properties in BizTalk (Visual Studio). If you want to understand the difference between the various authentication types, you have to look up the corresponding documentation for AX 4. At least this was where I found the answers to my general questions.
Posts
3 comments:
I have encountered the same problem now, how are you to solve this problem? thanks.
We have had the same issue with AX, what I normally do is run the following script
select * from dbo.AIFRESOURCELOCK
select count(*) from dbo.AIFMESSAGELOG
select count(*) from dbo.AIFGATEWAYQUEUE
select count(*) from dbo.AIFQUEUEMANAGER
select top 10 * from dbo.AIFMESSAGELOG
delete from dbo.AIFRESOURCELOCK
delete from dbo.AIFGATEWAYQUEUE
delete from dbo.AIFQUEUEMANAGER
what you normally see is that the resource table has multiple locks -Rerun the script and everything should work.
However, if anyone has the Queue manager form open then it wont work, the Queue manager form will re-add the locks.
You will have to reissue your messages.
It's ugly but it does work.
The post from BR summarizes the solution that worked for us. A key table is AIFRESOURCELOCK and this table should alwasy be the first one to check when you experience issues. We also decided to delete the existing endpoint defintions and establish them from scratch. This solved our issue and we have not experienced this after the clean up was done. Hope this was helpful.
Post a Comment