In Microsoft Dynamics NAV “7", This release will deliver significant enhancements and new capabilities, such as the new Web and SharePoint clients.
To enable these transformations, we will be optimizing selected technology components, or replacing with more modern or more standardized alternatives.
The list below outlines key technologies that will be discontinued in the release
Updated technologies highlighted in this document
1 C/FRONT and C/FRONT .NET (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”
For reading and writing data from external programs and systems, use Microsoft
Dynamics NAV Web Services:
• Simple Object Access Protocol (SOAP) Web Services (originally introduced in
Microsoft Dynamics NAV 2009).
• New Microsoft Dynamics NAV Queries.
• New “OData” Web Services.
2 Microsoft Dynamics Server-side COM components (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”
Change or redevelop your COM components to .NET. Utilize the standard .NET library or your own.NET types directly from C/AL code using the .NET Interoperability feature Introduced in Microsoft Dynamics NAV 2009 R2,or the new enhanced .NET Interoperability features to access the .NET components. We will support
.NET 4.0 and below. A .NET DLL compiled with Any CPU can run on both Server and Client Side. A .NET DLL compiled towards a specific target must be 64-bit for the Server and 32-bit for the Client. You can continue to use COM components on the Windows Client but it will not be possible to deploy server-side COM components on a Worker Role in Windows Azure.
• Alignment with .NET development process, enabling developers to utilize most of the .NET standard library directly from C/AL.
• Free reuse of a vast library of functionality relevant for Business Applications from the .NET Framework. Furthermore, as the .NET Framework is part of the Microsoft Dynamics NAV install, there is no need to install additional external components when using it.
• Simplified component management using .NET Interop and the .NET Framework.
• You can still develop your own .NET components for tasks that are better suited for .NET development.
3 Microsoft Dynamics NAV Application Server (NAS) (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”
For “passive” service scenarios – where Microsoft Dynamics NAV acts upon incoming requests - use Microsoft Dynamics NAV Web Services.
For asynchronous/background execution scenarios, use the new Background sessions.
For “active” scenarios - where a headless session actively manages what needs to be done - utilize the new “NAS on NAV Service Tier”.
• Ability to leverage the Microsoft Dynamics NAV Service Tier.
• More stable NAS installations that are easier to maintain using Windows Service Recovery Management and the Event Log. In addition, Microsoft Dynamics NAV “7” is PowerShell scriptable.
• Network Printing Support can be utilized from the Background sessions.
4 Dataport Object Type (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”For Fixed and Variable Text import and export, and XML import and export, use the new XMLport Object Type. The XMLport Object Type is enhanced in a number of ways, and now also supports:
• Unicode.
• Large files.
• Auto-Save/Update/Replace.
• Licensing.
5 Classic Runtime Stack (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”
Forms and any other means of executing on the Classic runtime stack are removed,
and all runtime execution is on the three-tier runtime stack. As a result, all classic runtime is replaced by execution on the NST (NAV Service Tier). There are several ways to invoke the NST runtime:
• Pages in the RTC.
• SharePoint client.
• Web client.
• Triggers on various events from XML Ports.
• NAS invoking AL code.
• Web services. Essentially, any runtime component will go through the NST rather than directly to the database, and all C/AL code will execute on the NST.
6 Classic database (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”
Replaced by SQL server only support.
• Delivering performance benefits and meeting the current and future needs.
• Enabling the new Query object for fast data access.
• Alignment with Microsoft SQL Server strategy.
7 Classic/Hybrid reports (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”
Replaced by SQL Server Reporting Services (SSRS) based Report Definition Language Client-side (RDLC) reports. Reports are RDLC 2008 based, taking advantage of the SSRS report definition and rendering engine.
• Stronger reporting capabilities as a response to customer needs
• Enabling new report design capabilities for creating professional and elegant looking reports in Microsoft Dynamics NAV.
8 Classic Debugger (Remove from Microsoft Dynamics NAV “7”):
Recommended technology to be used in Microsoft Dynamics NAV “7”
Replaced by the debugger in the Role Tailored Client.
• The debugger UI runs on the familiar RoleTailored client.
• A more extensive debugger with added capabilities.
• You can now debug RoleTailored client sessions, Microsoft Dynamics NAV Portal Framework for Microsoft SharePoint 2010 sessions, Odata & SOAP web services sessions, and NAS services sessions
9 32-bit server (Remove from Microsoft Dynamics NAV “7”);
Recommended technology to be used in Microsoft Dynamics NAV “7”
The NST in Microsoft Dynamics NAV “7” will only support 64-bit execution, so a
64-bit Windows OS is required to run the NST.
Please note that this communication should not be considered a complete listing of technology changes planned for Microsoft Dynamics NAV “7”.
Thursday, April 12, 2012
Saturday, October 9, 2010
NAV Communication Components
What is Comcom and Bus adapter?
Both Comcom and the bus adapter are automation servers developed by Microsoft for NAV. Comcom is a general communication component. All it does, is sending and receiving messages. You need to use a bus adapter with Comcom. The bus adapter is specific to the media used to transport the messages that Comcom sends and receive. At the moment there are two bus adapters: One for MS Message queue, and one for Named Pipes. In this document we will use the bus adapter for MS Message queue (MSMQ).
The reason for having Comcom as well as a bus adapter is, that you can create your application using Comcom without being concerned about what the transport media is going to be. When you decide on that / or if you want to change the media used, it will only require small changes – the application itself would need only very minor changes.
Prerequisites
Microsoft Dynamics NAV communication components come as part of SDK on the product CD. This needs to be installed before you start. And, you need to have MSMQ installed.
Create a new queue in MSMQ:
Open Computer Management, expand "Services and Applications", and you should see "Message Queuing" here, if MSMQ is installed. Expand "Message Queuing", and then expand "Private Queues". Note that the MSMQ Busadapter is only tested with private queues, and is unlikely to work with public queues.
Right click on "Private Queues", select New -> Private Queue, and enter a name. Let's call it MQueue. Also note that MSMQ Busadapter has not been tested for Transactional queues, so leave the field "Transactional" blank.
Now you have the queue, and the rest is up to Microsoft Dynamics NAV to send a message into this queue.
Create a new codeunit. First we need do declare the following variables to get access to Comcom:
Name Type Subtype
Comcom Automation 'Navision Communication Component version 2'.CommunicationComponent
ComOut Automation 'Navision Communication Component version 2'.OutMessage
OutStr Outstream
All automation variables need to be initialized before they can be used. Type these two lines to initialize Comcom and ComOut:
CREATE(Comcom);
ComOut := Comcom.CreateoutMessage('Message queue://');
'Message queue://' is the actual word Message queue. We need to tell Comcom to send the message in a format for Microsoft Message queue. But this is the only reference to the media (until we get to the bus adapter).
Remember, Comcom has only one purpose Sending/receiving messages. It is for writing the actual message that we want to send that we need OutStr. OutStr will contain the message, and Comcom will send it.
To associate Comcom with OutStr, add this line:
OutStr := ComOut.GetStream;
OutStr.WRITE('This is my message.');
Once the message is done, we just need to send it. Send it in this way:
ComOut.Send(0);
That’s the application done. Finally, we just need to add our bus adapter, which needs to be specific to what transport media we are using - in this case MSMQ.
Add one more global variable:
Name Type Subtype
MSBus Automation 'Navision MS-Message Queue Bus Adapter'.MSMQBusAdapter
To “plug in” the bus adapter, type in these lines at the beginning of the codeunit:
Create(MSBus);
MSBus.OpenWriteQueue('\Myqueue',0,0);
Comcom.AddBusAdapter(MSBus,0);
Your final codeunit should now look like this:
OnRun()
CREATE(Comcom);
CREATE(MSBus);
MSBus.OpenWriteQueue('Computername\Myqueue',0,0);
Comcom.AddBusAdapter(MSBus,0);
ComOut := Comcom.CreateoutMessage('Message queue://');
OutStr := ComOut.GetStream;
OutStr.WRITE('This is my message.');
ComOut.Send(0);
To test is, try to run it, then look the queue and see if the message was sent.
Next, we want to receive this message.
Receiving a message
Create a new codeunit with these variables:
Name Datatype SubType
Comcom Automation Navision Communication Component version 2'.CommunicationComponent
InMsg Automation Navision Communication Component version 2'.InMessage
InStr InStream
MSREBus Automation 'Navision MS-Message Queue Bus Adapter'.MSMQBusAdapter
Line Text 250
Highlight the Comcom variable, go to properties, and set the property WithEvents to Yes. This will create a new trigger called:
Comcom::MessageReceived(VAR InMessage : Automation "''.IDISPATCH")
This trigger will automatically run whenever there is a new message in the queue.
The finished codeunit should look like this:
OnRun()
CREATE(Comcom);
CREATE(MSReBus);
MSREBus.OpenReceiveQueue('computername\private$\lll',1,1);
Comcom.AddBusAdapter(MSREBus,1);
Comcom::MessageReceived(VAR InMessage : Automation "''.IDISPATCH")
InMsg := InMessage;
InStr := InMsg.GetStream;
InStr.READTEXT(Line);
MESSAGE(Line);
Go to Codeunit Properties, and set the property SingleInstance to Yes. Now, you can either run it from the object designer, or you set up NAS to run this codeunit.
First codeunit to send a message to MSMQ, and another codeunit which can listen to this queue, and which is triggered as soon as a message arrives.
Both Comcom and the bus adapter are automation servers developed by Microsoft for NAV. Comcom is a general communication component. All it does, is sending and receiving messages. You need to use a bus adapter with Comcom. The bus adapter is specific to the media used to transport the messages that Comcom sends and receive. At the moment there are two bus adapters: One for MS Message queue, and one for Named Pipes. In this document we will use the bus adapter for MS Message queue (MSMQ).
The reason for having Comcom as well as a bus adapter is, that you can create your application using Comcom without being concerned about what the transport media is going to be. When you decide on that / or if you want to change the media used, it will only require small changes – the application itself would need only very minor changes.
Prerequisites
Microsoft Dynamics NAV communication components come as part of SDK on the product CD. This needs to be installed before you start. And, you need to have MSMQ installed.
Create a new queue in MSMQ:
Open Computer Management, expand "Services and Applications", and you should see "Message Queuing" here, if MSMQ is installed. Expand "Message Queuing", and then expand "Private Queues". Note that the MSMQ Busadapter is only tested with private queues, and is unlikely to work with public queues.
Right click on "Private Queues", select New -> Private Queue, and enter a name. Let's call it MQueue. Also note that MSMQ Busadapter has not been tested for Transactional queues, so leave the field "Transactional" blank.
Now you have the queue, and the rest is up to Microsoft Dynamics NAV to send a message into this queue.
Create a new codeunit. First we need do declare the following variables to get access to Comcom:
Name Type Subtype
Comcom Automation 'Navision Communication Component version 2'.CommunicationComponent
ComOut Automation 'Navision Communication Component version 2'.OutMessage
OutStr Outstream
All automation variables need to be initialized before they can be used. Type these two lines to initialize Comcom and ComOut:
CREATE(Comcom);
ComOut := Comcom.CreateoutMessage('Message queue://');
'Message queue://' is the actual word Message queue. We need to tell Comcom to send the message in a format for Microsoft Message queue. But this is the only reference to the media (until we get to the bus adapter).
Remember, Comcom has only one purpose Sending/receiving messages. It is for writing the actual message that we want to send that we need OutStr. OutStr will contain the message, and Comcom will send it.
To associate Comcom with OutStr, add this line:
OutStr := ComOut.GetStream;
OutStr.WRITE('This is my message.');
Once the message is done, we just need to send it. Send it in this way:
ComOut.Send(0);
That’s the application done. Finally, we just need to add our bus adapter, which needs to be specific to what transport media we are using - in this case MSMQ.
Add one more global variable:
Name Type Subtype
MSBus Automation 'Navision MS-Message Queue Bus Adapter'.MSMQBusAdapter
To “plug in” the bus adapter, type in these lines at the beginning of the codeunit:
Create(MSBus);
MSBus.OpenWriteQueue('\Myqueue',0,0);
Comcom.AddBusAdapter(MSBus,0);
Your final codeunit should now look like this:
OnRun()
CREATE(Comcom);
CREATE(MSBus);
MSBus.OpenWriteQueue('Computername\Myqueue',0,0);
Comcom.AddBusAdapter(MSBus,0);
ComOut := Comcom.CreateoutMessage('Message queue://');
OutStr := ComOut.GetStream;
OutStr.WRITE('This is my message.');
ComOut.Send(0);
To test is, try to run it, then look the queue and see if the message was sent.
Next, we want to receive this message.
Receiving a message
Create a new codeunit with these variables:
Name Datatype SubType
Comcom Automation Navision Communication Component version 2'.CommunicationComponent
InMsg Automation Navision Communication Component version 2'.InMessage
InStr InStream
MSREBus Automation 'Navision MS-Message Queue Bus Adapter'.MSMQBusAdapter
Line Text 250
Highlight the Comcom variable, go to properties, and set the property WithEvents to Yes. This will create a new trigger called:
Comcom::MessageReceived(VAR InMessage : Automation "''.IDISPATCH")
This trigger will automatically run whenever there is a new message in the queue.
The finished codeunit should look like this:
OnRun()
CREATE(Comcom);
CREATE(MSReBus);
MSREBus.OpenReceiveQueue('computername\private$\lll',1,1);
Comcom.AddBusAdapter(MSREBus,1);
Comcom::MessageReceived(VAR InMessage : Automation "''.IDISPATCH")
InMsg := InMessage;
InStr := InMsg.GetStream;
InStr.READTEXT(Line);
MESSAGE(Line);
Go to Codeunit Properties, and set the property SingleInstance to Yes. Now, you can either run it from the object designer, or you set up NAS to run this codeunit.
First codeunit to send a message to MSMQ, and another codeunit which can listen to this queue, and which is triggered as soon as a message arrives.
Subscribe to:
Posts (Atom)