RPC errors

One of the areas I find a little bit hard to understand, is the RPC exceptions logged in the event log (application). This is of course specific to AX 4 and AX 2009, but in my opinion Microsoft has done a pore job explaining the prerequisites and relationship between the RPC errors logged as Information and Warnings in the event log.

Sample (AX 2009 on Windows Server 2008)

I have studied this somewhat, but I have never found a good solution to generalize into best practice when installing AX. I understand that something impacts the way a client calls a Remote Procedure being executed on the AOS, but I don’t have a real understanding of the possible reasons. It could be a number of factors ranging from authentication, x++ code/logic (run at property), network packets, time outs, network drivers etc. but I really miss some basic guidelines on how to account for this. Could it also be some registry settings/tweaks needed? If yes, Microsoft should in my opinion indeed help the partners to better understand the prerequisites since this is all about making AX operating without any disturbance and “hidden” issues.

My challenge to eventual readers is to share your experience and help defining a best practice for this area. I would happily share the result of a joint community effort on this blog. If anyone remember the old “Damgaard Technet”, I really miss a common channel for addressing technical issues that I think a lot of partners around the world are experiencing, I don’t understand why every partner must invest in a lot of R&D activities to solve these kind of issues especially since it’s often about not documented prerequisites!

So please donate your experiences as comments to this blog and I promise to compile a best practice that everyone can use to better avoid RPC issues. Since a lot of unpleasant spam occurs in blogs, I have to moderate your comments before publishing but anonymous comments are allowed so keep them coming.

Experiences with the AX BizTalk Adapter

We have now encountered our first issue with the AX 2009 BizTalk Adapter. I will try not to go into every detail, but instead focus on the principal guidelines.

#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.