License Requirement and suitability - Web based application

ssinglassingla Member Posts: 2,973
edited 2009-07-24 in NAV Three Tier
Scenario : Not for Profit Organigation giving access of NAV data in customized tables to internal and external users

Client has implemented NAV 2009 and now they have certain data which they want to make available on the web. This will enable the authorized people within the organization, contractors, other external people to acess, modify, insert data (along with document attachment) in those table.

Other external people are mainly the people who gives the organization revenue and has been defined as customer in standard NAV. Other External people are more than 2k and are bound to increase every year. Payment from them are entered in NAV and should be available on the web. Employees have been defined in the employee table.

Apart from this, data in the customized tables has no relation with the standard NAV functionality.

IMHO this perfectly suits the implementation of Employee portal using NAV Server and MOSS License (for employees), external connector (for external people). The issue is that a partner has suggested NAV basic user license with external connector. I assume they are proposing to use Windows Terminal Services/Remote desktop connection to give the users access.

I would like to hear from the experts, suggestions on the following points:

a) Will external connector be able to give access to NAV classic application/RTC client to unlimited external users.
b) Which approach should be followed? We should implement Employee Portal or use WTS/RDC? The scope of web based application is expected to increase manifold within the first few years of implementation.
CA Sandeep Singla
http://ssdynamics.co.in

Comments

  • matttraxmatttrax Member Posts: 2,309
    You'll never get the same answer from more than one person, partner, Microsoft, whatever, but here's my take.

    1) The external connector does not give access to the client itself. It is not required to own it for users to access the data (technically). The licensing agreement is the only thing that makes you have to purchase this. At $5000 (or maybe back to $15000, don't know if the special is still going) it is your best bet. $200 - $400 / user * 2000 users is easily more money.

    2) If your internal people are accessing NAV data with an application other than the NAV client (RTC or Classic) they will also (technically) be required to be licensed through the new model, DCO. You cannot use the external connector for this licensing. I've been told so many different things on this it's not even funny. Microsoft said you didn't need DCO licenses for these users, partner said you didn't if they clicked a button inside the NAV client that took you to the other application, Microsoft Licensing agreement says you need it no matter what.

    Hope it helps a little and at least answers part of your question.
  • jlandeenjlandeen Member Posts: 524
    1) for external access - it sounds like there are pretty simple requirements, read some data from NAV maybe make an update to a table or 2. Exposing and supporting external users (over 2000 of them) on the RTC or NAV client via TS or something I think would be complete overkill. Use the external connector and build a web app or something else to expose this. (IMHO the external connector to a web site/app is just so much simpler to build and support - and it can be supported by non NAV resources).

    2) For the interal people that need access to NAV data/processes I think the question that should be answered is whether or not the processes the internal users will have to access are simple or complex. If they're simple and don't require access to a lot of data and procedures that are in NAV then again pay for a DCO license for each user and build a web/winform application that connects to NAV as necessary. If the requirements are complex then chances are the user will need to user the full NAV client in which case do everything in NAV and forget about DCO.

    In general I think that experienced and qualified NAV resources are in short supply while .NET and other develoeprs are more abundant. In this case it can be a better use of resources to build some applications/functionality outside of NAV (.Net, Java, etc.) and then integrate back into NAV. This requires less dependance on NAV resources while providing a lot of functionality and possibly reducing development, support and maintenance costs - as NAV consultants normally charge at a higher rate then their .NET/Java brethren.
    Jeff Landeen - Sr. Consultant
    Epimatic Corp.

    http://www.epimatic.com
  • bbrownbbrown Member Posts: 3,268
    You must also consider the SQL cleint access licensing. Anyone accessing the SQL database, regardless of how they access it, must be licensed. If you cannot control the number of users (i.e exposing database to anoymous internet access) then you must license for unlimited users. This means processor licensing.
    There are no bugs - only undocumented features.
  • ssinglassingla Member Posts: 2,973
    Thanks to all for helping and giving your suggestions/views.
    bbrown wrote:
    You must also consider the SQL cleint access licensing. Anyone accessing the SQL database, regardless of how they access it, must be licensed. If you cannot control the number of users (i.e exposing database to anoymous internet access) then you must license for unlimited users. This means processor licensing.

    Client has SQL developer processor based license so SQL license is not a problem.
    jlandeen wrote:
    2) For the interal people that need access to NAV data/processes I think the question that should be answered is whether or not the processes the internal users will have to access are simple or complex. If they're simple and don't require access to a lot of data and procedures that are in NAV then again pay for a DCO license for each user and build a web/winform application that connects to NAV as necessary. If the requirements are complex then chances are the user will need to user the full NAV client in which case do everything in NAV and forget about DCO.

    Client is a educational institute. The NAV application/table data will be rarely used in the web based application. It will more of publishing course contents, interaction between client and students, admission process, discussion forum. So the requirement is simple as far as NAV is concerned. We will be looking at list of students and their fee deposit entries in customer ledger.
    matttrax wrote:
    1) The external connector does not give access to the client itself. It is not required to own it for users to access the data (technically). The licensing agreement is the only thing that makes you have to purchase this. At $5000 (or maybe back to $15000, don't know if the special is still going) it is your best bet. $200 - $400 / user * 2000 users is easily more money.
    In India the price is even less i.e. around $3000 + AEP @16%. Though DCO license for all the 2000 users means more money to me, I will not be advising as the client doesn't requires it. I believe we should suggest correct licensing and not look only on profit.
    CA Sandeep Singla
    http://ssdynamics.co.in
  • bbrownbbrown Member Posts: 3,268
    ssingla wrote:
    Thanks to all for helping and giving your suggestions/views.
    bbrown wrote:
    You must also consider the SQL cleint access licensing. Anyone accessing the SQL database, regardless of how they access it, must be licensed. If you cannot control the number of users (i.e exposing database to anoymous internet access) then you must license for unlimited users. This means processor licensing.

    Client has SQL developer processor based license so SQL license is not a problem.

    :?:

    There is no such thing. The SQL developer license is an individual user license. Also a developer license may not be used on a production system.
    There are no bugs - only undocumented features.
  • ssinglassingla Member Posts: 2,973
    bbrown wrote:
    ssingla wrote:
    Thanks to all for helping and giving your suggestions/views.
    bbrown wrote:
    You must also consider the SQL cleint access licensing. Anyone accessing the SQL database, regardless of how they access it, must be licensed. If you cannot control the number of users (i.e exposing database to anoymous internet access) then you must license for unlimited users. This means processor licensing.

    Client has SQL developer processor based license so SQL license is not a problem.

    :?:

    There is no such thing. The SQL developer license is an individual user license. Also a developer license may not be used on a production system.

    My mistake :oops: They have both Enterprise as well as developer license.
    CA Sandeep Singla
    http://ssdynamics.co.in
  • kinekine Member Posts: 12,562
    One biggest question in the licensing is "who is named user?".

    Is it physical person?
    Is it one account in system?
    Is it someone who identifies himself in the system somehow (login)?

    Based on the answer you can license the access.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • bbrownbbrown Member Posts: 3,268
    A "named user" is defined as a created "named" login. It's the number of users accounts created in the system. "Named user" licensing usually does not allow for accout sharing. It expects each physical user to have their own unique login. You cannot circumvent licensing by having multiple users login with the same credentials. However a user could open multiple sessions and still be considered a single named user.
    There are no bugs - only undocumented features.
  • kinekine Member Posts: 12,562
    Yes, and this is the point. If I have 10 people, which are accessing one machine, which is logged in under one account each time, how many licenses I need?

    I know that MSFT assume 10 license, but it could be discussed and I think that there will be gray zone each time...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • jlandeenjlandeen Member Posts: 524
    Yeah I think this whole DCO/External licensing is a huge grey area. IMHO Microsoft is now trying to overly restrict a client's access to their own data that exists on their SQL servers that they have license too.

    Basically any external access to NAV data through web/SQL/any other means should be done under the extneral connector license (unless it is only a few external users and then named DCO Licenses are more cost effective). Any INTERNAL EMPLOYEES OR CONTRACTORS HAVE TO USE Named DCO Licenses or full client licenses.

    There has already been quite a lot of discussion here: http://www.mibuso.com/forum/viewtopic.php?f=32&t=30704.
    Jeff Landeen - Sr. Consultant
    Epimatic Corp.

    http://www.epimatic.com
  • ssinglassingla Member Posts: 2,973
    jlandeen wrote:
    Basically any external access to NAV data through web/SQL/any other means should be done under the extneral connector license (unless it is only a few external users and then named DCO Licenses are more cost effective). Any INTERNAL EMPLOYEES OR CONTRACTORS HAVE TO USE Named DCO Licenses or full client licenses

    Do contractors also need DCO license? I have never read something specific in the MS documentation.
    CA Sandeep Singla
    http://ssdynamics.co.in
  • jlandeenjlandeen Member Posts: 524
    Yes Contractors of a company are still considered "Internal" resources by the license agreement (at least according to the most recent DCO FAQ that was posted on Partner Source). So basically if the company retains them in anyway through a subcontract or empoyee relationship they will at bare minimum require a named DCO license to access NAV related data.
    Jeff Landeen - Sr. Consultant
    Epimatic Corp.

    http://www.epimatic.com
  • bbrownbbrown Member Posts: 3,268
    kine wrote:
    Yes, and this is the point. If I have 10 people, which are accessing one machine, which is logged in under one account each time, how many licenses I need?

    I know that MSFT assume 10 license, but it could be discussed and I think that there will be gray zone each time...

    From the SQL standpoint, you'd be better off with device CALs in this scenario. The one machine would require only 1 device CAL regardless of how many users shared it. In terms of the DCO, I think you're stuck with needing 10 licenses, but not sure.
    There are no bugs - only undocumented features.
  • kinekine Member Posts: 12,562
    bbrown wrote:
    kine wrote:
    Yes, and this is the point. If I have 10 people, which are accessing one machine, which is logged in under one account each time, how many licenses I need?

    I know that MSFT assume 10 license, but it could be discussed and I think that there will be gray zone each time...

    From the SQL standpoint, you'd be better off with device CALs in this scenario. The one machine would require only 1 device CAL regardless of how many users shared it. In terms of the DCO, I think you're stuck with needing 10 licenses, but not sure.

    But we are back on the question "who is "named user"" in this scenario... if it is the account or the physical person. I think that from MSFT point of view it is the physical person, but from another point of view it could be only the account I am using, because the account is what I can limit in access, somehow control, somehow count in the system etc...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
Sign In or Register to comment.