5.1 and single instance codeunit

NavStudent

Hello
Will the single instance codeunit run on service tier or client tier?
Can you run it from a webservice?

Waldo

I don't think anyone is going to be able to answer this one ... .

What specific functionality needs this?

p.willemse6

able or allowed to

kine

1) Client or service tier - by definition of 3-tier it will run on service (mid) tier. Client tier is just presentation layer. But if it will be shared with other sessions on service-tier or not, it is a question...
2) WebService and singleinstance - who knows...

Waldo

p.willemse6 wrote:

able or allowed to

"able" 8)

Michael_Nielsen_[MSFT]

1) Kine is right - It will run on the server (service tier)
2) Single instance code units will keep their state on the server = yes you can

NavStudent

gulp.

That means you can run a second service tier just for NAS or just for ADCS.

Michael_Nielsen_[MSFT]

The new server has nothing to do with the current NAS. It is rewritten from scratch in managed code using .net datatypes and it is truely multithreaded (NAS is not). This means that the server can handle many concurrent request at at time and you only need to add more servers if you run into scalability problems.

NavStudent

what I meant by NAS was to be able to run Job Queue on service tier.
Currently Job queue runs on NAS. So instead it could run on service tier.

Marije_Brummel

This is actually a very good question. You should be able to activate codeunit 448 [Job Queue Dispacher] as a webservice.

Let me try to find (another, no offence Michael ) ms employee who has been involved in webservices to answer this question ok?

PS. Michael, as I said to you this week, thank you for your contribution. It is very cool to see you active on the forum =D>

Michael_Nielsen_[MSFT]

Yes you are right Mark

I dont know the answer:) - but I need it anyway for a partner presentation Thursday next week. I or another MS person will answer sometime next week

Kris_Rafnsson

This thread has 2 questions that I believe I should answer.

Can you run single-instance codeunit from a web service?
The answer to that is, I’m sorry to say, little complicated.
You can call methods of single instance codeunits, but!
Single-instance codeunits are only single instance per session, this mean that each login will get its own instance of the codeunit.
You cannot predict the session lifetime in a web service call. This will render the single instance feature of the object practically useless, as you don’t know if the object has been garbage collected sins you called last time.

I consider this to be right behavior for Web Services. The idea is to be stateless on the middle tire. But I also realize that this will require some amount of rethinking of some existing application features, but at the end of the day I believe it to be better this way. Feedback is welcome on this point.

About “Job Queue Dispacher”.

There are 3 things about that object that I would like to point out that makes that object unsuited for web service as it is written.
1.) It has method signatures that cannot be published as a web service; remember that the only types available to you on the codeunit if you intend to publish it as a service: are the simple types (text, int…) and XMLPorts.
2.) The codeunit uses the OnRun trigger to startup. Web Services subsystem does not call that trigger nor allows that trigger to be exposed as a service. Workaround for that is to add a method that calls that trigger and then call that method from the web service client.
3.) The codeunit seems to have requirements for predictable lifetime (see the session talk above).
it is possible to get a web service that does this feature but it needs to be re designed.

Thanks
Kris

NavStudent

thank you. That was very clear. I have one more question about this.

Based on MS documents, Microsoft will only support 2 tier or 3 tier.

So if a client chooses to go with 3 tier, and they use Job Queue. The job queue needs to be changed as you mentioned. So is the NSC going to make the change in order for it to work in 3 tier solution or MS will do this before releasing the product?

The NASHandler Function in CU 1 has so many other integration related codeunits, will they have to be redisigned as well? Or you won't support them in 3 tierd solution?

Marije_Brummel

Thanks Kris,

Looking forward to see how it will end up working in 6.0.

See you at Directions. \:D/

Luc, can you give Kris the MFST avatar?

Luc_VanDyck

Mark Brummel wrote:

Luc, can you give Kris the MFST avatar?

Done!

Nice to see some people involved in the development of the Dynamics NAV product at Vedbaek are joining this community. =D>
I'm sure all forum members will appreciate their contributions to the threads!

Waldo

NavStudent wrote:

thank you. That was very clear. I have one more question about this.

Based on MS documents, Microsoft will only support 2 tier or 3 tier.

So if a client chooses to go with 3 tier, and they use Job Queue. The job queue needs to be changed as you mentioned. So is the NSC going to make the change in order for it to work in 3 tier solution or MS will do this before releasing the product?

The NASHandler Function in CU 1 has so many other integration related codeunits, will they have to be redisigned as well? Or you won't support them in 3 tierd solution?

That is a good question.

Will NAS be considered as being part of the the 3 tiered solution as well. Theoretically, it isn't, because it connects to the DB, not the service tier.

Furthermore I only see three things to execute business logic: Client, NAS and Web Service, with that latest having as disadvantage of the non-predictable lifetime.

Now, if not supported, you could think of some very simple solutions like creating webservices of your codeunits that you would like to handle by job queue and call those on regular basis (scheduled task, custom .net app, ...).

My guess is that the NAS will still be supported, allthough it's not part of the (full) 3 tier solutions but I'd like to have MS view on this as well... .

kine

Kris Rafnsson wrote:

Can you run single-instance codeunit from a web service?
The answer to that is, I’m sorry to say, little complicated.
You can call methods of single instance codeunits, but!
Single-instance codeunits are only single instance per session, this mean that each login will get its own instance of the codeunit.
You cannot predict the session lifetime in a web service call. This will render the single instance feature of the object practically useless, as you don’t know if the object has been garbage collected sins you called last time.

I consider this to be right behavior for Web Services. The idea is to be stateless on the middle tire. But I also realize that this will require some amount of rethinking of some existing application features, but at the end of the day I believe it to be better this way. Feedback is welcome on this point.

Because you can use tables as your state storage, you can redesign some parts of the application this way. Of course, for complex things it is not so easy. In this way you can do something like "mid-tier wise singleinstance codeunit" if there is clear point of "constructing" the codeunit ("first call") when the codeunit can read the state of variables from table and you have some way how to "pass" the changes of the variables from one session into another (solution can be reading the variable each time you need it from table and after change write it back into table). But it means big overhead to keep all sessions instances of the codeunit synchronized (it means to have some safe signalling mechanism like semaphore to prevent two instances to change same value in same time, which now in NAS is not possible because it is serial execution). It means, all is possible, but base is to have the mechanism for serializing some parts of the process (but e.g. locking can be used for that in some limited way).

Another way: do you thing that it will be possible to have some mechanism in mid-tier to run some codeunit as separate session without the automatic garbage collector, something like "service session"? Just some mechanism which will keep the session running without any external mechanism to do that?

Waldo

kine wrote:

Another way: do you thing that it will be possible to have some mechanism in mid-tier to run some codeunit as separate session without the automatic garbage collector, something like "service session"? Just some mechanism which will keep the session running without any external mechanism to do that?

You mean using whatever is published on the IIS without the webservices ... . As it's all managed code on IIS ... what is wrong of using the NAS to connect to the database instead of IIS?

DenSter

I thought that was what it would be. NAS is a regular NAV client session without a user interface. The NAS session will run on a server instead of a client machine, and will use the service tier for whatever would run there from the client session.

Waldo

NAS is classic client without UI ... so it will not be able to use the service tier ... .

kine

I suggested the separate session to prevent using "mixed" technology (NAS + service-tier). It is true that may be it is hard or impossible to do that on IIS. I am not expert in programming for IIS 8) (right now...).

If something like NAS is not existing, it means just web-services can be used. But this is not possible in all cases. But yes, everything can be done in another way, but in most cases in more expansive way. NAS was easy for use and thus cheap solution. Now it leads to something like Biztalk etc. and it is not so cheap (license cost and knowledge). E.g. solution reading periodically some files from predefined folder will be very hard to realize, today it is easy.

I know that each new technology have own ways how to do things and things which cannot be done. It is just about going through all possibilities and if there is some easy way how to do things like NAS, than add this way.

But may be I am just blind and I don't see the ways.

Waldo

My answer was a bit short because I was using my phone ... .

What I meant is just that we need to be able to execute business logic. If NAS is not an option anymore (because of direct connection with DB), then I only see webservices as an option ... .

You are right that in that case, some solution "in the middle" should be provided ... . noone heard anything like this until now, so I'm afraid there is no extra service that runs on the middle tier... .

All code on the middle tier is managed ... compiled from the C/SIDE database ... so C/SIDE runs the same as middle tier (theoretically). That's why I don't see why NAS wouldn't be supported - no redesign of the functionalities is needed in that case.

Anyway ... I'd like to see Microsoft's opinion on this

DenSter

Waldo wrote:

NAS is classic client without UI ... so it will not be able to use the service tier ... .

So now:
C/SIDE client = UI + business logic
NAS = business logic + UI-less 'client'

I assumed the new 3 tiers would be:
New Client = Presentation layer + Service tier
New NAS = Service tier + UI-less 'client'

The new client will have a presentation layer and will use the service tier for executing the logic. My assumption was that NAS will still exist, similar to today: running the business logic, which by definition lives on the service tier, executed without the presentation layer. Because the way that these two communicate we'd still have NAS on the 3 tiers.

I never considered that NAS would not exist on the 3 tier architecture.

Waldo

Everything is possible at the moment... .

Michael_Nielsen_[MSFT]

Let me give it a try:

NAS = C/AL Business logic + Classic Client(single threaded) - UI
New Service tier = C/AL business logic converted into C# and then compiled to IL + C/SIDE function library rewritten in managed code (Multit hreaded)

But both run the same business logic against the same database and will be able to coexist

DenSter

In other words, NAS will not use the service tier?

kine

But both run the same business logic against the same database and will be able to coexist

Happy to hear that. I hope that it will be still true when 6.0 will be released... ;-)

Some "math" for me:

if NAS = C/AL Business logic + Classic Client(single threaded) - UI
than
Classic Client = NAS + C/AL Business logic + UI

and if NAS can coexists with mid-tier, Classic client can coexists with mid-tier too. 8) Am I right or not? :whistle:

I will be just happy if yes...

Waldo

Ah, thanks Michael. It's like I expected it to be - luckily, because the existing functionality like Job Queue can exist without changes. =D>

Waldo

kine wrote:

and if NAS can coexists with mid-tier, Classic client can coexists with mid-tier too. 8) Am I right or not? :whistle:

I wouldn't know why ... as long as you're using SQL Server, this should be possible

Michael_Nielsen_[MSFT]

The ambition from day one has been that business logic run on the current stack produce exactly the same result if run on the new stack.

However, when I wrote the C/AL compiler and runtime many year ago I also (by mistake and trying to look smart) introduced a number of side effects. These side effects has since then been used by many C/AL Developers to make the language do things it was not meant to do in the first place – but made a number of cool features possible and made many customers excited and happy. Some of these side effect cannot be converted to .net without knowing the context of the constructs’ and will not be automatic converted to C# = not able to run unmodified on the new service tier.

We have a session at Directions next week where Kim (and I will) go through some examples of bad coding and design (that used to be ok coding and design)

NavStudent

I hope there will be some document available for people who are not going to be at Directions.

Thank you for the information.

Now if somebody responds to partial index creation I mentioned here, that it would be usefull, it would definetly help performance. O:)

http://www.mibuso.com/forum/viewtopic.php?t=21740&highlight=