APEX

partlycloudy wrote:
apex.server.process can be invoked from client-side Javascript to read/write data on the server. The pName parameter to this API is The name of the PL/SQL on-demand page or application process to call. Parameters to this process are passed using the apex_application.g_xNN package variables. This process typically returns a JSON object back to the client. For DML operations, this is typically a simple success/failure code/message. When data needs to be retrieved, it tends to be a more complex object. Putting all this code in the APEX application/page process (AJAX callback) is considered poor practice. 
I guess the only option is to create a packaged or standalone stored procedure and use that as the application/page process with the restriction that it should have exactly zero parameters, instead all IN and OUT parameters are passed using APEX session state/package variables.

I would see this as violating the separation of concerns due to the tight coupling of the package implementation with APEX data structures and the requirements of a single application.

This is an updated version of a schematic I prepared for a customer a few years ago, showing an idealized (and therefore rarely encountered!) architecture for enterprise APEX solutions.

APEX: Separation of Concerns

One of the design principles is the complete separation of business logic from any APEX dependencies. The programs in business packages do not directly access APEX session state, read from/write to APEX collections, utilize any APEX-defined data structures, or call any APEX APIs. All business program parameters and function return values are standard scalar types, business data structures, PL/SQL collections, or cursors.

The APEX packages form an intermediate layer between the business packages and APEX, and are used to resolve APEX dependencies and broker communication between the application UI and the business layer. Examples of this include marshalling APEX page item values to and from business data structures, and converting between database and HTML representations by escaping/unescaping values or adding/removing HTML mark-up.

The main benefits of this approach are reusability—existing business logic can be utilized without being APEX- or web-aware, and new logic is not tied to APEX, and can be used by other applications and processes—and simplified unit testing. With no APEX dependencies in the business logic, it is much easier to set up and automate unit tests as there is no need to use what were until recently undocumented and unsupported methods to simulate APEX sessions and application contexts to provide data during testing.

Paul - That's a great diagram, thanks for sharing. Happy to note that, without being an explicitly stated goal or even articulating as such, our architecture has, mostly, evolved to this state!

it is much easier to set up and automate unit tests as there is no need to use what were until recently undocumented and unsupported methods to simulate APEX sessions and application contexts to provide data during testing.

With APEX 18.1, it will take a lot of discipline to maintain this approach since apex_session.attach makes it trivial for developers and testers to inspect session state, collections, and use the same queries used by the application from the comfort of their favorite IDE!

parameters and function return values are standard scalar types, business data structures

But getting back to the topic at hand...would you agree that an exception is in order for procedures used for AJAX callbacks since APEX does not allow them to pass IN/OUT parameters? Especially since these procedures tend to generate, as stated, potentially long-winded code to generate an appropriate JSON object for the client to consume?