Consolidating business intelligence for REST and APSV

Posted by OctavioOlguin on 21-Jun-2017 19:32

I'm about to consolidate 2 projects, so the resulting project, exposes procedures as REST, and also current clients access same procedures via APSV to PASOE 11.7.  Have several questions.

1)  the procedure with the task at hand, for instance, a method to get some customers (20 years with for each customer in the ears, rings a bell, don't you think?), is used to map the process to the rest part of pasoe.  So far so good..  How do I expose same procedure to APSV client?  Should I create a Wrapper .p to instantiate the customer class, and call the same method used for the GET verb?.

2) this means that I should publish .war file for rest client, and the .p procedure (compiled to .r, of course) to provide the class for the wraper?

3) this imposes the need of funny trickery with propath, as I've been warned in previous question here on community?


All Replies

Posted by Irfan on 21-Jun-2017 21:04

Hi Octavio,

If your REST Services backend logic is ABL procedures, then you can use the same procedures as remote procedures to be called by APSV Client. In-case you are using ABL Classic to as REST backend, then you definitely need to  write some ABL procedures that would call appropriate classes and methods.

Of-course you have publish all your backend logic to the PASOE Server, irrespective of REST Artefacts and ABL Procedures/classes. The question would be do you want to deploy everything in the same WebApp or different WebApp. It does not matter for the backend because they all share the same PROPATH. 

I did not understand why you want to have different PROPATH. I see that you wanted to call the same REST backend for APSV, so why would you want to have different PROPATH? If you want to write different ABL code for both REST and APSV Clients but the procedure names will be same, then yes. You might need to put some kind of condition in your code(but there shouldn't be a necessity  for invoking APSV and REST Clients).

Posted by OctavioOlguin on 22-Jun-2017 08:32

What I need is to call same code for REST and APSV clients, so there is no need for maintaining 2 source codes to do the same task,,

Posted by Irfan on 22-Jun-2017 14:15


Attached a sample flow that uses same .p for both APSV and REST. Is that what you were looking for ? 

Posted by kevin hermans on 28-Jun-2017 07:19

How do you do this with Business entity classes?

For example if you create a standard Business entity. How can I access one of the methods through APSV?

REST is working fine.

Posted by bronco on 28-Jun-2017 07:28

Well, if look at the OpenEdge Reference Architecture (OERA) you'll see that what is called the Business Entity is in fact the System Interface (SI). My advice would be not to program any business logic in what you call the "standard Business Entity", but treat it as what it is, a Service Interface. Make a true Business Entity and wire your SI to that BE. And make another SI for the APSV transport.

Posted by kevin hermans on 28-Jun-2017 07:58

Our Business logic is separated from our Business entities. At this moment we create them with the CRUD and invoke methods these methods are also created in our backend classes. So in our Business entities there is no Business logic we just pass the data. My explanation was not that accurate...

But if I understand you well you can access the backend logic class through the APSV transport. Can you give an example please? For procedural purpose Irfan has already given an example. But how I have to do this for accessing a method in an object of the backend?

Posted by bronco on 28-Jun-2017 08:22

Well, you create the service interface for the APSV transport. Basically you create a .p (for example: get_customer.p) and in that .p instantiate your customer logic object (say: customerObject = new BeCustomer()) and access the appropiate method. Just like you used to do in the classic AppServer.

Posted by Peter Judge on 28-Jun-2017 09:58

So in OERA terms the Business Entity _is_ the business logic. The service interface is NOT the BE.  The lack of a well-defined Service Interface layer in the OERA diagrams is one of its larger failings.
In “Mobile services” terms the annotations on the BE methods define the service interface (which may be implemented in java or ABL).
I would create a distinct service interface that may be tailored for the client – a SOAP client may pass in XML, a ‘web’ client JSON and an ABL client temp-tables – which then authenticates the user, authorizes the operation and transforms the data into a format that the business logic understands.

Posted by bronco on 28-Jun-2017 12:46

Of course the BE (OpenEdge.BusinessLogic.BusinessEntity) handles the logic, it just shouldn't handle the transport related stuff as well. Makes the re-use of it more difficult.

Posted by on 28-Jun-2017 13:42


that’s a very academic view on the matter :)

If you throw in the mix a ‘business task’ (to ‘coordinate’ work on multiple business entities) then you only have to instantiate the service interface, the business task, a number of business entities each with it’s own data access but luckily object instantiation is blazing fast in 4GL ;)

Anyway, I’m a bit confused by the title… ‘business intelligence’???
Marian Edu

Acorn IT 
+40 740 036 212

Posted by OctavioOlguin on 01-Jul-2017 12:52

I meant with that title to refer to the procedures that make up the application's object.  Sorry

This thread is closed