John De Binder commented on Jun 11, 2014

Editing the XML config file

I have just been notified that the referenced article "Leveraging WebSphere Portal V6 programming model: Part 5. Accessing portal content with custom URLs" has been archived and is no longer accessible. That article contained information about the DeeplinkManagementPortlet and the deeplinkConfig.xml file.

You can add the DeeplinkManagementPortlet to any page you wish. This will display the links that have been defined in the configuration file. The deeplinkConfig.xml file is in the following directory: DeepLinkResolver2EAR.ear\DeepLinkResolver2.war\WEB-INF\. You can modify this file, press the "Reload configuration file" button in the management portlet and see your new links.

Hope this clears up any confusion.

Pradeep Ruhil commented on Dec 20, 2012

Re: Passing query parameters to JSR-286 portlets using existing IBM WebSphere Portal capabilities

thanks, I got it resolved. Thanks again for nice article :)

Pradeep Ruhil commented on Dec 20, 2012

Re: Passing query parameters to JSR-286 portlets using existing IBM WebSphere Portal capabilities

Hi John De Binder

Thanks for a very nice article.It really helps.

I have successfully executed the deeplinkwar1 and got it working and running and also able to overide the parameters that your said.

But my problem is I want to execute the action phase of the portlet , but in the example it is always executing the render phase of the portlet.

As you have you have done some modification in deeplink2 war, so can you share me the code or the deeplink2 war which will help me to execute the action phase of the portlet.

I have tried lot of things, but still not able to execute the action phase of the portlet.

Please help

Thanks

Pradeep

John De Binder commented on Nov 16, 2012

Adding EAR to RAD

If you want to import this EAR/WAR into RAD you will need to add three JARs to your build path.

com.ibm.content.operations.registry.jar

wp.resolver.api.jar

wp.resolver.cor.api.jar

Johan Bladh commented on Aug 28, 2012

Keep some QS parameters in url after redirect from POC uri?

We have a requirement where we also want to keep some QueryString parameters in the url that will be redirected from the poc uri i.e. if the url look like this now /wps/poc?uri=gbglnk:&test=value we want the poc uri solution to resolve to the portal page with the unique name given as parameter BUT keep the &test=value in the QueryString after the redirection from the poc uri. We still want to create rendering parameters for some of the QS parameters that we send to the poc uri but not for all. We really can't find a solution for this.

Anyone knowing if this is possible?

Abraham Farris commented on Jul 12, 2012

Re: Passing query parameters to JSR-286 portlets using existing IBM WebSphere Portal capabilities

Ignore my last comment, there isn't a bug. I forgot to set the unique name on the installed portlet from the Custom Unique Names under Administration.

Abraham Farris commented on Jul 12, 2012

Re: Passing query parameters to JSR-286 portlets using existing IBM WebSphere Portal capabilities

Hello, thanks for the article it helped me create my poc solution. I did find a slight bug. In the collectChildren method in the DeepLinkResolver class you have:

PortletDefinition portletDef = portletModel.getPortletDefinition(portletWindow);

String portletUniqueName = portletDef.getObjectID().getUniqueName();

I believe this gets the uniqueName from the actual portlet definition from the install and not the portlet in the page itself. To get the actual portlet unique name on the page, I changed to:

PortletWindow portletWindow = portletModel.getPortletWindow((LayoutControl) node);

String portletUniqueName = portletWindow.getObjectID().getUniqueName();

This seems to work for me, hopefully saves some headache.

John De Binder commented on May 8, 2012

Re: Passing query parameters to JSR-286 portlets using existing IBM WebSphere Portal capabilities

Eduardo, please send me an email if you're still having problems. I would like to understand more about your situation. Is your resolver installed on the portal that references the remote portlets? Are the parameters null in the resolver or in the remote porltets? Does the resolver work for local portlets?

eduardo m milpax commented on Apr 12, 2012

Strange error on URI Resolver

Hi I found a problem on receiving params from url.

I have two websphere portal servers, first contains portlets itself, second contains a reomte reference to portlets of the first one.

URI resolver works perfect resolving URIs, but params(declared and tested on my local machine previously) are recieving null.

Any idea, I’m driving crazy, thanks

John De Binder commented on Jan 11, 2012

Re: Passing query parameters to JSR-286 portlets using existing IBM WebSphere Portal capabilities

Got the following question from a reader:

-------------------------------------------------------------------------------------

The user is navigating from one jsp to another inside a portlet on a given Portal page. Then they decide to click a link/button that re-directs them outside of Portal to a Canada revenue(CRA) agency web application. Now the user starts interacting with CRA web application in the same browser session. At some point during the interaction, they are presented a screen where they hit the submit button inside the CRA web application. The web application should then POST the form back to the Portal page having the portlet. The session on the Portal side should remain as they left it prior to moving to CRA site. Also, we need to fire the process action of the portlet in response to the submit on the form on the external web application. I did research on poc servlet functionality but I think it only is useful for “GET” and not “POST”. Also, we cant send any call back url to CRA as part of original request. The call back url has to provided to them separately and they register that in their db and assigns a partner id. We only send partner id in the request and then they can read the call back url and post it back to us accordingly.

I was thinking that we could write a “intermediate servlet” that reads the “post” from their web application and then invokes the POC servlet passing those extra parameters and then portlet could react appropriately. However, it wouldn’t be a process action it would be a render request. I am sure there is better way of doing than what I am thinking J

---------------------------------------------------------------------------------------------------

my answer:

It is true that the poc url is intended only for GET requests. The reasons are explained in my article. But the more important aspect is that you should not allow any request from outside the portal to cause a permanent side effect. i.e. don't allow a request from outside the portal to transfer money from one account to the other. That is what opens the door that allows one web site to hijack a users credentials for another web site.

So, if you do have the 'side' servlet that takes parameters from the outside application, changes something and then invokes the portlet that is really no different than just invoking an action on the portlet itself. You're still changing state.

That's why I added the ability to invoke a portlet action with the code in my article. What you have to be careful of is not completing or committing a transaction on the request from outside the portlet. It's ok if you simply change session state because the end user still has to click a button within the application to commit that state change permanently (i.e. to the back end).