Visual LANSA Forum

Posted: **Wed Aug 10, 2022 5:40 pm**

Hi again,

I have to create a WEB-API for a customer, which is called from an external webshop to get prices and item availability. So far this works already quite well.
But now there is a special requirement to send a mail automatically if there are any inconsistencies in the determination of the values.

I have learnt from supoort that when the store makes the request, LANSA automatically starts the server routine and sends the response when the server routine ends with ENDROUTINE.
I already made the experience that if I add more instructions after this command (e.g. mail an error message), this leads to a very very noticeable delay in the response.

Can I somehow programmatically trigger the response myself immediately or can I call routines within the Web API server that are executed in parallel?
How can it be feasible with this processing that after the sender of the response - i.e. after the server routine has ended - another function / mthroutine / Reusable Part can be called / started to send mails? I tried to create a server module for this but when I try to use this VL says: the server module is only supported on the web. I thought this is Web...

Does anybody know a way to realize these requirements?

Many thanks in advance,
Jörg

Posted: **Wed Aug 10, 2022 11:41 pm**

Is this the WAM environment Jörg???

Posted: **Thu Aug 11, 2022 1:12 am**

Hi René,

no, this is a Web API created with VL wizard in VL15.
After processing the operation "GetPricesAndAvailabilties" I have to send an email via LANSA Integrator (functionality is already avaiulable). However, the mail process must not delay the sending of the response!

KInd regards,
Jörg

Posted: **Thu Aug 11, 2022 1:58 am**

Hi Joerg,

Our trusty SUBMIT still works.... I modified a server module Status server routine to add a submit:

Code: Select all

Srvroutine Name(Status) Response(*HTTP #http)
* Instance of the Status Operation
Define_Com Class(#Com_Home.Status) Name(#Operation)
Define Field(#contentstring) Type(*Char) Length(256) Decimals(0)
If (#Operation.TryBind( #http ))
#contentstring := '{' + (10).AsUnicodeString + '"JobID": "' + *JOBNBR + '",' + (10).AsUnicodeString + '"ServerStatus": "OK",' + (10).AsUnicodeString + '"CPU Type": "' + *CPUTYPE + '",' + (10).AsUnicodeString + '"LANSAPGMLIB": "' + *LANSAPGMLIB + '",' + (10).AsUnicodeString + '"Partition": "' + *PARTITION + '",' + (10).AsUnicodeString + '"Language": "' + *LANGUAGE + '"' + (10).AsUnicodeString + '}'
#Operation.Response.SetContentString( #contentstring )

#STD_STRNG := #contentstring
Submit Process(test810pro) Function(testbatch) Exchange(#STD_STRNG)

Endif
Endroutine

and submitted a process/function that in my test just did this:

Code: Select all

Function Options(*DIRECT)
Insert Fields(#STD_STRNG) To_File(TESTLOG)
Return

and it works correctly. it could be JSM calls to Integrator.
Notice that a rdmlx function, can call a reusable part, another function, etc.

Now regarding, to:
"the server module is only supported on the web. I thought this is Web..."

well... the web page/view/dialog/reusable part consuming the server module, are running in the web browser or client (html,javascript).
the web client can execute the server module asynchronous or not.
But then, the server module, it is in the server, is a compiled C program. the server module is not in the web.
I think that message is trying to say that only something running in the web client, can execute a server module.

Posted: **Thu Aug 11, 2022 6:23 pm**

Thank you, Dino - both for the web explanation and for the example!

in this modern environment I have not thought about these "old fellows" at all.
It feels a little bit strange to work with things like SUBMIT, SAVE_LIST, RESTORE_SAVED_LIST or EXCHANGE in the web environment. But when it works then it works

Kind regards,
Joerg

Visual LANSA Forum

Web API - asynchronous processing

Web API - asynchronous processing

Re: Web API - asynchronous processing

Re: Web API - asynchronous processing

Re: Web API - asynchronous processing

Re: Web API - asynchronous processing