Re: Question about Execute on Server under 4D v15

[Robert McKeever via 4D_Tech]

Thanks, Kirk.

> On Mar 6, 2018, at 10:24 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Robert,
> John's suggestion about a worker process is a good one. It sounds like
> you're just starting into this area so I'll throw out out a few things that
> aren't readily apparent.
> 
> I use Execute on server (EOS) methods a lot. When a method is EOS it runs
> on the server but in the 'twin' process of the one on the client. Let's say
> I've opened an order in a new process named 'order_1234'. I have the actual
> record open and locked on my client machine. That is, it's locked by the
> client process.
> 
> Now I call a method to lookup some stuff. Since it's a big lookup (or like
> me you are running over TCP/IP between the server and client) I use an EOS
> method. That method runs on the server in the process named 'order_1234'
> but the server side of the process, the 'twin', doesn't share the context
> of the client side. So there is no current order record on the server yet,
> for example. And if I try to load the order record on the server it will be
> locked because it's already open on the client side.
> 
> This can be useful. Let's say I've got some Order Lines in a related table.
> On the client side I probably have a current selection of them in a listbox
> or subform. On the server side I could do a search on that table, create a
> completely different current selection yet not disrupt the current
> selection on the client.
> 
> This can also create problems. If I forget to explicitly set the server
> side process to READ ONLY(*) before using it then I can lock a record in
> that process. The LOCKED ATTRIBUTE will only tell me it's locked by the
> 'order_1234' process - not WHICH VERSION of the process has it locked. That
> one stumped me for a while in one case. I just could not find where a
> record in a table was getting locked especially since I called READ ONLY(*)
> when the process started. Eventually I realized the situation was resulting
> from an EOS method that did a query and left the selection with the record
> locked. Grrr. So now the method that runs when I create a new method calls
> an little EOS method which sets all tables to READ ONLY.
> 
> The other type of server side process is what we call a stored method. This
> is initiated from the client by Execute on server or by simply creating a
> new process on the server itself. When you do this these processes exist
> only on the server and are conceptually similar to a Worker process.
> Workers have the cool feature of their own messaging system however. But
> simple server side processes are useful as well.
> 
> I use them for doing things like aggregating information that may be
> displayed on various client side forms or dashboards. I just finished work
> on a 'sales scoreboard' feature. A stored method periodically (every 5
> minutes) builds a set of summary arrays of sales data folks are interested
> in. I stuff them into an IP c-obj on the server. I use this same c-obj for
> a number of operations like this.
> 
> The cool benefit of server side IP vars, and especially c-objects in my
> view, is that any client can access that data with a simple EOS function.
> This DOES NOT use Get Process Variable which can be problematic. You don't
> need to. Here's the method that gets the sales data:
> 
>  //  Score_get_data **EOS**
>  // Written by: Kirk as Designer, Created: 03/06/18, 08:50:48
>  // --
>  // Method: Score_get_data (ptr)
>  // $1 is ptr to c-obj
>  // Purpose: get the data object from the server
> C_POINTER($1)
> C_OBJECT($obj)
> 
> $obj:=OB_New
> $obj:=OBJ_get_obj (<>appObject;"scoreData")
> $1->:=$obj
> 
> 
> I add the **EOS**  to the headers of methods to make it easy to remember
> which ones are. Otherwise you have to look at the properties.
> 
> This is called from the form on the client. I don't need to worry about
> locking the IP var because I'm only reading it. You can also use this to
> write to the server side variable but this gets more complicated if you
> actually use it. So I stick to reading from the server side only.
> 
> I pass a pointer to a local object var. This is a pretty handy way to let
> your server manage this sort of operation without having to add the
> overhead of a messaging table where the server process writes data to a
> table and the client side reads from the table. I did it that way before
> but this is just easier.
> 
> Just some ideas. The best thing to do is start up a server and just play
> with it. This all gets a lot clearer when you can actually see it work, I
> think.
> 
> 
> On Mon, Mar 5, 2018 at 8:00 PM, Robert McKeever via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
> 
>> I have two processes, one foreground, the other background (runs
>> continually with appropriate pause/resume). There are a few dialogs that
>> exist in the background process that can be eliminated. Since it does a lot
>> of information gathering before creating/deleting a re

Re: Question about Execute on Server under 4D v15

[Kirk Brooks via 4D_Tech]

Robert,
John's suggestion about a worker process is a good one. It sounds like
you're just starting into this area so I'll throw out out a few things that
aren't readily apparent.

I use Execute on server (EOS) methods a lot. When a method is EOS it runs
on the server but in the 'twin' process of the one on the client. Let's say
I've opened an order in a new process named 'order_1234'. I have the actual
record open and locked on my client machine. That is, it's locked by the
client process.

Now I call a method to lookup some stuff. Since it's a big lookup (or like
me you are running over TCP/IP between the server and client) I use an EOS
method. That method runs on the server in the process named 'order_1234'
but the server side of the process, the 'twin', doesn't share the context
of the client side. So there is no current order record on the server yet,
for example. And if I try to load the order record on the server it will be
locked because it's already open on the client side.

This can be useful. Let's say I've got some Order Lines in a related table.
On the client side I probably have a current selection of them in a listbox
or subform. On the server side I could do a search on that table, create a
completely different current selection yet not disrupt the current
selection on the client.

This can also create problems. If I forget to explicitly set the server
side process to READ ONLY(*) before using it then I can lock a record in
that process. The LOCKED ATTRIBUTE will only tell me it's locked by the
'order_1234' process - not WHICH VERSION of the process has it locked. That
one stumped me for a while in one case. I just could not find where a
record in a table was getting locked especially since I called READ ONLY(*)
when the process started. Eventually I realized the situation was resulting
from an EOS method that did a query and left the selection with the record
locked. Grrr. So now the method that runs when I create a new method calls
an little EOS method which sets all tables to READ ONLY.

The other type of server side process is what we call a stored method. This
is initiated from the client by Execute on server or by simply creating a
new process on the server itself. When you do this these processes exist
only on the server and are conceptually similar to a Worker process.
Workers have the cool feature of their own messaging system however. But
simple server side processes are useful as well.

I use them for doing things like aggregating information that may be
displayed on various client side forms or dashboards. I just finished work
on a 'sales scoreboard' feature. A stored method periodically (every 5
minutes) builds a set of summary arrays of sales data folks are interested
in. I stuff them into an IP c-obj on the server. I use this same c-obj for
a number of operations like this.

The cool benefit of server side IP vars, and especially c-objects in my
view, is that any client can access that data with a simple EOS function.
This DOES NOT use Get Process Variable which can be problematic. You don't
need to. Here's the method that gets the sales data:

  //  Score_get_data **EOS**
  // Written by: Kirk as Designer, Created: 03/06/18, 08:50:48
  // --
  // Method: Score_get_data (ptr)
  // $1 is ptr to c-obj
  // Purpose: get the data object from the server
C_POINTER($1)
C_OBJECT($obj)

$obj:=OB_New
$obj:=OBJ_get_obj (<>appObject;"scoreData")
$1->:=$obj


I add the **EOS**  to the headers of methods to make it easy to remember
which ones are. Otherwise you have to look at the properties.

This is called from the form on the client. I don't need to worry about
locking the IP var because I'm only reading it. You can also use this to
write to the server side variable but this gets more complicated if you
actually use it. So I stick to reading from the server side only.

I pass a pointer to a local object var. This is a pretty handy way to let
your server manage this sort of operation without having to add the
overhead of a messaging table where the server process writes data to a
table and the client side reads from the table. I did it that way before
but this is just easier.

Just some ideas. The best thing to do is start up a server and just play
with it. This all gets a lot clearer when you can actually see it work, I
think.


On Mon, Mar 5, 2018 at 8:00 PM, Robert McKeever via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> I have two processes, one foreground, the other background (runs
> continually with appropriate pause/resume). There are a few dialogs that
> exist in the background process that can be eliminated. Since it does a lot
> of information gathering before creating/deleting a record and updating
> another, I’d like to move it so it executes on the server. It see that it
> creates a new process on the server.
>
> 1. Is that a unique process for each user, or only one process for all
> users?
>
> 2. Are the local variables in use on the ‘client’ the save as whe

Re: Question about Execute on Server under 4D v15

[Robert McKeever via 4D_Tech]

Many thanks, John.

> On Mar 5, 2018, at 10:00 PM, John Baughman via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> If you are working in v15 R5 or better, I would recommend that you take a 
> close look at Worker processes. No need for pause/resume and calls are 
> managed automatically by the worker on a first in first out basis. With a 
> worker on the server, you would still use execute on server but only to call 
> the worker and pass parameters.
> 
> Whether you use a Worker process on the server or a process created with 
> Execute on Server no variables are shared with the client. You could use 
> records to exchange data, but it is much cleaner and easier to just pass the 
> data in Execute on Server/Execute Client parameters. If you are working in 
> v14 or better, c_object is the perfect vehicle for this. Just pack all the 
> variables or data into a single c_object.
> 
> My 2 cents.
> 
> John
> 
>> On Mar 5, 2018, at 6:00 PM, Robert McKeever via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> I have two processes, one foreground, the other background (runs continually 
>> with appropriate pause/resume). There are a few dialogs that exist in the 
>> background process that can be eliminated. Since it does a lot of 
>> information gathering before creating/deleting a record and updating 
>> another, I’d like to move it so it executes on the server. It see that it 
>> creates a new process on the server. 
>> 
>> 1. Is that a unique process for each user, or only one process for all users?
>> 
>> 2. Are the local variables in use on the ‘client’ the save as when you use 
>> ‘Execute on Server’? e.g., if I start the process on the server, does it 
>> share variables with the client or must they be exchanged via a record in a 
>> table?
>> 
>> _
>> Bob McKeever  http://www.mswl.com 
>> McKeever's Software Wizardry
>> Port Coquitlam, B.C.
>> bobmckee...@mac.com
>> 
>> 
>> 
>> 
>> **
>> 4D Internet Users Group (4D iNUG)
>> FAQ:  http://lists.4d.com/faqnug.html
>> Archive:  http://lists.4d.com/archives.html
>> Options: https://lists.4d.com/mailman/options/4d_tech
>> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
>> **
> 
> John Baughman
> Kailua, Hawaii
> (808) 262-0328
> john...@hawaii.rr.com
> 
> 
> 
> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

_
Bob McKeever  http://www.mswl.com 
McKeever's Software Wizardry
Port Coquitlam, B.C.
bobmckee...@mac.com




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Question about Execute on Server under 4D v15

[John Baughman via 4D_Tech]

If you are working in v15 R5 or better, I would recommend that you take a close 
look at Worker processes. No need for pause/resume and calls are managed 
automatically by the worker on a first in first out basis. With a worker on the 
server, you would still use execute on server but only to call the worker and 
pass parameters.

Whether you use a Worker process on the server or a process created with 
Execute on Server no variables are shared with the client. You could use 
records to exchange data, but it is much cleaner and easier to just pass the 
data in Execute on Server/Execute Client parameters. If you are working in v14 
or better, c_object is the perfect vehicle for this. Just pack all the 
variables or data into a single c_object.

My 2 cents.

John

> On Mar 5, 2018, at 6:00 PM, Robert McKeever via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> I have two processes, one foreground, the other background (runs continually 
> with appropriate pause/resume). There are a few dialogs that exist in the 
> background process that can be eliminated. Since it does a lot of information 
> gathering before creating/deleting a record and updating another, I’d like to 
> move it so it executes on the server. It see that it creates a new process on 
> the server. 
> 
> 1. Is that a unique process for each user, or only one process for all users?
> 
> 2. Are the local variables in use on the ‘client’ the save as when you use 
> ‘Execute on Server’? e.g., if I start the process on the server, does it 
> share variables with the client or must they be exchanged via a record in a 
> table?
> 
> _
> Bob McKeever  http://www.mswl.com 
> McKeever's Software Wizardry
> Port Coquitlam, B.C.
> bobmckee...@mac.com
> 
> 
> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

John Baughman
Kailua, Hawaii
(808) 262-0328
john...@hawaii.rr.com





**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**