I'm looking for pro and cons in webservices compared to NAS

ara3n

Sunset wrote:

Although we seem to be straying a bit of course from the original question; the discussion is at least an interesting one

There is no need in NAV to have the posting in consecutive numbers any longer. The old consistent check had some reasons for this, but as the new consistent only makes sure that debit and credit equals 0 for the posting routine you are currently in, the entry number is "reduced" to being a key. And as such there is no technical reason (at least to my knowledge) why a posting should have consecutive numbers.
For traceability it is a very nice feature, but as a technical reason it doesn't hold.

All I can say is: Wait and see what they will do with NAV 7.

Jens_M-P

I have followed this discussion with great interest and I have a follow-up question:

What features in version 7 of NST / WebServices would make your life easier if moving away from a NAS solution?

jreynolds

Jens M-P wrote:

What features in version 7 of NST / WebServices would make your life easier if moving away from a NAS solution?

1. Would like to be able to print reports from web services.
2. Performance is terrible under Windows Mobile; would like to see this improved.
3. Would like to be able to set flow filters with a page web service.

ara3n

1. Make authentication installation simpler (or remove kerebose delegation)
2. A new service that is active, and we can instantiate a single instance code unit or automation. it needs to be multi-threaded. it needs to be an active service or be activated by certain events.

Jens_M-P

Thank you for your input - it is highly appreciated (and will be taken into consideration).

rdebath

Jens M-P wrote:

I have followed this discussion with great interest and I have a follow-up question:

What features in version 7 of NST / WebServices would make your life easier if moving away from a NAS solution?

The thing that most disappointed me was the lack of true record variables, if you put a record as an argument in a codeunit trigger you have to pass a reference to a record in the database. This increases either the number of round trips to the webservice or the complexity of the codeunit because you end up using a bigtext argument and passing an XML inside an argument already encoded as XML by the webservice. (Or using an insane number of arguments)

The biggest irritation was the authentication and the fact that it's using an MS only variation of passwords; no standard password usage nor certificates.

And the thing that looks the most ugly is the way that an object is selected for showing on a web service. Sticking the object number in a table is just weird; why isn't it a property of the object!? If it was required authentication method and a per trigger "export to webservice" flag could be too.

That's my take on it.