Uniface User Forum

Hi

We are migrating from Uniface 9 to Uniface 10.4.02. We have some web services that have worked fine in Uniface 9, but fail in Uniface 10.

I wrote the original web services following a Uniface blog article some years ago, along the lines of "How to implement a web service with a Dynamic Server Page". The problem in Uniface 10 is that GET requests work fine, but POST requests fail before getting near the DSP. I eventually discovered that the POST request was being denied by the USYSHTTP component.

A simple workaround for this was to simply convert my DSP to a USP, and then everything works fine.

So my question is, is this expected behaviour in Uniface 10? Was I wrong to assume it would work in Uniface 9  (it did work)? 

I'm happy to be told that POSTing to a DSP makes no sense, if that's the case. I'm just trying to understand.

Thanks very much.

Andrew

Hi Andrew,

I think I know the blog post you're referring to, which was written by an ex-colleague about creating REST services. It modified the triggers in a DSP component so that it didn't behave like a DSP by removing/replacing the standard trigger preActivate and postActivate logic which handles partial page updates. At the time I didn't think it was a good idea, and have always used a USP component for REST services instead. I think you could alternatively use a service if you prefer, which might be a slightly better conceptual fit.

The USYSHTTP service was introduced to allow you to customize the web lifecycle. It is possible to import the source code and modify it as we do in the DSP Web Development course  (for reasons such as adding additional authentication or security checks, customising error reporting, or redirecting to a login page on session timeout). The USYHTTP component contains different handlers for each type of component, so this is likely an unanticipated side-effect of your DSP component acting in an unusual way.

While you can customize USYSHTTP (e.g. to treat specific components as if they were not DSPs) it is probably better and easier in this case to just to change your component type property and recompile.

Kind Regards,

David Akerman

Hi

We are migrating from Uniface 9 to Uniface 10.4.02. We have some web services that have worked fine in Uniface 9, but fail in Uniface 10.

I wrote the original web services following a Uniface blog article some years ago, along the lines of "How to implement a web service with a Dynamic Server Page". The problem in Uniface 10 is that GET requests work fine, but POST requests fail before getting near the DSP. I eventually discovered that the POST request was being denied by the USYSHTTP component.

A simple workaround for this was to simply convert my DSP to a USP, and then everything works fine.

So my question is, is this expected behaviour in Uniface 10? Was I wrong to assume it would work in Uniface 9  (it did work)? 

I'm happy to be told that POSTing to a DSP makes no sense, if that's the case. I'm just trying to understand.

Thanks very much.

Andrew

Hi David 

Thank you for your helpful response. That's pretty much what I guessed had happened, though I didn't realize using a DSP to create a REST service was so unorthodox. 

I'll convert my DSP REST services to USP, as it's easy enough to do and there aren't many.

Andrew

Hi Andrew,

I think I know the blog post you're referring to, which was written by an ex-colleague about creating REST services. It modified the triggers in a DSP component so that it didn't behave like a DSP by removing/replacing the standard trigger preActivate and postActivate logic which handles partial page updates. At the time I didn't think it was a good idea, and have always used a USP component for REST services instead. I think you could alternatively use a service if you prefer, which might be a slightly better conceptual fit.

The USYSHTTP service was introduced to allow you to customize the web lifecycle. It is possible to import the source code and modify it as we do in the DSP Web Development course  (for reasons such as adding additional authentication or security checks, customising error reporting, or redirecting to a login page on session timeout). The USYHTTP component contains different handlers for each type of component, so this is likely an unanticipated side-effect of your DSP component acting in an unusual way.

While you can customize USYSHTTP (e.g. to treat specific components as if they were not DSPs) it is probably better and easier in this case to just to change your component type property and recompile.

Kind Regards,

David Akerman

Hi

We are migrating from Uniface 9 to Uniface 10.4.02. We have some web services that have worked fine in Uniface 9, but fail in Uniface 10.

I wrote the original web services following a Uniface blog article some years ago, along the lines of "How to implement a web service with a Dynamic Server Page". The problem in Uniface 10 is that GET requests work fine, but POST requests fail before getting near the DSP. I eventually discovered that the POST request was being denied by the USYSHTTP component.

A simple workaround for this was to simply convert my DSP to a USP, and then everything works fine.

So my question is, is this expected behaviour in Uniface 10? Was I wrong to assume it would work in Uniface 9  (it did work)? 

I'm happy to be told that POSTing to a DSP makes no sense, if that's the case. I'm just trying to understand.

Thanks very much.

Andrew

Just a question from a newbie to DSP/USP and the realtion to SOAP/REST*) :-)
We did programming a SOAP/REST interface just with operations in a service
And then we used /sto to generate the corresponding SOAP statements.
Works perfect for us.
Is there an advantage to using DSP/USP?
Ingo

*)if I'm not wrong, SOAP is the technical interface definition whereas REST is a possible way of filling the interface with logical life

Hi David 

Thank you for your helpful response. That's pretty much what I guessed had happened, though I didn't realize using a DSP to create a REST service was so unorthodox. 

I'll convert my DSP REST services to USP, as it's easy enough to do and there aren't many.

Andrew

Hi Andrew,

I think I know the blog post you're referring to, which was written by an ex-colleague about creating REST services. It modified the triggers in a DSP component so that it didn't behave like a DSP by removing/replacing the standard trigger preActivate and postActivate logic which handles partial page updates. At the time I didn't think it was a good idea, and have always used a USP component for REST services instead. I think you could alternatively use a service if you prefer, which might be a slightly better conceptual fit.

The USYSHTTP service was introduced to allow you to customize the web lifecycle. It is possible to import the source code and modify it as we do in the DSP Web Development course  (for reasons such as adding additional authentication or security checks, customising error reporting, or redirecting to a login page on session timeout). The USYHTTP component contains different handlers for each type of component, so this is likely an unanticipated side-effect of your DSP component acting in an unusual way.

While you can customize USYSHTTP (e.g. to treat specific components as if they were not DSPs) it is probably better and easier in this case to just to change your component type property and recompile.

Kind Regards,

David Akerman

Hi

We are migrating from Uniface 9 to Uniface 10.4.02. We have some web services that have worked fine in Uniface 9, but fail in Uniface 10.

I wrote the original web services following a Uniface blog article some years ago, along the lines of "How to implement a web service with a Dynamic Server Page". The problem in Uniface 10 is that GET requests work fine, but POST requests fail before getting near the DSP. I eventually discovered that the POST request was being denied by the USYSHTTP component.

A simple workaround for this was to simply convert my DSP to a USP, and then everything works fine.

So my question is, is this expected behaviour in Uniface 10? Was I wrong to assume it would work in Uniface 9  (it did work)? 

I'm happy to be told that POSTing to a DSP makes no sense, if that's the case. I'm just trying to understand.

Thanks very much.

Andrew

Hello,

Unless I am mistaken $webinfo isn't supported on services (I think it generally does work). So you would usually want to go through a pass through USP/DSP for the service to utilise the request information. All of the work should be in a Service behind that.

Just a question from a newbie to DSP/USP and the realtion to SOAP/REST*) :-)
We did programming a SOAP/REST interface just with operations in a service
And then we used /sto to generate the corresponding SOAP statements.
Works perfect for us.
Is there an advantage to using DSP/USP?
Ingo

*)if I'm not wrong, SOAP is the technical interface definition whereas REST is a possible way of filling the interface with logical life

Hi David 

Thank you for your helpful response. That's pretty much what I guessed had happened, though I didn't realize using a DSP to create a REST service was so unorthodox. 

I'll convert my DSP REST services to USP, as it's easy enough to do and there aren't many.

Andrew

Hi Andrew,

I think I know the blog post you're referring to, which was written by an ex-colleague about creating REST services. It modified the triggers in a DSP component so that it didn't behave like a DSP by removing/replacing the standard trigger preActivate and postActivate logic which handles partial page updates. At the time I didn't think it was a good idea, and have always used a USP component for REST services instead. I think you could alternatively use a service if you prefer, which might be a slightly better conceptual fit.

The USYSHTTP service was introduced to allow you to customize the web lifecycle. It is possible to import the source code and modify it as we do in the DSP Web Development course  (for reasons such as adding additional authentication or security checks, customising error reporting, or redirecting to a login page on session timeout). The USYHTTP component contains different handlers for each type of component, so this is likely an unanticipated side-effect of your DSP component acting in an unusual way.

While you can customize USYSHTTP (e.g. to treat specific components as if they were not DSPs) it is probably better and easier in this case to just to change your component type property and recompile.

Kind Regards,

David Akerman

Hi

We are migrating from Uniface 9 to Uniface 10.4.02. We have some web services that have worked fine in Uniface 9, but fail in Uniface 10.

I wrote the original web services following a Uniface blog article some years ago, along the lines of "How to implement a web service with a Dynamic Server Page". The problem in Uniface 10 is that GET requests work fine, but POST requests fail before getting near the DSP. I eventually discovered that the POST request was being denied by the USYSHTTP component.

A simple workaround for this was to simply convert my DSP to a USP, and then everything works fine.

So my question is, is this expected behaviour in Uniface 10? Was I wrong to assume it would work in Uniface 9  (it did work)? 

I'm happy to be told that POSTing to a DSP makes no sense, if that's the case. I'm just trying to understand.

Thanks very much.

Andrew