Great sample to start, thanks a lot! 

The problem I'm having is that since the dashboard server is interactive,  it seems to call a lot of endpoints (e.g. http:/127.0.0.1:8080/foo/bar/(…)/anything ) which are not known in advance, so I need a way to route any suburl like http://myserver/csp/dashboards/* to 127.0.0.1:8080/*  , but also http://myserver/csp/dashboards/*/* to 127.0.0.1:8080/*/* etc.

I need to configure both the web server in order to route all these requests to the CSP gateway (not only *.csp, *.cls ...it could be *.py , who knows) and the CSP gateway should invoke a single class/page which should deliver them all, instead of having a page for each endpoint, which is how Caché handles them by default. For this reason I need to understand how the REST broker works. Maybe there are other examples of having one csp page serving different urls/endpoints, I don't know.

Hello and thanx a lot for the reply.

The goal was mainly to port as much code as possible very quickly, because we ha a deadline soon (1 month, 20klocs of  PL/SQL code): later it will be reengineered properly during a second phase, but it seems that a 1:1 conversion is not possible. Also, we are accessing data by means of SQL only, so anything that is only supported in the OO interface is not good for us.

We found that even initialization is often done inside their triggers (!), so the only option is splitting the trigger code into :

1 )Initialization

2) Validation

3) Normalization

4) Cascading changes to other tables

It seems to me that 1) is a perfect job for INITIALEXPRESSION attribute of properties.

I have tried using a  <propertyname>IsValid() and a <propertyName>Normalize() ClassMethods and they seem to work (through SQL) without creating a custom datatype: I don't know if it's currently a good pattern, since I couldn't find it clearly stated in the documentation. If someone can confirm that it's ok, we'll proceed.

4) Is clearly the right job for the trigger, we'll leave this code in the trigger.