Creating a Magnolia page for rendering from SCIPIO ERP is a two-step process: you first write the page itself, or more specifically the template for it, using SCIPIO-specific API facilities; then you map an SCIPIO ERP controller request or view to the page so it is invoked for rendering through an SCIPIO ERP webapp or store. Any SCIPIO ERP Request that falls into the SCIPIO request flow will output the page that is specified. This gives a lot of freedom when reusing or implementing new processes in the system.
Page authors edit templates and pages in Magnolia instances using the Magnolia author webapp (http://localhost:[port]/magnoliaAuthor) and regular Magnolia means, but supplemented with a SCIPIO-specific API for code and some SCIPIO helper applications. It is here that the authors are able to add and modify content to the created pages.
Understanding the Request Flow
To give a general idea, the progress of a typical SCIPIO request is summarily:
A request is made directly or indirectly to an SCIPIO ERP webapp.
If the request matched a SCIPIO Process Mapping source path, it is process and forwarded. Afterward or otherwise, the request continues on as normal, and for it to be relevant to SCIPIO, toward the webapp’s controller.
Eventually the webapp/store’s controller receives the request and the request’s events are run.
If the request response is a view, SCIPIO intercepts the view rendering for it.
If the view matched a SCIPIO Process View Mapping or View Mapping, SCIPIO sets up a new CMS rendering request to the CMS page defined by URI in the mapping. The rendering request is a separate request.
The CMS rendering request is invoked by SCIPIO, and SCIPIO serializes and passes with it a number of predefined request/session/application/context attributes, as well as other attributes of simple types. In addition, it attempts to serialize and pass attributes specified by name by the developer, which are (for one) specified in View Parameters.
SCIPIO intercepts the CMS request received by Magnolia. SCIPIO checks the request and at this point may reject invalid or suspicious requests.
Otherwise, if the page to be rendered has a SCIPIO-initialized page template and the request was valid, SCIPIO prepares a rendering context (the main SCIPIO context, SCIPIORenderContext/catoCtx; an SCIPIO ERP/OFBiz screen context emulation, catoCtx.ofbizCtx; and mock servlet objects representing the original request, catoCtx.ofbizRequest, catoCtx.ofbizSession, etc.) and stores it in the Magnolia context.
SCIPIO wraps the page template section rendering in an SCIPIO ERP transaction (currently always enabled unless globally disabled via properties).
SCIPIO invokes any Groovy/Minilang script includes associated with the template (via SCIPIO Template Helper app), before the template model is executed, using the emulated OFBiz screen context (catoCtx.ofbizCtx).
Magnolia invokes the template model and finally the template itself, with the SCIPIO context and templating functions made available to them. The client’s code may use the SCIPIO context and facilities (SCIPIO Render & Platform Communication API) to read SCIPIO ERP data from the request/session/application/context attributes passed across the invocation or – more importantly – from the OFBiz database or API (using delegator, dispatcher, etc.).
The CMS produces a final output.
If the CMS rendering request did not succeed, an internal server error is produced and logged.
Otherwise, its output is transferred to the original SCIPIO ERP webapp request’s output, finalizing the view rendering.