Please note that all DMS news and blog content has been moved to the main website at www.dynms.com for a categorized view.
All utilities and downloads are available at www.dmsiworks.com
You’re a developer, and you’ve been asked to make a part of MS Dynamics NAV web accessible. Great! It’s out of the box in NAV 2013.
Uh oh, it’s not 2013 yet? No problem, you still have options and should probably consider licensing, architecture, and integration interfaces soon.
Licensing.
The first step is get licensing out of the way. Determine before you start which licenses your client will need or already has available, as they will affect your architecture. Have handy the number of users that will be accessing your site, and whether they will be internal or external. (Hint: your scenario will probably be in one or more of the following granules 1240, 1260, 1280, 2450, or 2510). Some of these licensing options are very expensive and could change some of the requirements.
Architecture.
If you’re lucky, you will find a third party component that fits the bill. In most cases you will end up needing to either custom build or build an integration component. Every situation is unique, but there are a few patterns that you’ll see more often with Dynamics NAV sites.
An Existing Purpose-Built Website, Synchronizing the Information
If you’re lucky, you will find a website solution that is purpose built for the problem you’re solving. A retail system is a good example. In this scenario you just need to have a mechanism to synchronize the data, and often not in real-time. For example, prices can be updated in a batch process nightly from NAV into a retail system, and sales information can be grabbed from that system and put into sales journals and posted in Dynamics NAV. In this scenario you only need to custom build the synchronization component. This component could connect to either your business web services or do regular updates from a landing area in your Dynamics NAV database (for example writing sales into the sales journal, and potentially reading current pricing or inventory from Dynamics NAV).
An Existing Custom Website, That Now Needs to Integrate Some NAV Data with Existing Data
Sometimes you’ve got a website with a database that already exists, and you just need to grab some of the data and merge it with some other information.
If you need to merge the data, and the data does not need to be real-time then your integration option looks similar to the 3rd party component web site.
An Internal Website, or a Website that Needs Real-time Information
If it’s an internal website, or need real-time data then you can connect directly the Dynamics NAV SQL database or to the Dynamics NAV web services.
There are many variations of the above. For example, you might want database replication to keep your NAV data available and not have web usage introduce risk or load on your company operations.
Choosing the Integration Interface to Connect with NAV
There are several NAV interfaces, but you’ve really got two main options. RTC business web services (Dynamics NAV pages or CodeUnits exposed as business web services), or direct to SQL server. The best choice will really depend on your architecture, which is also affected by your licensing.
2009 Web Services, AJAX > RTC Web Services
If you’re using NAV 2009 you have the option of using the RTC web services. These web services are really meant for SOA integration, however you could just expose the RTC web services directly over the Internet and then have a completely AJAX driven website connect to that, however the web service requires you to be authenticated against Active Directory. This has a few implications:
- Licensing (again). Every user would need windows CAL and a dynamics NAV C/AL. This option is fine for your existing Dynamics NAV users as that license fee would already have been paid, but it makes it more costly to allow access for your customers or vendors. It’s not an option at all for anonymous logins.
- Kerberos double (or more) hop. Having gone through this several times it’s doable, however be aware that some IT departments will not allow web accessible computers to delegate authentication, which is a key step in configuring double-hop to work properly. Determine now before you start whether this is a possible deployment scenario, because sometimes it’s a showstopper.
2009 Web Services, but with Your own Custom Decorators and Controllers on Top
Dynamics NAV 2009 web services are WCF based, which makes it very simple to connect to from ASP.Net based systems. This also provides the option to have your web site exposed with it’s own custom forms based authentication, while still connecting to NAV as a single application user (check your licensing options before you do this). This makes it easy to execute NAV business logic from within your custom website, and provide access to data.
Direct to SQL Server
If you’re using Dynamics NAV 5 or earlier then web-services aren’t available as an option, and you will often need to just connect to SQL server directly.
Even if you’re on 2009 or later, the downside to using the NAV web services is that it is not the most efficient communication available. For performance-minded applications this is not often a solution as you’ll have your website data layer, making an HTTP call to the web services, passing noisy XML data back and forth, and having that XML data serialize and de-serialize both on the side of Dynamics NAV and your custom website.
Your challenges with the direct to SQL Server option are:
- No business logic is available.
- The table naming convention of prefixing SQL server tables “CompanyName$” will make it more difficult to develop and deploy, and can also cause problems with newer frameworks such as Ruby on Rails, or MVC.Net
Tim Dimsdale
Dynamic Manufacturing Solutions
No comments:
Post a Comment
Your comment will be posted once approved.