VLF-ONE Strategies for dealing with complex Server Modules

[jyoung]

Given that a single Server Module supports multiple filters and command handlers, they can get rather large and some routines can get pretty complex.

What are some recommended strategies to deal with these situations?

In my former .NET life, I would consider the Server Module analogous to WebAPI or MVC Controllers and offload the business logic into a "Service" or "Domain" object. So that the responsibility of the controller was to deal with the HTTP Request/Response and the Service's responsibly was to fulfill the logic of the request.

I am beginning to see a need for the same type of thing for complex Server Modules.

I've used a server side reusable part before to abstract away some of the complexities of dealing with Integrator and it's JSM commands. So I could do the same here, create a reusable server side part that would handle the complex logic and leave the server module to map the inputs and outputs aka Requests and Responses.

I've also thought about using Functions as I can then invoke them form Windows Forms to test them, similar to how I test repository Rules and Triggers. That makes a lot of sense to me as I can call that Function from a Server Module or a Function, however this line in the documentation

The use of parameters when calling another process or function is strongly not recommended. Use the exchange list instead.

in http://docs.lansa.com/14/en/lansa015/in ... call_c.htm gives me pause and apparently I should use Exchange Lists.

Ok, but I cannot pass lists or data structures with Exchange Lists, or can I? The documentation does not say anything about exchanging lists or data structures and I cannot (according to the docs) get a result from a Function without an Exchange List. It seems almost like a catch-22.

So, how are you handling complex Server Modules? Do you just leave them alone and let them be?

Thanks,
Joe

[MarkD]

This is really a general VL-Web question.

Regarding “Given that a single Server Module supports multiple filters and command handlers”

You can have many server modules, right down to one per filter and one per command handler I guess. So they can be as coarse grained (large) or as fine grained (small) as you chose to make them.

If you go the fine grained route you can avoid duplicated code by creating a “server common services” reusable part. Normally such parts are declared as scope(*Application) so that you only get one instance in a job. It becomes the placeholder for all your shared and reusable logic. Standard server module initialize and terminate methods are also recommended to accommodate present and future changes to how library lists are set, how resources are freed, etc. See http://docs.lansa.com/14/en/lansa048/in ... 8_6710.htm for an example.

[MarkD]

Regarding sharing logic between Windows and Web applications, I have recently been experimenting with that and am using a model structured like this:

capture.png (16.89 KiB) Viewed 9759 times

Where this differs from you model I think is that the "meat" of the logic is contained in a shared reusable part, rather than in a function.
That make its interface capabilities substantially simpler and more powerful than a function's are.

BTW - You can pass working lists around between reusable parts and functions, buts that's kind of another whole topic I guess.

[jyoung]

You are right, I could have fine grained server modules to make the management of the server modules easier.

Your model is very similar to how I would have modeled it in .NET and is where I am headed now. By having a lightweight interface to shared object (a reusable part in this case) some really useful things happen. Whereas in .NET it made unit testing easier and we don't have unit testing in LANSA, but we can easily create a Windows Form to invoke the lightweight interface, that in turn invokes our shared object. This way we don't have to to mess around with navigating through the app just to test something out. We get the shared object working then is it just a matter of hooking it up with the Server Module and testing that it works within the app as expected.

I am used to passing lists around (via custom objects and Collections) on the client, but have not done so on the server. If the resuable part Target Platform is "All Platforms" then it looks like you can reuse the same object on Client and the Server, though as I mentioned I have not tried that yet.

I had thought that using a Function would be easier, but now I am thinking maybe not.

[Stewart Marshall]

Hi Joe

This is all really a matter of taste.

The server module as you suggest simply defines what we might regard as a set of APIs (SrvRoutines). How each of those routines does its processing is entirely up to you.

As the processing requirements are typically procedural, e.g. reading/writing data, using Functions is a good way to do. Data transfer to a Server module today is by way of Groups, Fields and Lists which fits very nicely with Functions which receive/return individual field values via Exchange and can receive and return multiple Lists.

Code: Select all

Srvroutine Name(SaveOrder)
Field_Map For(*Input) Field(#OrderID)
List_Map For(*Input) List(#OrderItems)

Exchange Fields(#OrderId)
Call Process(*Direct) Function(SaveOrd) Pass_Lst(#OrderItems)

Endroutine

This is a pragmatic view of how best to arrange your processing. Both the Function and the Server Module nominally perform the same activity, it's just the work is actually done by the Function, which you could call from the client using Call_Server_Function.

Building an object to run on both platforms seems like a good idea at first, but it does require additional work, beyond the simple definition. For example, while IO commands can be written in Windows reusable parts, they are invalid in browser based parts. This means that the IO functionality needs to be abstracted regardless.

Regards

[atostaine]

Our main ancestor(s) define our common code like this:

define_com #common scope(*application)

RP Common has all of the common RP's defined like this:

begin_com Role(*EXTENDS #PRIM_objt)
define_com #getInvNo scope(*application) reference(*Deferred)
define_com #anotherRP(*application) reference(*Deferred)
.....etc.

define_pty pGetInvNo get(*Reference #GetInvNo)
define_pty pAnotherRP get(*Reference #anotherRp)
.....etc.
end_com

Maybe #getInvNo RP looks like this:

begin_com Role(*EXTENDS #PRIM_objt)
mthRoutine mNextInvNo
define_map for(*output) class(#invNo) name(#pInvNo)
..Code to get next Invoice#
endRoutine
end_com

In every RP with those ancestor(s), we can do this:

#common.pGetInvNo.mNextInvNo(#invNo)

If we can't use that ancestor, we just add this line to the RP

define_com #common scope(*application)


It works well for us. Doesn't slow down loading the RP's the first time, and has been working since V11.5

Also, our WAM's and VL-WEB load the common RP as well. We have an RP that does our message box processing (wrapper around message_box_* Bifs). We don't use RP's that have windows only code on the web, so it just works.

Note: code From memory, don't have my IDE nearby to paste code.