First off a little bit of theory. Dynamics AX is a client-server application and utilizes a special protocol/interface for client-server communication. Namely versions prior to 4.0 used AOCP (Axapta Object Communication Protocol) implemented over TCP/IP and versions 4.0 and above have moved to an
RPC interface. The client-server communication details inevitably change over time as kernel updates are released and obviously for robust Dynamics AX kernel operation it's vital to make sure that a client and a server
understand each other precisely i.e. use the very same «dialect» of the communication protocol/interface. Hence an internal communication protocol/
interface versioning is used in Dynamics AX kernel to find out if an arbitrary client can safely connect to and communicate with an arbitrary server.
Those of you who has worked with Axapta 3 might remember that when you start a client with a kernel build number different from the AOS' kernel build number then the client most likely fails to connect to the AOS and complains about «Internal revision mismatch in Axapta Object Communication Protocol»; then it
suggests to use the same kernel build for both client and Object Server. Why is it just a suggestion? First, the client has no idea if the server's kernel build matches it's own, and vice versa the AOS has no idea if a client attempting to connect has the same kernel build number as the AOS. Second, Dynamics AX clients and servers with non-matching kernel build numbers
can connect and work with each other in case they use the same version of a communication protocol/interface.
The first statement might look arguable. If you look in the
User log (
Administration/
Inquiries/
User log) you can find there some technical information about a user's session such as a client computer name, a client type and some kind of build number. Aha! So Object Server
does know exactly the client's kernel build number, right? Wrong. A
SysUserLog record which represents User log data is filled right in
SysUserLog.insert() method. And while
SysUserLog.Computername and
SysUserLog.ClientType field values represent corresponding
xSession object properties,
SysUserLog.BuildNum field is initialized with a value returned by
xInfo::buildNo() static method which has no explicit
client or
server modifiers. In 3-tier environment a table variable is generally located on the server side, hence
SysUserLog.insert() and
xInfo::buildNo() are executed
on the server side and
SysUserLog.BuildNum field receives
server's kernel build number. So, once again, an AOS has no idea if a client attempting to connect to it has the same kernel build number or not.
So when it comes to client/server interoperability, Dynamics AX kernel relies solely on the communication protocol/interface version, not kernel build numbers. And if that version is the same in client an server binaries then those binaries can be safely used together. But how can you know what communication protocol/interface version does an arbitrary Dynamics AX kernel binary use? Well, here is a utility for you:
viewer for Dynamics AX AOCP/RPC interface version used by an given DAX kernel binary. Prior to a kernel binary file name you can pass these command line arguments:
-nosigcheck - omit Authenticode verification (useful for some legacy kernel builds that miss the Authenticode digital signature)-debug - output additional technical information about the binary and print more detailed error messages if any
You now can easily find out (and check it out) that Dynamics AX 4.0 SP1 and SP2 binaries work together as they use the same RPC Interface version; and so do Dynamics AX 2009 TAP3 and RTM binaries...
