OpenEdge Web Handlers

Posted by marian.edu on 10-Aug-2018 05:39

Hi guys, 

wonder if anyone uses those (well, besides Mike of course) and if you do how do you actually handle differences between OE versions and deployment? Do you work with what PSC ships in core, net libraries or just keep your own version and ship that with the app code?

Somehow related, are those libraries part of a format SDK? Is the source code public, do we have some kind of specifications, versioning? I see CCS parts are included, or at least parts of that, is that open for community contribution? Would it be ok for instance to take the libraries from 11.7 and deploy the code on 11.2 (assuming it will compile in the first place)?

Trying to find out what would be the best way to override some of the classes used by a WebHandler so it would work whether or not the libraries are available or not so, guess the main question is can we distribute the code from an earlier OE version or that is a violation of the EULA?

Thanks,

Marian

OpenEdge Development - Forum

All Replies

Posted by Peter Judge on 10-Aug-2018 08:24

I don’t know about EULAs but will try to answer some bits.
 
WebHandlers only work on PASOE and only on 11.6.0+, when the WEB transport was introduced. They do not work on the REST or any other transport.
 
At a bare minimum you need an implementation of a OpenEdge.Web.IWebRequest and an implementation of a Progress.Web.IWebHandler and some configuration (properties) to use that WebHandler for a particular (OE-) Webapp. We try to code to interfaces as far as possible but (as Mike Fechner noted elsewhere on these forums) that doesn’t guarantee that we won’t break backwards compatibility.
 
PSC ships a few implementations (for a variety of purposes).  I’ve done a couple of session on webhandlers at PUGs over time.  The slides at onedrive.live.com/  have the basics.
 
The sources are available in $DLC/src/netlib/OpenEdge.Net.pl , and are for that version of OE. We don’t typically provide specs. There is some API doc at https://documentation.progress.com/output/oehttpclient/117/  . There’s no technical reason preventing you from shipping/deploying an entire ABL “runtime environment” – by which I mean a predefined set of rcode that your application uses. You can use the -baseADE parameter to point to a directory containing a set of PL files, or set it to blank to prevent the AVM from adding the standard default PROPATH entries (eg. $DLC/tty). The compatibility of this rcode would obviously be subject to the AVM’s version (and features etc).
 
Not sure as to what you mean by part of an SDK (but I’m interested in what you’d want in/as one).
 
Also, deployment and versioning of ABL services (and other parts of an application) to PASOE is something we’re working on at the moment – we’ll be asking about some of these on the CVP forums (https://community.progress.com/community_groups/openedge_customer_validation_program ) .
 
 
 

Posted by marian.edu on 12-Aug-2018 10:24

Thanks for that Peter,


had a feeling you might know more about those but wanted to hear more experiences from those using them.

I don't really care much about the transport restrictions as our need was to use those in OE10.2B+ (as long as that is still alive and kicking) and as I've soon discovered my hope to reuse or extend the existing implementation have hit a wall pretty soon... inline getter/setter for properties can be a great showstopper :(

Anyway, when I'm referring to an SDK I mean all those interfaces/implementation classes that you guys ship with latest versions (Core, Net, Web, etc). If one starts to use those then it would be nice to know things are versioned and at least we get to know when there are breaking changes. Dependencies between those packages is not clear either, I saw CCS have made it into some of that code already but even there is not clear how versioning works.

Will look into that CVP thingy, haven't heard about it up until now but hey we're still making progress :)

Marian Edu

Acorn IT 
+40 740 036 212

This thread is closed