Runtime behavior | HCL Digital Experience
The portal event broker subsystem provides support for inter-portlet communication with active notifications using portlet events or the cooperative programming model.
The event broker is based on a loosely coupled publish/subscribe communication model: participating portlets declare the messages or data types that they can publish and consume, but do not need to know about the actual communication structure.
How messages are distributed between portlets is determined by portlet wires that are defined as part of page editing. Portlet wires link a defined output of one portlet on a page to a defined input of another portlet on the same page or on a different page.
The wiring step is separate from portlet development and deployment. This allows independent development of source and target portlets, as long as both portlets use common data types and semantics for information exchange. Portlets can operate stand-alone, and, as partner portlets for the communication are added by editing pages, they can exchange information and react in a coordinated manner, and thereby improve the user experience. Conversely, as portlets are removed, the remaining portlets still work correctly.
Action/event and render phases
The processing cycle of a portal request is divided into an action/event phase which processes user input and a render phase which generates markup output. The activity of the event broker subsystem occurs during the action/event phase. Event processing is usually initiated by a portlet action that is encoded in the current request URL. For example, this can be a portlet action URL, or a URL generated by a click-to-action menu. For requests that do not require portlet activity, but just produce output, the action/event phase can be skipped entirely.
If the request specifies a portlet action, that action will be run and may itself publish output, either as a JSR 286 event or as a cooperative portlet property. If that output is wired to the input of one or more other portlets, a call to the processing methods of these portlets is put into the event queue. When the first portlet action is completed, the next event is taken from the queue and the target portlet is invoked. In the course of the event processing, the target portlet can trigger further communication calls that are then also queued. This process repeats until the queue is empty.
- Transfer of the order ID to the Order Details portlet.
- This first step also triggers the transfer of the tracking ID for the order to the Tracking Details portlet
- The Tracking details portlet in turn triggers the transfer of the customer name that is associated with the order to the Customer Details portlet.
- Consequently, all three portlets display information that pertains to the same customer order.