Dynamics AX 2009 Business Connector Logon

Question

Background: I'm currently working with the Dynamics AX 2009 Business Connector in C#. For my current project I need to connect to multiple AOS servers; ideally all in parallel, though sequentially would be adequate. I can connect to one server (any server) successfully, but always hit a LogonSystemChangedException if I try to connect to a different server (or even the same server but using null to connect to it as default instead of by specified name). I even get this error if I Logoff and Dispose the previous BC, set the variable referencing it to null, put the thread to sleep for 30 seconds, call GC.Collect() (sorry - desperate times) then create an entirely new BC looking at a different instance of AX altogether in an new variable. This suggests that MS's code has some static object behind the scenes which persists this information throughout the processes lifetime.

Found Suggested Solutions:

• I found a suggested fix of using LogonAs along with the correct formatting for the AOS instance here: http://asonofmartha.blogspot.co.uk/2010/06/ax-net-business-connector-how-to-open.html - but have tried this with no luck.

• The only thing I've found so far which works is to create a second process for the second connection - but this is an unpleasant solution.

Why: My reason for connecting to multiple AOSes is I'm writing a CLR table function which connects to a given AX instance, loops through all AOS servers on that instance then returns a list of all clients & their SPIDS (which are only visible when connected to that session's AOS). This is to allow our monitoring software to return information about the AX user session when we see blocking on the database.

Question: Is there way to connect to more than one AOS using the AX .Net Business Connector within the same process (sequentially if parallel's not possible)?

Answer 1

Some time ago I faced this problem and didn't get a solution. I asked MS through my employer service plan and it seems that .NET BC stores some kind of cache of the connection data that is not released until the entire process ends. This is not planned to change, as .NET BC is going to be fully deprecated on the next version.

What I did was develop a service that ran against an AOS and then run three instances of the service, each of them gattering information from an AOS to an SQL table, where I could get all the information consolidated.

Hope this helps.

Answer 2

Since you want parallelism anyway, why not go for sub-processes?

Fork a sub-process for each AOS server of the instance, collect the answers on the same shared pipe (or similar) until end-of-file then wait for sub-process death, which should be eminent as they have all closed the output.

Estavan have answered your question as stated.