Open the menu

    The Producer service WSRP allows for the provision of instances of interfaces such as remote portlets to be consumed by any WSRP consumer.

    WSRP is a standard defined by OASIS that defines a set of interfaces and related semantics that standardize interactions with components that provide the user with a markup, including the processing of user interactions with that markup. For more details about the WSRP standard, visit http://www.oasis-open.org/committees/wsrp.

    Behavioral Aspects

    The current implementation of the WSRP producer in LumisXP presents the behavioral aspects described below. These behaviors may be altered in future versions of LumisXP aiming for improvements and evolution of this service.

    • Registration: there is support for registration. Lumis supports both inband and outband registration.
    • Public render parameters: the producer ignores provided public parameters and does not send any public parameters.
    • User categories: the producer ignores any information about user categories provided by the consumer.
    • User information: the producer ignores any information about the user provided by the consumer.
    • Markup caching: the producer always indicates that the markup expires in zero seconds, which implies it is not to be cached.
    • Resource caching: the producer does not generate any extra control information about resource caching. The resource URLs generated by the producer are based on the proxy transport mechanism .
    • Events: the producer does not generate or process events.
    • Consumer Configured Portlet: the producer allows the creation of Consumer Configured Portlet as long as the consumer is registered.  The properties of the Portlet are stored as custom properties in the producer.
    • During import/export or applying channel template, the configurations of the WSRP producer service instance (all configurations and list of provided interface instances) are not transported.
    • HyperLink: HyperLink is a feature of LumisXP that allows generating a URL for a LumisXP page calculated dynamically according to its parametrization. In the WSRP specification, there is no support for a portlet to have a link to another page of the portal, or even to another portlet. Therefore, in the scenario where LumisXP is a WSRP producer and the URL of a HyperLink is rendered in a markup being consumed through WSRP, this URL will be written by the producer in an absolute manner, pointing to the corresponding LumisXP page. Thus, the HyperLink maintains its behavior of generating a URL for a LumisXP page. Note, however, that the end user when following this URL will leave the consumer portal and navigate directly to a LumisXP page. If the end user does not have access to navigate to this URL (for example, because they do not have access to navigate directly on the LumisXP server), an error may occur in their browser according to their access limitation.
    • WSRP does not send form parameters to render type URLs: This is a limitation of WSRP, where form parameters are sent only if the form is submitted to action-type URLs, and not if it is submitted to render-type URLs. Thus, interfaces that generate such types of HTML may not work correctly through WSRP.
    • Client-side functionalities: There are specific elements of a LumisXP page, such as javascript functions or HTML elements, that may not be available on the page created in the consumer, or even if they are attempted to be made available there, may not work as expected. Any interface that generates HTML that uses such elements may not work correctly through WSRP. Some client-side scripts may not work through WSRP if they generate URLs manually.
    • Use of the parameters itemId and lumItemId: The use of these parameters generates distinct behaviors between the operation of services when executed natively or via WSRP. This difference in behavior occurs because the parameters itemId and lumItemId are public on the page and this resource is not supported by the WSRP producer. In this case, it is necessary to customize the service using specific parameters for rendering detail interfaces, thus maintaining the same behavior between both executions.