Skip to Content

Being able to set iView properties at runtime is a particularly useful thing. I was originally forced to think about a method to achieve this back in the EP5 days when I needed a way to easily determine some iView properties “on the fly”. I wanted to be able to have one iView that was assigned to everyone in the portal but I wanted the iView to behave differently based on the groups a user belonged to.

The solution I came up with was much like the one proposed by Detlev Beutner at SAP Tech Ed 06 in the SDN session Implementing Dynamic iView Properties, but I think differs just enough to warrant this blog. In essence the architecture is the same. Firstly you create an iView (proxy iView) that “fronts” the target iView you want your users to see. In this proxy iView you can include logic to determine the values of any iView properties you wish to set at runtime. This is where I implemented the logic based on my users group membership.

The main difference is that rather then passing these values through as part of the URL request string (?param1=x&param2=y) you manipulate the component profile of the target iView directly in the proxy iView and then redirect the user to the target after setting the parameter values you require.

The code looks something like this…

//Get the context and profile for the target iView IPortalComponentContext ctx = request.getComponentContext("pcd://contentlib/"); IPortalComponentProfile profile = ctx.getProfile(); //Set the property values you want profile.setProperty("param1", "value1"); //Store the component profile for the user; //Forward user to target component... (this is just an example) response.write("");

This approach was much easier then creating multiple roles with different iView parameter configurations. It yields the same results as the method covered at SAP Tech Ed, but differs slightly in how the parameters are set. I recommend you take a closer look at the SAP Tech Ed session mentioned above and see if you can use the code here too. It should allow you to set any type of iView property.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Michael Nicholls
    Hi Simon

    Does this effectively make a delta linked iView for each user? What would be the effect with, say, 30,000 users? Would the tables storing the PCD start growing?


    1. Simon Kemp Post author
      Hi Michael,

      I don’t think it actually creates anything physically in the PCD – it all happens at runtime I believe. The component profile is stored in memory and I would hope is collected when no longer referenced (but maybe not). I did not see any performance issues when used at my clients, in fact in the case I used it for (UWL) performance was improved since no unnecessary calls were being made to backend systems the user actually didn’t have access to.

      Thanks for your comments,

      1. Detlev Beutner
        Hi Simon, hi Michael,
        Michael is absolutely right that the profile is (a) stored per user (that’s what the “store()” method is for) and (b) that this is done via PCD personalization, which in fact means more or less much DB access. For few users, that shouldn’t be a problem, nevertheless, that might be getting a problem if done for really many users (and maybe for several iViews).
        You can realize that quite easily: Take a navigation iView as target iView and set the “path” parameter individually per user. Then restart the server and call http://…/irj/portal?NavigationTarget=ROLES://portal_content/sdn/NaviViewExample with a user already used before (now not going via the proxy) – the memorized “path” property value will be taken.
        Nevertheless, I would consider this approach as a stopgap, if the approach I have introduced on SDN (and even deeper at TechEd) doesn’t work (if for example the target iView isn’t using the URL parameter). But one should be aware of the problems which may arise under certain circumstances.
        Best regards, Detlev

Leave a Reply