P
Peter Judge
Guest
Not quite. A PASOE instance contains a couple of things - one or more webapps. A webapp is a URI that exposes your ABL to the web/REST. A webapp talks to the AVM (ABL execution engine) via a session manager. - one or more abl-applications. An abl application is a single session manager (a set of configuration like PROPATH and db connections) 1 webapp can only talk to 1 abl application 1 abl application can be exposed via one or more webapps 1 instance exposes 1 or more webapps An ABL application’s PROPATH is the same as any propath – it can go anywhere basically. BUT we provide 2 recommended locations for ABL code, which are added to PROPATH by default. - in $CATALINA_BASE/openedge (that’s the instance root). This is where we think “common business logic” should go. Standard application libraries, stuff that can be used by all webapps and abl-applications in an instance. This could also contain common utilities. - in $CATALINA_BASE/webapps/ /WEB-INF/openedge (each webapp). This is where we think “service interface code” should go. This is ABL code that relates to handling a request and calling into the common business logic. It should only contain code relating to that webapp. You may notice that there’s no place for ABL code for a particular abl-application. This is something we’ll be addressing in the (near, hopefully) future but if you use $CATALINA_BASE/ablapps/ /openedge you should be in a good position. This should be code that’s specific to a particular abl-application (like individual customer extensions or customisations). In the pic, /SportsSvc and /PubSports are webapps. They both handle requests for the sports-demo abl application. I don’t have a simple example set up to share, but I feel that once you have the 3 basic units in your mind it gets easier to work with and understand.
Continue reading...
Continue reading...