NAS and msmq problem

Cem_Karaer

Hi all,

We decided to use NAS to make a B2C portal for one of our customers. Customers of our customer will login in the Web site and make a quote request. They will be able to create quote headers and add quote lines the same as an ordinary NAV user does in the client environment. We setup the NAS, designed our web site in ASP.NET, configured msmq and made necessary code changes in NAV. In the test environment, on which IIS, NAS and NAV are installed on the same machine, everything goes all right.

But live system of our customer has a different configuration for its web site. NAV is installed on a server (server A); NAS and IIS are installed on another server (server . In our tests we see that NAS works but cannot listen the msmq on the server B. Could it be that it tries to listen the server A's queue?

Note: SQL Server 2008, NAS & NAV 4.03

DenSter

If you are using the standard NAV MSMQ Bus Adapter, it needs to be a private, non-transactional queue, and only the basic MSMQ components need to be installed. If your queue is not a private wueue, if it is transactional, or if you have more than just the standard MSMQ components installed, it will not work properly.

Saalek

Hi

I has similar problems 4 years ago with a Web Server and I don't remember exactly my solution, but I think I created a Windows Registry Entry refering Web server Queue name.

Read this post
viewtopic.php?f=14&t=3666

Using CpHandler DLL, "\SOFTWARE\QUEUE" is a Registry entry that refers other machine queue,so you can comunicate between diferents servers using MSMQ.

I'll try to refresh my memory.

Bye

Cem_Karaer

DenSter wrote:

If you are using the standard NAV MSMQ Bus Adapter, it needs to be a private, non-transactional queue, and only the basic MSMQ components need to be installed. If your queue is not a private wueue, if it is transactional, or if you have more than just the standard MSMQ components installed, it will not work properly.

Hello DenSter,

Queues are private and non-transactional in our case. But what are non-standard msmq components?

DenSter

When you enable the MSMQ components (control panel, programs and features, turn on Windows features, which is where you enable MSMQ), there are a number of things you can select. You only need the core component. I've had issues with MSMQ when having the AD integration turned on caused it to simply not work, messages would just disappear. We turned it off and it started working.

KYDutchie

Hi,

Also how is your queue name defined in your C\Al code?
If it is like this: "direct=os:.\private$\freight", then the NAS will listen to a local private queue named "Freight".
Because it is on a different server, please use : "direct=os:\\<servername>\private$\freight".
Furthermore please allow everyone full access to the message queue on the server. This will prevent a lot of issues I encountered.

A little hint, turn of the "Journal" option on the queue. We noticed it stopped processing because it ran out of space with that option turned on.

Hopes this helps.

Regards,

Willy

AndreB

You are not running the NAS and MSMQ on a 64 bits server? I tried that some time ago and found out that NAS will not listen to the MSMQ on a 64 bits server. We had to install it on a 32 bits server to get it all working.

Cem_Karaer

AndreB wrote:

You are not running the NAS and MSMQ on a 64 bits server? I tried that some time ago and found out that NAS will not listen to the MSMQ on a 64 bits server. We had to install it on a 32 bits server to get it all working.

Oh no!! It's Windows Server 2003 x64. I hope you are kidding me.

ara3n

I suggest to use MSMQ instead of BA. I have tested MSMQ on 64 bit OS windows server 2003 and it works fine and reads the messages from message queue.

Seppo

ara3n wrote:

I suggest to use MSMQ instead of BA. I have tested MSMQ on 64 bit OS windows server 2003 and it works fine and reads the messages from message queue.

I have tested last week also and did not work. Microsoft replied that msmq is not working on 64-bit Windows environment. See KB942755 and KB960369 in Partner Source. How did you get it working? I could only send messages to message queues but reading (Comcom::MessageReceived(VAR InMessage : Automation "''.IDISPATCH")) did not succeed.

DenSter

What Rashed means is that the standard NAV MSMQ Bus Adapter (BA) won't work on 64 bit, but using the MSMQ object directly, it does work on 64 bit.

If you write your own queue monitor code, and you use the MSMQ object model directly, there are a lot less limitations. In that case you can use transactional queues, different labels, you can read messages without processing them. The downside is that this way you have to write all the code yourself, and it is not event driven.

Cem_Karaer

Seppo wrote:

ara3n wrote:

I suggest to use MSMQ instead of BA. I have tested MSMQ on 64 bit OS windows server 2003 and it works fine and reads the messages from message queue.

I have tested last week also and did not work. Microsoft replied that msmq is not working on 64-bit Windows environment. See KB942755 and KB960369 in Partner Source. How did you get it working? I could only send messages to message queues but reading (Comcom::MessageReceived(VAR InMessage : Automation "''.IDISPATCH")) did not succeed.

I don't think that NAV & msmq don't work on x64 environment. I was informed that in another project of ours, same techniques are used successfully on x64 Win2003 server. I strongly believe that the problem stems from the topology of servers. Does it matter that SQL server running the NAV database and NAS listening the msmq are on different servers?

Cem_Karaer

I learned that x64 platforms were Windows 2008 Servers on which NAS runs successfully. I think that using Navision MS-Message Queue Bus Adapter in Win2003 x64 as desired is not possible.

The main reason of the problem is that 'Navision Communication Component version 2'.CommunicationComponent's ComCom::MessageReceived(VAR InMessage : Automation "''.IDISPATCH") event is not triggered.

DenSter

Did you set the WithEvents property of the variable?

Cem_Karaer

Yes.

ara3n

DenSter wrote:

The downside is that this way you have to write all the code yourself, and it is not event driven.

I remember implementing MSMQ in 2.6 using Microsoft automation and I remember that Events do work with Microsoft MSMQ.
There is MSMQEvent object that you can create it withevents and it has Arrived Event.