When to have multiple PASOE Instances, Web Apps, Services, and Resources - Forum - OpenEdge General - Progress Community

When to have multiple PASOE Instances, Web Apps, Services, and Resources

 Forum

When to have multiple PASOE Instances, Web Apps, Services, and Resources

This question is answered

I think I posted this to the wrong group yesterday (sorry for the duplicate):

I have a decent understanding of how each part of the PASOE stack behaves and is managed, but I'm looking for a simple explanation of when I should have more than one of any part of the stack. I didn't find a clear answer in the docs - rather, just the how-to-do-it part.

We are doing internal business development (not deploying to/for external customers) that includes multiple applications, each needing a set of Data Services/APIs that may or may not overlap with the other applications.

Instances - multiple for load-balancing. Ability to limit the load from one Data Service impacting performance of another Data Service? Other reasons?

Web Apps - multiple for different URL organization and different auth models?

Services - multiple services for URL organization?

Resources - this one is the most clear, essentially needing a resource for each "object" you want to work with via a Data Service.

And while you could put everything into a single PDSOE project and pick/choose what WAR files to deploy where, how do you split up your AppServer projects in PDSOE?

We have successfully used the PASOE stack for maybe a year, but are wondering if we need to reconsider some of the structure/organization.

Thank you,

Tim

Verified Answer
  • There's a missing "ABL Apps" level missing - this is the common business application code/DBs for all services exposed via webapp. It sits between "Instances" and "Web Apps".
     
    I would have 1 project in PDSOE for each ABL App, and 1 for each ABL webapp*.
     
    The Server that you associate projects with in PDSOE represents an ABL App - you can see that if you double-click opn the server in the "Servers" view/editor. The Connection specifies the PASOE name and the ABL Application name.
     
     
     
     
    * The ABL WebApp projects include an AppServer folder, which is really the ABL App's code. I'd leave it empty and/or not deploy from here.
                   
     
All Replies
  • There's a missing "ABL Apps" level missing - this is the common business application code/DBs for all services exposed via webapp. It sits between "Instances" and "Web Apps".
     
    I would have 1 project in PDSOE for each ABL App, and 1 for each ABL webapp*.
     
    The Server that you associate projects with in PDSOE represents an ABL App - you can see that if you double-click opn the server in the "Servers" view/editor. The Connection specifies the PASOE name and the ABL Application name.
     
     
     
     
    * The ABL WebApp projects include an AppServer folder, which is really the ABL App's code. I'd leave it empty and/or not deploy from here.
                   
     
  • Hi Peter,

    I'm reviewing your slides from a session I missed at PUG Challenge. Looks like I attended the wrong session during that slot. :)

    pugchallenge.org/.../516_BeyondTheCode.pdf

    I think this answers many of my questions. Thanks for excellent explanations and diagrams in your slides!

  • Thanks Tim … and please ask if you have more questions.
     
    If anyone's interested (and in Barcelona for the EMEA PUG), I'll be presenting this session at 13.45 on Thursday (31-Oct).