I have found interesting Dynamics Nav Web Client functionality thanks to which we can create Dynamics Nav Page as part of other website. It's cool thing, but how it's look with user license?
Is it possible to create website which has Dynamics Nav Web Client Page where everyone can do something(including people without Navision license)?
It's not possible - at least not in a way you access a public website, where the number of connections is limited only by the server's resources. Actually, connecting to a Nav server via a web client is not much different than using a Windows client or Sharepoint client from the licensing point of view. In any case, the client doesn't hold the license. License file is uploaded on the server, and the server side is responsible for keeping an eye on license restrictions.
Since Nav uses concurrent licensing model, any user who can authenticate, is able to connect to the server as long as the number of concurrent sessions does not exceed the licensed limit, no matter which client they connect with.
You can read more about Nav licensing on MSDN or download a Licensing Guide
Related
I built web app by golang, and I want integrate it with Microsoft Dynamics NAV, and I don't know from where can start,
Is there a way to integrate Microsoft Dynamics NAV by REST API, or any other methods?
Depending on the version of NAV we're talking about, a number of its object types (not really OO; think ~modules) can be published as SOAP or OData webservices. For reading and writing NAV data, I would probably recommend a page-based webservice.
For more information on how to expose a NAV page as a webservice, please refer to https://msdn.microsoft.com/en-us/library/dd355316(v=nav.90).aspx (SOAP) or https://msdn.microsoft.com/en-us/library/hh166960(v=nav.90).aspx (OData).
You can Integrate your third Party apps with dynamics Nav by using OData Link
Microsoft Dynamics Nav 2016 and greater versions support these features
To Get OData Base URL you have to run dynamics nav Administration Shell as an admin
Click on OData Services here you can Get Odata Port and URL
IF your OData Service is not Enable than click the check box and restart the Dynamics Nav Instance
This post refers to SOAP and OData Web Services in Dynamics NAV 2016 (or later) and hopefully it is not off-topic. I would like to know whether the following facts are true or false (or it depends).
Given Starter Pack functionality, and default Customer License with no extra Development Granules:
A Full User can publish any page (say, Customer or Employee) as a Web Service.
When consuming a published Web Service from another software service, a separate NAV user should be created and not be associated with a real person - and this is fine with respect to NAV's licensing (e.g. Perpetual Licensing with Concurrent Client Access Licenses).
A Full User can create a codeunit (in the allowed range of 10 codeunits for the Starter Pack) and publish the code unit as a Web Service.
Both a Full User and a Limited User can be used to authenticate against a Web Service.
In other words, I would like to know to which extent is a customer of Starter Pack (no extra Development Granules) able to integrate NAV with other software systems via SOAP / OData endpoints - without relying on the elevated development capabilities of a Certified Partner / Value Added Reseller.
Microsoft Dynamics NAV 2016 Product Overview and Capability Guide
Walkthrough: Registering and Using a Page Web Service (SOAP)
MS Dynamics NAV - development licensing basics
Upon cross-posting on dedicated Dynamics forums (Dynamics NAV Users and Dynamics Community), I reached the following conclusions:
True.
True, but must be aware of licensing issues related to multiplexing. Multiplexing is not allowed. More comments about Web Services and internal / external users are here.
Partially true. A Developer License is required to create new codeunits - a Customer License doesn't suffice. Existing codeunits can be published as Web Service though.
True.
I need to serve a SOA application though an AJAX/REST API. The service need to be sold to customers which will be able to host a JS on their sites which will let their users communicate with our webservice.
Needs:
the customer only should put a one line in its page, no server side code
the script should authenticate and download the API js code to communicate with the enabled services (depending on the licensing options the customer buy)
the overall path should work without having the customer's users to see logins nor certificates
I can't find a pattern to fullfill the previous requirements at the same time. Do you have suggestions?
I've considered various options, but at the minimum thet reuire to install server side code on my customer's machines, but I cannot do it (they have their own third party hostings, of various nature).
Thanks a lot,
Giovanni
In all cases we are running .NET Framework 3.5
My company has a server running Windows Server 2003 R2 (Service Pack 2), 32-bit processor. The IIS instance on this machine runs several Websites. One of the Websites we are running is Microsoft CRM 4.
When I attempt to log in to CRM from my local PC, everything's perfectly straightforward. I receive a prompt for username and password, I enter the details, I'm authenticated, and I pass through. Easy.
However: I can RDP into the 2003 Server and open IE. If I then browse to our CRM website I am prompted for a username and password. I provide exactly the same details - including the correct domain - as I enter from my local PC. But nothing. I'm denied access.
I am an administrator both of my local PC and of the 2003 Server.
This is very weird. I don't even know where to begin looking on this one. I don't even know what key terms to hit into Google.
Any help would be very much appreciated.
Context
Now, knowing what developers are like (I am one) the first response is going to be: "If you can log in from your PC, why do you care?"
There's more going on.
We have another website on that server that does nothing but host a set of critical web services. This is because the critical web services themselves rarely change but the other features change all the time. We don't want the critical web services to go down while maintenance is performed on other areas, so they were split off into their own independent web site about 18 months ago.
I am developing a web service for the critical site. This Web Service itself includes a proxy that points to the CrmService of CRM 4. The idea is that we want people to be able to submit certain information - such as lead contact information - into our CRM. However, we don't want to give just anyone access to the whole CRM system (obviously). So by publishing our own WebService that sits in the middle we can expose only the functionality that we want other people to have.
This new web service is now ready for deployment. All scenarios are met, all unit tests pass, everything that should fail does. It's all hunky-dory.
When I put that WebService on the 2003 Server, suddenly it can't communicate with CrmService any more due to authentication failure. ???
In my attempts to diagnose the problem, I noticed that no-one - not even administrators - can log into the CRM Website from within the 2003 Server. So I'm suspecting that whatever is causing that issue is also responsible for my web service to be unable to access the CrmService too.
For additional context, we have a new multi-domain SSL cert on the 2003 Server and we're splitting access to all our websites via host-headers.
I can't think of any more relevant information. If I've left out something critical, just ask.
Found it!
http://support.microsoft.com/kb/896861
Did the trick.
Has anyone tried to build an e-commerce site atop MS Dynamics, using the new Web Services introduced in Nav 2009 ? I'd like to know what kind of load these web services can take, and what kind of resources can be read/written, and any other challenges that I can expect.
I intend to integrate an existing linux-based webapp via Web Services ...
Thanks.
Web services in NAV 2009 can call either CodeUnit or Page objects. Pages allow you to create, read, update and delete rows from their source table. CodeUnits offer greater flexibility, allowing you to invoke any action you can implement in C/AL. I think CodeUnit trigger arguements are limited to primitive types and Records.
NAV web services use Windows Authentication, so your linux app will have to be able to present Windows credentials accordingly. I'm not an expert in this area, so I'm not sure how difficult this is from a Linux machine.
With regard to the supported load, I would ask in the forum at mibuso - this is the largest community of experienced users I am aware of. I expect you will be limited by the CPU and memory of the web service host. NAV does not support clustering\load balancing on the web service tier, but I beleive it is possible to run several side by side.