Consolidating business intelligence for REST and APSV - Forum - OpenEdge Development - Progress Community

Consolidating business intelligence for REST and APSV

 Forum

Consolidating business intelligence for REST and APSV

  • 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?

    Thanks.

  • 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).

    Regards,

    Irfan

  • 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,,

  • APSV and REST Client.docx

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

    Regards,

    Irfan

  • 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.

  • 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.

  • 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?

  • 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.

  • 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.
     
     
  • 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.

  • Bronco, 

    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

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