Your opinions on 5.1 preview

zeninoleg

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....

ara3n

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.

zeninoleg

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

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

DenSter

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.

zeninoleg

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
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.

kine

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)

zeninoleg

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 ...

kine

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...

DenSter

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_johnson

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!

Lars_Westman

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.

DenSter

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_Westman

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.

DenSter

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_Westman

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.

DenSter

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_Westman

I'm afraid someone else has to watch this at Convergence. I'm also not able to make it to Copenhagen.

Jason_Allor_[MSFT]

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.

Waldo

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).

jlandeen

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).

Waldo

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 ... .

Ilana_Smith_[MSFT]

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.

Darren_Laybourn

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.

navex

hi all,

could you please recommend, where can be found a stable build of NAV 5.1? thanks

Waldo

These are not yet available, I'm afraid.