Your opinions on 5.1 preview

zeninoleg
Member Posts: 236
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....
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
Oleg
0
Comments
-
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.0 -
On .NET users not learning navision. As long has NAV business log is run, you don't have to worry about data being corrupted.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.If I were a .NET developer, I wouldn't learn an ERP system that will morph into something else in 2-5 years.Best Regards,
Oleg0 -
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.
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.0 -
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 amhoping for though is that those .NET developers will have the common sense to involve NAV expertise
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,
Oleg0 -
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)0
-
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 dataBest Regards,
Oleg0 -
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...0
-
zeninoleg wrote:That is when the customer can get lousy solution ...0
-
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
) 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!0 -
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.Lars Westman
http://www.linkedin.com/in/larswestman0 -
laweume wrote:I don't understand why the new client should communicate with the service-tier using web serives.0
-
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.Lars Westman
http://www.linkedin.com/in/larswestman0 -
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?"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."
I don't necessarily agree that the two are the same mechanism. ".NET" is not equal to "webservices".0 -
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.Lars Westman
http://www.linkedin.com/in/larswestman0 -
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.0
-
I'm afraid someone else has to watch this at Convergence. I'm also not able to make it to Copenhagen.Lars Westman
http://www.linkedin.com/in/larswestman0 -
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.”0 -
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).0 -
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).0 -
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 ...
.
0 -
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.0 -
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&D0 -
hi all,
could you please recommend, where can be found a stable build of NAV 5.1? thanks0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions