Greetings..
Trying to embrace mobile, I'm starting with baby step...
I have the folowing routine at procedure level,
BLOCK-LEVEL ON ERROR UNDO, THROW.
{bi/Paqs02.i}
DEFINE INPUT PARAMETER pSucursales AS INTEGER NO-UNDO.
DEFINE INPUT PARAMETER pFecha1 AS DATE NO-UNDO.
DEFINE INPUT PARAMETER pFecha2 AS DATE NO-UNDO.
DEFINE INPUT PARAMETER pStatus AS CHARACTER NO-UNDO.
DEFINE INPUT-OUTPUT PARAMETER DATASET FOR dsPaqs.
/* ******************** Preprocessor Definitions ******************** */
/* *************************** Main Block *************************** */
EMPTY TEMP-TABLE ttPaquete.
FOR EACH dwPaquete NO-LOCK
WHERE (dwPaquete.Sucursal = pSucursales OR pSucursales = 0)
AND dwPaquete.FechaSalida >= pFecha1
AND dwPaquete.FechaSalida <= pFecha2
AND can-do(pStatus, dwPaquete.statusP):
CREATE ttPaquete.
BUFFER-COPY dwPaquete TO ttPaquete.
RELEASE ttPaquete.
END.
by procedure level I mean that I call it with
RUN bi/paqs02.p ON hServer (fSucursal, fFecha, fFecha-2, Flags, INPUT-OUTPUT DATASET dsPaqs).
on my n-tier desktop app...
Now I would like to expose it as a simple mobile app, but the part that the internal procedures are the one exposed is tricky for me still, as I can't imagine how should I transform the current process, so it is "mobilizer-friendly".
Any clue would be deeply appreciated
Hi,
I would suggest you start by watching/doing the REST expose part of this workshop:
After you have done that, I suggest the simplest approach that I can think of:
- Do the similar configuration but connecting to your Database
- Create a Business Entity and instead of selecting a DB/Table like in the workshop above, use a .i file with the desired storage structure (dataset / temp-table)
- Comment the generic code included in the Read class ( /* SUPER:ReadData(filter). */ ) and paste your code in there
- Adapt your code to use a single input parameter called filter. In order to do that, you can pass the parameters as a JSON string and have your Read class parse them back into multiple variables
- Expose the Business Entity in you REST Service and test it
If you need to keep the code as-is, you can do it with INVOKE, but it would be more complex than what I've suggested above.
Regards,
Ricardo Perdigao
Questions to narrow down the answer:
- What version of PDSOE (Progress Developer Studio) do you have?
- Where do you plan to consume the REST data exposed (Hybrid App using Telerik Mobile, hybrid app using something else, Apple Native App, Android native app, etc)?
The above questions are to help me understand what tools you have? And what kind of project you should use:
OpenEdge Mobile (with JSDO) or REST Mobile (without JSDO).
- On an OpenEdge Mobile project, you would have to change your code a little to match the signature parameters for a read (easy). Or leave the parameters as is, but expose it as an Invoke and leverage the JSDO (medium).
- On an OpenEdge REST project, you can have the code as is, but it would not leverage the JSDO (not sure you need it). On this option, you will need to annotate the code and map the input/output parameters (easy).
Will try to help you more once I hear back from you!
Regards,
Ricardo Perdigao
rperdiga@progres.com
Thanks Ricardo!!
well... lot of stuff... I guess that's why I have had bad times trying to figure out an strategy, and focus on that... (I've been peeking here and there and nothing formal).
I'm on PDSOE11.5.1. The app run on Appserver, but I'll nedd to move to Pacific (already licensed), and as I asked some time back, I was recommended to move to pacific sooner. Also I think I should start in Telerik Platform, as of september, we have to move anyway...
I think that plataforms I should address are IOs and Android (in the first instance) and if hybryd or native, that really scapes me.... I would like to support the camera for the supervisor (that would be native...) and just reporting for division chief (guess is hybryd).
Guess I just need pointing on right direction to hands-on info...
Hi,
I would suggest you start by watching/doing the REST expose part of this workshop:
After you have done that, I suggest the simplest approach that I can think of:
- Do the similar configuration but connecting to your Database
- Create a Business Entity and instead of selecting a DB/Table like in the workshop above, use a .i file with the desired storage structure (dataset / temp-table)
- Comment the generic code included in the Read class ( /* SUPER:ReadData(filter). */ ) and paste your code in there
- Adapt your code to use a single input parameter called filter. In order to do that, you can pass the parameters as a JSON string and have your Read class parse them back into multiple variables
- Expose the Business Entity in you REST Service and test it
If you need to keep the code as-is, you can do it with INVOKE, but it would be more complex than what I've suggested above.
Regards,
Ricardo Perdigao
Thanks!!
Hands on that little later in the afternoon!!
I'll keep you posted!
See 'ya