Dear Rick,
I have a project called Test and a TestProcess.prg with several functions.
I created a REST service into Test project then added several funtions to it.
Please, is there any way to expose TestProcess functions to the REST service?
If cannot call TestProcess or Process from any REST service.
Thank you very much for support

I don't understand your question...

+++ Rick ---

Dear Rick,
in my Test project I have the usual TestProcess prg with several utility functions.
I added a REST prg to project .
In one REST function I need to call some TestProcess function, but this does not work.
For example: if there is a function TestProcess.MyFunction that I can call rightly through the project, then I cannot call it from a Rest Function because REST class do not see TestProcess prg.
Please is it possible to expose Process functions to REST class, or I have to copy every TestProcess functions into REST class to be able to use it?
Thank you for patience 😃

Hi Luca,
You can do that by creating another process class. We'll call it ParentTestProcess.prgfor example.
Then edit your TestProcess and REST process prgs to inherit from ParentTestProcess instead of wwProcess.
Move any methods that will be called by both TestProcess and REST to the ParentTestProcess class. While you're at it, you can put the common properties in the ParentTestProcess class as well.

Carl

Many thanks Carl!!

@Carl - I'm not sure if that would work in Luca's case because you can't mix and match base classes between wwProcess and wwRestProcess. You can't create a wwProcess base class and then inherit from it and also somehow inherit wwRestProcess...

I'd argue that the Process method code should not be shared, unless it's for routing related purposes (ie. routing one request to another's output internally). Any common code should be in a shared library class, and any business logic probably should be in business objects that can be shared by both the service and the HTML application.

For more complex applications that have a lot of Process methods I'd even recommend creating helper classes that you can forward processing to. They'd do the same thing as a process class, but allow you to have multiple classes to break up the code size and complexity into more logical units - and avoid the 65k compilation limit that a few people have run into.

If you must Share Process Code

If it's absolutely necessary to share methods between these, then the better approach is to not use a REST class, but rather explicitly set up methods that handle REST requests as outlined in the walk through here:

Hooking up wwJsonService

That example, routes to a new class (AjaxCallbacks) but you could also route that directly back to THIS which is the process class and so have the calls in the same host Process class that can now share methods with the HTML application. This pretty much gives you the same functionality that wwRestProcess uses - the downside are the ugly URLs that have to explicitly specify the single access method and specify the method for the secondary routing:

https://localhost:5200/JsonCallbacks.wwd?Method=Customers

Personally I much prefer completely seperating my services from HTML front end just for clarity and ease maintenance...

+++ Rick ---

Hi Rick,
Yeah, I should have thought of that.
In my app, I have several process classes/subclasses that serve different purposes and have different authentication methods. However, my subclass that returns JSON is not based on wwRestProcess and I didn't take that into consideration in my note to Luca.
Good that you corrected that.

Carl