Set object to run in server side

(0) Share

Report

Posted on by @rp@n

Dear All,

I write one class as per customer requirement which is used for Batch job. I want to run this class always in Server side. How to do this.

Please give me more shed on this.

Thanks!

Arpan Sen

*This post is locked for comments

I have the same question (0)

All responses (12)

Answers (0)

Suggested answer

Mea_ 60,284 on at

Like (0)

Report

Hi @rp@n,

By default all batch jobs are executed on the server using CIL, so you don't need to do anything special. However, if you would ever want to run them on client refer to this article technet.microsoft.com/.../aa551632.aspx

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

It is good practice to set the RunOn property on the Class to Server, to indicate that this is intended to run on server-side only.

Since batches are running in a thread within the AX AOS, you do not have to specifically define anything.

Also you could check run context on a batch header if it is executing in a batch process:

https://msdn.microsoft.com/en-us/library/batchheader.isexecutinginbatch.aspx

Was this reply helpful? Yes No
Mea_ 60,284 on at

Like (0)

Report

@Vilmos Kintera Why do you think that setting RunOn = Server on a class is a good practice ? This thread is about batch jobs, so I assume that RunBaseBatch framework is used under the hood. If we refer to "Inside Microsoft Dynamics AX 2012" book it says:

"To run the business operation job on the server and push the dialog box to the client, you should be aware of two settings. On the menu item that calls the job, set the RunOn property to Server; on the class, set the RunOn property to Called From."

And, as far as I remember, you will get some issues with RunBaseBatch classes with RunOn = Server because of dialog that should be obviously on client.

Was this reply helpful? Yes No
Martin Dráb 237,978 Most Valuable Professional on at

Like (0)

Report

To add a little bit more details, it's indeed wrong to set a RunBase class to always run on server. The frameworks needs two instances of the same class, one running on client (dealing with user input) and one running on server (doing the actual execution).

It's different with the business operation (SysOperation) framework, because processing is split to several classes (a controller, a UI builder, a class containing the operation to execute...). Therefore saying "this class" isn't enough in this context.

Was this reply helpful? Yes No
Brandon Wiese 17,788 on at

Like (0)

Report

It's fine to specify the class to run on the server for a RunBaseBatch class (as well as using the server keyword on the main method, and server on the launching menu item), even if it produces a dialog. The RunBaseBatch class will construct a server DialogRunbase object and transfer execution to the client using its own pack and unpack mechanism (even while your class remains only on the server). You can see this in class Dialog\doRun().

Was this reply helpful? Yes No
Martin Dráb 237,978 Most Valuable Professional on at

Like (0)

Report

No, it's not fine; Microsoft knew what they're talking about in the book.

The RunBase framework does have the pack and unpack mechanism, but if you don't allow the class to create instances on client, it won't be very useful. The serialization will still work, but it will be pointless, because both instances will run on server. The whole point of this client/server optimization is that one instance is on client and then the state is used in a server instance of the same class, but it can work only if the class can be constructed on both client and server.

Was this reply helpful? Yes No
Mea_ 60,284 on at

Like (0)

Report

@Brandon Wiese, Let's say it possible but not common. You can try to take any standard class with dialogPostRun() overridden where it is used to register overloaded method or 2009 style "dialog.dialogForm().formRun().controlMethodOverload(true);" and change RunOn to "Server". Most likely it would lead to stack trace on prompt. There is work around to use "dialog.dialogOnClient_RU()" but it was not in standard 2009 application (only in RU localization), so 99% of classes have this "issue".

Based on the above I won't call it neither "good practice" nor "fine" because we have common pattern (described in books and standard code) to set RunOn on menu Item only and I don't see any benefits from changing it, however, it could lead to some error, like described above and that's the only one 1 remember, so maybe there is more.

Was this reply helpful? Yes No
Martin Dráb 237,978 Most Valuable Professional on at

Like (0)

Report

Aha, you mean the dialog class only, but we're talking about the whole RunBase, such as that all RunBase methods called by the dialog executes on client without the penalty of cross-tier calls.

What you're talking about can make sure that implementing a RunBase class incorrectly doesn't have completely disastrous effects, which isn't the same thing as doing it right.

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (1)

Report

I would recommend to check tutorial_RunBaseBatch class from Microsoft, where the constructor is specifically setting server-side execution with the X++ keyword. The main method which is fired by opening it from the AOT or via a connected Action menu item is using the constructor of the class, so setting it on the caller menu item has no effect on where does the code execute.

If you follow the debugger, you may see this:

\Classes\WIK_RunBaseServerTest\main -> prompt()

...

\Classes\RunBase\promptPrim (line 14 fails on this.canSwapBetweenCSPrim if class is not set to RunOn = CalledFrom, however at a later stage we have a code fork anyway to check where the dialog is constructed, and variables are packed and passed on correctly) -> dialogMake()

...

\Classes\DialogRunBase\newOnServer

...

\Classes\Dialog\doRun -> Dialog::runOnClient

The last bit forces the Dialog form to execute on client-side, and pass on the packed variables between the execution states once the form is closed.

What I wanted to point out is that setting the property is not harmful, and this reply does answer the original post's question on how does he enforce server-only execution for a batch process.

I stand corrected though that setting RunOn to be Server is not a general good practice for batches, which should be CalledFrom for everyday cases.

Was this reply helpful? Yes No
Martin Dráb 237,978 Most Valuable Professional on at

Like (0)

Report

Yes, it's unfortunate that quite a few tutorial objects (most of them were already in Axapta 3.0; they may be even older) and samples on MSDN aren't implemented according to best practices.

Was this reply helpful? Yes No