No access to Webspeed workshop via PasOE OE11.7

Hi Sofiane,

Workshop is not supported in PASOE, we added it earlier to the PASOE Instance as some part of it  worked. In 11.7 with new tomcat, we had issues running PASOE Instance and hence we removed it from the instance.

If your instance is taking up almost 10 mins to create on CentOS then I would guess it would be something with setting urandom to your environment. Try setting this on your CentOS for a new session then you should see this problem anymore.

rngd -r /dev/urandom

Hi Irfan,

Thank you for your response. But I am surprised by dropping such part from Webspeed without other alternative than OE Developer Studio !!!

How to manage, check, compile remote customer web apps when we change their database schema for example.

Fortunately, we have designed our own online compiler.

Regards,

Sofiane

Yea, I got to say getting rid of Workshop is a stupid idea...

After working through planning and testing a migration from Classic AppServers/WebSpeed to PAS, it really seems like support for Classic WebSpeed was an afterthought.  I've encountered a number of roadblocks in 11.7.2 migrating the WebSpeed apps, some of which we can code around, others we are waiting for hotfixes for, so I'm not surprised Workshop was ignored.

The new web handlers in PAS are attractive, but have their own issues.  Even in 11.7.2, basic features WebSpeed includes (getting form field values or multipart data), are certainly possible, but hard.  Each developer has to code their own solution for basic features available WebSpeed.

In my opinion if you have WebSpeed applications running in production and don't intend to rewrite, stick with Classic WebSpeed.  It has worked well for nearly 20 years.  But if you need more security out of the box (if you can manage getting Spring security running), have the ability/desire to rewrite your application, or are starting from scratch, PAS is worth a look.

Peter,

The current implementation makes it easy to get access to cookies, headers and query values/parameters ( poRequest:GetHeader("X-My-Stuff"):VALUE; poRequest:GetPathParameter("ItemID"); poRquest:URI:GetQueryValue("qType"); poRequest:GetPathParameter("GroupName")).  These all work well and are easy to understand.  

Even getting a JSON body is 'fairly' straight forward, but not nearly as simple.  There could be a better way, but right now I am creating aa Payload.MessageWriter, using Write(poRequest:Entity) and then casting the Entity as a JSONObject.  It would seem that a 'poRequest:GetMessageBodyJSON()' or something similar would make life easier.

But once you need access to basics like form field, things get much more complex.  Where as in WebSpeed we could simple call 'get-value("uType")' to get form field passed into a request, and even 'get-long-value("b64Image")' to get large items (like base64 image uploads), there is just no easy equivalent using WebHandlers.  Right now, as far as I can see, we need to Use the Payload.MessageWriter on the poRequest:Entity, cast that a a MulitpartEntity, get each entity part using Entity:GetPart(x), get the Header of the part, extract the field name from the header, and then the value from the body.    I've written logic for this(to return the entire set as an easy to use StringStringMap, but it will probably fail in the case of weird multipart entities and I'll end up having to go an re-write it; and I'm sure my logic won't work for super long values (like encoded images), and I'm not even thinking about binaries.

So, by moving away from the Compatiblity hander (which will allow us to access WebSpeed functions), I've now made basic things harder and more fragile.  Sure, I can eventually code around it, but that's pulling me away from getting actual work done.

We are only just at the start of our migration to PASOE and WebHandlers.  A majority of our new work will likely involve parsing JSON bodies from REST calls, but not all.  We will need to receive data as a form-body from some partners, and in those cases PASOE/WebHandlers is harder than using the Compatibility handler and writing old-school Webspeed programs.  

Peter,

While testing 11.7.5, I was searching for an API in all classes/docs/forum to retrieve multipart/form-data or application/x-www-form-urlencoded content.

You mentioned in your post dated back March 2018.

<<Better support for form-based stuff, whether its multipart/form-data or application/x-www-form-urlencoded content. Some GetField() and SetField() type methods. We do have open issues for these; we just need to get to them.>>

Can you tell me if it is something done ? (or maybe already in 12.0) ?

Thanks

Stephan