Classic Client, RoleTailored Client and MSMQ

For the following Situation:

In Table 18 Customer

Trigger OnModify:

(…)

FMXIntegrationManagement.CreateMessage(Customer);

(…)

Where:

CreateMessage(Customer : Record Customer)

InitNavComCom();

IF NOT XMLPORT.EXPORT(XMLPORT::ACCMOD,OutS,Customer) THEN BEGIN

MESSAGE(Text002,XMLPORT::ACCMOD);

END;

IF NOT OutMsg.Send(0) THEN BEGIN

MESSAGE(Text003,XMLPORT::ACCMOD)

END;

Where :

InitNavComCom()

IF ISCLEAR(MQBus) AND ISCLEAR(CC2) THEN BEGIN

IF ISSERVICETIER THEN BEGIN

IF (NOT CREATE(MQBus,TRUE,TRUE)) OR (NOT CREATE(CC2,TRUE,TRUE)) THEN BEGIN

ERROR(Text001);

END;

END ELSE BEGIN

IF (NOT CREATE(MQBus,TRUE)) OR (NOT CREATE(CC2,TRUE)) THEN BEGIN

ERROR(Text001);

END;

END;

END;

CC2.AddBusAdapter(MQBus,1);

CompanyInformation.GET;

MQBus.OpenWriteQueue(CompanyInformation.“FMX Trigger Queue Name”,0,0);

OutMsg := CC2.CreateoutMessage(‘Message queue://’+CompanyInformation.“FMX Trigger Queue Name”);

OutS := OutMsg.GetStream();

Variables:

Name DataType Subtype

MQBus Automation ‘Navision MS-Message Queue BusAdapter’.MSMQBusAdapter

CC2 Automation ‘Navision Communication Component version 2’.CommunicationComponent

OutMsg Automation ‘Navision Communication Component version 2’.OutMessage

OutS OutStream

CompanyInformation Record Company Information

In Classic Client, results are as expected: modifying a Customer creates a Message.

But In RoleTailored Client, when pressing OK button after modfying a Customer record, the error:

“The Server net.tcp://localhost:7046/DynamicsNAV/Service is either unavailable or oyur connection has been lost. Do you want to attempt to reconnect?”

When choosing yes or no, the following error occurs: “The connection to the servers has been lost. The application will close.”

Investigating a litle bit further, Computer Management → System Tools → Event Viewer → Windows Logs-> Application, found the following error:

Service: MicrosoftDynamicsNavServer#### User: FR8\aluna#### Type: System.InvalidCastException#### Message: Unable to cast object of type ‘Microsoft.Dynamics.Nav.Runtime.NavAutomation’ to type ‘Microsoft.Dynamics.Nav.Runtime.NavStream’.#### StackTrace:#### at Microsoft.Dynamics.Nav.Runtime.NavAutomation.InvokeMethod[T](String methodName, Object[] arguments)#### at Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50002.InitNavComCom()#### at Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50002.CreateMessageACCMOD(INavRecordHandle customer)#### at Microsoft.Dynamics.Nav.BusinessApplication.Codeunit50002.OnInvoke(Int32 memberId, Object[] args)#### at Microsoft.Dynamics.Nav.Runtime.NavApplicationObjectBase.Invoke(Int32 methodId, Object[] arguments)#### at Microsoft.Dynamics.Nav.BusinessApplication.Record18.OnModify()#### at Microsoft.Dynamics.Nav.Runtime.NavRecord.Modify(DataError errorLevel, Boolean runApplicationTrigger, Boolean runGlobalTrigger)#### at Microsoft.Dynamics.Nav.Service.NsDataAccess.Modify(DataError errorLevel, Boolean runApplicationTrigger)#### at Microsoft.Dynamics.Nav.Service.NsFormDataAccess.Modify(DataError errorLevel, Boolean runTrigger)#### at Microsoft.Dynamics.Nav.Service.NSRecord.Modify(NavConnection con)#### at Microsoft.Dynamics.Nav.Service.NSService.<>c__DisplayClass2b.b__2a(Connection connection)#### at Microsoft.Dynamics.Nav.Service.NSService.ExecuteOperation[T](String operationName, ServiceOperation`1 operation, Connection connection, Boolean revertLanguageChanges, WindowsIdentity impersonationIdentity)#### Source: Microsoft.Dynamics.Nav.Ncl

we think this exception is caused in InitNavComCom, Line OutS := OutMsg.GetStream();

It looks like the service tier is crashing.
One suggestion that is a design issue is that you are sending the record when it’s modified all in one transaction.
This slows down performance and will cause locking issue, because nav has to wait for other system to respond.
If the other system is down, then you cannot modify the customer record.
I suggest to create the message in a staging table and let NAS to monitor and send all unprocessed messages.
Second when you create the automation, you need to instantiate it on the server instead of the client.

use
CREATE(MQBus)
CREATE(CC2)

Well, we have decided not to use MSMQ components of Navision, coz is giving lots of headaches on RCT even though we have then working on the Classic Client, instead we are using xml files on a directory.

Thank you for your help, highly apreciated!

I notice from your reply below that you have changed your approach but I thought I would try an answer anyway, just incase someone else is having a similar issue and comes across this post. From the code… OutMsg := CC2.CreateoutMessage(‘Message queue://’+CompanyInformation.“FMX Trigger Queue Name”); OutS := OutMsg.GetStream(); I would guess that the CreateoutMessage is failing to create an out message and hence you should probably test this object is not empty before tying to get the handle to the stream. So why does createoutmessage fail? If you’re running on three tiers my immediate thoughts are missing communication components on service tier, ivalid queue name for service tier and delegation issues (possibly user does not have permission to write to message queue when using delegation). I agree with the suggestion of writing to a staging table and prcessing later, but I see you have gone for a file based approach. If you are not using three tiers to test this, you should as you may find writing the files to a location not on the service tier box fails.

hello gaspode:

Thanks for your response and recoomendations. We did test the aproach with the RCT using three tiers with the MSMQ, making sure that the queues name existed, and with all the propers permissions, however, is quite valid the thought that the GetStream may fails trying to use an empty Object. Howver is not applicable in our case, again we tested and debuged with correct queues names and correct permisions, we even tested something very siilar with a pure C# code class.

In the other hand, we have succesfully tested our aproach using files in both Classic and RCT three tiers and i am glad to say is up and runing and working as desired.

Cheers to all!!!

Ayna