Your opinions on 5.1 preview

zeninolegzeninoleg Posts: 236Member
edited 2008-02-19 in NAV Three Tier
I have watched the preview:
http://www.mibuso.com/dlinfo.asp?FileID=873
It is nice. Very nice. However.....
I did not see anything related to the security and permissions, would you be able to give access to the certain fields/tabs to the users?
Web Services are great too, but i think they will create so much more headackes for us.... I have seen so many companies asking for API "because they do not want to learn Navision but they have to integrate their addon/solution with it". Makes me sad. I think taht Microsoft is opening the door for the whole bunch of .Net developers (and companies) who do not know or do not want to learn NAV but will be creating their solutions for it. Originally Navision was a functional system with mainly functional upgrades, but now Microsoft is making move to the technical side to the technicak upgrades. I cannot say if it is good or bad, but NAV will never be same anymore.
To add more, one of the strongest points of NAV was stability due to relative simplicity, now Microsoft is changing backside, I am afraid all this will make NAV less stable....
Best Regards,
Oleg

Comments

  • ara3nara3n Posts: 9,232Member
    On the stability issue, they have postponed the release for another quarter, so I'm sure they are working on making at stable as the navision client.

    On navision changing, yes it is changing, MS bought the 4 ERP systems, so they all will have to change to into one ERP system. Change is inevitable.


    On .NET users not learning navision. As long has NAV business log is run, you don't have to worry about data being corrupted.

    If I were a .NET developer, I wouldn't learn an ERP system that will morph into something else in 2-5 years.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • zeninolegzeninoleg Posts: 236Member
    On .NET users not learning navision. As long has NAV business log is run, you don't have to worry about data being corrupted.
    You are right taht Navision data will not be corrupted but the result in the NAV will not be same as they have expected, then we will hear complaints that NAv does not work and so on.
    On the stability issue, they have postponed the release for another quarter, so I'm sure they are working on making at stable as the navision client.
    I hope so but still highly doubt that it will be as stable as old NAV because of all these additional stuff(API, Report Designers, new generation of reports, etc). Microsoft has a history of trying to create an application taht will suite every need and will work everywhere and it is not always a happy experience :wink:


    If I were a .NET developer, I wouldn't learn an ERP system that will morph into something else in 2-5 years.
    Business Logic stays same not matter of the look. And in ERP system bus logic is much more important then all these bells and whistles. All software is changing very rapidly and eventually will morph into something else :D
    Best Regards,
    Oleg
  • DenSterDenSter Posts: 8,127Member
    I am very excited about all the prospects. I think it is very cool that we can finally expose NAV business logic in an industry standard way. Finally we have a connection to industry standard reporting, and a more open way to expose information out of the system. Think of all the possibilities!!

    If that means that there will be many .NET developers messing up the system then that means more work for NAV people. What I am hoping for though is that those .NET developers will have the common sense to involve NAV expertise. I've met quite a few of them, and believe me, people in that world are MUCH more willing to share information and work together than the NAV world. It is going to be exciting times :mrgreen:.

    Personally I'm not too worried about what all can go wrong because of other people screwing up, I am looking at all opportunities for myself and my customers. There may be things missing, or things that could have been better/different, but the fact remains that there will be MANY MANY new things that we can do to improve life for our customers, and that is what I think counts.
  • zeninolegzeninoleg Posts: 236Member
    Good point Denster,
    I agree with you that things are going to change and mostly they will be better. We will have so many new opportunities and possibilities! But everything that i am
    hoping for though is that those .NET developers will have the common sense to involve NAV expertise
    . I would like to see more successful projects and more interesting projects. And yes, it will be more work for us which is a good thing :wink:
    I guess i am more an idealist and want everything to work out nicely but changes are necessary and will be appreciated by the market even if we will be getting bugs in the first time.
    Best Regards,
    Oleg
  • kinekine Posts: 12,562Member
    And do not forget, that you as NAV developer have the WebServices interface in hand, not the .NET developer. It is on YOU what you will expose and in which way. It is on YOU to create simple interface and do waht you need in way you need inside the NAV. Let .NET developer just send the data you need and it is on NAV what you will doo with that data. 8)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • zeninolegzeninoleg Posts: 236Member
    Sorry for not replying for a week - it was so nice to leave laptop at home and escape for a week for vacation. 8)
    Let .NET developer just send the data you need and it is on NAV what you will doo with that data
    That will be the ideal scenario, but i was talking about the companies who have, say, some existing system(addon) that they want to connect to Navision "because one of our clients want to use NAV for accounting" and they do not involve me or any other NAV specialist "because you charge too much and we can figure it out ourselves, just give us API". That is when the customer can get lousy solution ...
    Best Regards,
    Oleg
  • kinekine Posts: 12,562Member
    But there is no "standard" API to the NAV. Someone must say what will be published as WebService and it means someone must be responsible for that. And if you are resposible for NAV for your customer, another company cannot do some changes in NAV, publish some functionality etc. and not be responsible for the result... it is just about responsibility...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • DenSterDenSter Posts: 8,127Member
    zeninoleg wrote:
    That is when the customer can get lousy solution ...
    When a company wants to integrate application A and application B, and they decide not to involve an expert for both applications, they make a bad decision, and it only takes time for them to realize that. Most companies do not make decisions that bad. The ones that do usually at some point in time realize they need experts on both sides anyway, and end up spending twice the money on fixing the problems.
  • chris_johnsonchris_johnson Posts: 22Member
    In my personal opinion it looks nice and I can see a lot of work coming my way thanks to it. It looks like there is plenty of opportunity to create some really good solutions (and equally some really bad ones :D ) both inside and outside of the Navision client.

    I especially like the opportunity to present Navision data in SharePoint and hope this will be made as easy as possible (I can see quite a few requests for this coming my way).

    On the whole, looking forward to playing with it in the flesh!
  • Lars_WestmanLars_Westman Posts: 116Member
    I'm also quite exited about the new service tier, but i'm worried about the performance of the new client.

    I don't understand why the new client should communicate with the service-tier using web serives. Web services are not known to be fast. There are more efficiant ways to achieve remoting.

    Web Services is excellent for communicating throughout the firewalls beyond the intranet and inside the intranet with other applications/interfaces. But inside the intranet and with the proprietary client there should be more efficient ways to communicate instead of using plain text format and web services.

    One reason for using web services also with the new client could be that MS otherwise couldn't use the same client for AX, GP and SL, but i'm still worried about the performance.
  • DenSterDenSter Posts: 8,127Member
    laweume wrote:
    I don't understand why the new client should communicate with the service-tier using web serives.
    Where did you get that information?
  • Lars_WestmanLars_Westman Posts: 116Member
    DenSter wrote:
    Where did you get that information?

    Have You ever heard anything else? MS says NAV will ship with approx 1500 web services and why should they if it's not for the new client.

    Also this i cut from the statement of direction : "The middle tier, the Service Tier will be used to service the clients and to enable web services to external or third-party applications. Microsoft Dynamics NAV 5.1 is built entirely on Microsoft .NET."

    Since the application will be compiled and converted into managed .Net and be run on IIS what other technique can be used but web services to communicate with the client?

    I would feel more confortable if the new client used something else then web services from a performance perspective but i dont think that's the case. Just look at the way map Point, outlook and all the other cool stuff can be put into the client. That is done through web services just as the NAV pages will be.
  • DenSterDenSter Posts: 8,127Member
    laweume wrote:
    Have You ever heard anything else? MS says NAV will ship with approx 1500 web services and why should they if it's not for the new client.

    Since the application will be compiled and converted into managed .Net and be run on IIS what other technique can be used but web services to communicate with the client?
    Ah so it's an assumption on your part. Just wanted to make sure. There is so much information floating around, that I just want to make sure how people get their information and what it's based on.
    "The middle tier, the Service Tier will be used to service the clients and to enable web services to external or third-party applications. Microsoft Dynamics NAV 5.1 is built entirely on Microsoft .NET."
    To me this means 'we will have a service tier and it will do two things (among possibly others): 1-service the clients and 2-enable webservices'

    I don't necessarily agree that the two are the same mechanism. ".NET" is not equal to "webservices".
  • Lars_WestmanLars_Westman Posts: 116Member
    DenSter wrote:
    To me this means 'we will have a service tier and it will do two things (among possibly others): 1-service the clients and 2-enable webservices'

    I don't necessarily agree that the two are the same mechanism. ".NET" is not equal to "webservices".

    Let's hope so. It would be nice if it was possible to get some clarification on this at convergence.
  • DenSterDenSter Posts: 8,127Member
    Keep us posted if you get a clear answer (unfortunately I can't make it to Convergence). It is a good question, and if your assumption is right it could explain some things.
  • Lars_WestmanLars_Westman Posts: 116Member
    I'm afraid someone else has to watch this at Convergence. I'm also not able to make it to Copenhagen.
  • Jason_Allor_[MSFT]Jason_Allor_[MSFT] Posts: 5Member, Microsoft Employee
    Have You ever heard anything else? MS says NAV will ship with approx 1500 web services and why should they if it's not for the new client.

    The new Role Tailored client does not use the new Web Services feature for communication with the service tier. Web Services are exposed for integration with external components.

    Hope that clarifies it.

    Thanks.
    This posting is provided "AS IS" with no warranties, and confers no rights.”
  • WaldoWaldo Posts: 3,412Member
    I think there is a misunderstanding involved.
    As 6.0 ships with Webservices functionality, and you can expose pages and codeunits by a simple "click", you can expose many webservices out-of-the-box. But that doesn't mean that this is the way that the client connects to the service tier (this is definitally not the case).

    Eric Wauters
    MVP - Microsoft Dynamics NAV
    My blog
  • jlandeenjlandeen Posts: 524Member
    On the webservice front. I'm still not 100% clear on how scaleable that interface is going to be. One of the standard interfaces patterns that's been published in various white papers is to use MSMQ to broker messages back & forth to Navision - it is this layer that essentially serializes these messages.

    Does anyone here or @ MS know if the webservice interfaces that come out of the box with Pages (and codeunits linked to pages) will be scaleable to handle a large volume of synchronous calls to them?

    Also does anyone know if the standard interfaces exposed by pages can be modified or restricted? I know we could add functionality through codeunits...but can we restrict default functionality if needed? (i.e. don't allow inserts or deletes, but do allow finds).
    Jeff Landeen - Sr. Consultant
    Epimatic Corp.

    http://www.epimatic.com
  • WaldoWaldo Posts: 3,412Member
    I don't know practically, because I didn't have the chance to lay my hands on it. You have to wait for a MS answer ... .

    But theoretically I can say this:
    - Webservices should be multi threaded
    - Webservices uses Windows Authentication - and therefore the standard security within NAV
    - You should be able to install two service tiers

    This is what I made up from various conferences :| . Hope I'm not making something up here ... :wink:.

    Eric Wauters
    MVP - Microsoft Dynamics NAV
    My blog
  • Ilana_Smith_[MSFT]Ilana_Smith_[MSFT] Posts: 5Member, Microsoft Employee
    We can't really comment on perf/scaleability at this point - lots more work to do there before we ship, so we're not sure what it's going to look like. Eric is right though - you can scale out with more NSTs if necessary.

    At this point, we're not planning to allow restricting the page service. The crux of our approach is to keep security/functionality the same between the page through UI and through a web service. If you want different functionality/security, you'd need to create and use a different page.
    --
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Darren_LaybournDarren_Laybourn Posts: 4Member, Microsoft Employee
    Also wanted to add that the communication between the client and the server is based on WCF (Windows Communication Foundation). We are using WCF so that we can take advantage of the higher performing protocals that it supports between the client and the serer.

    Also, when we release the server will not be hosted in IIS. The server is built using some additional components that come as part of WCF as well.

    Performance is a critical concern for us and has Ilana stated we are working hard on on it all the time.
    Darren Laybourn
    General Manager Dynamics R&D
  • navexnavex Posts: 16Member
    hi all,

    could you please recommend, where can be found a stable build of NAV 5.1? thanks
  • WaldoWaldo Posts: 3,412Member
    These are not yet available, I'm afraid.

    Eric Wauters
    MVP - Microsoft Dynamics NAV
    My blog
Sign In or Register to comment.