Posts Tagged ‘hack’

Replace Collab’s horribly broken file uploader

Sunday, September 27th, 2015

While the entire WebCenter Interaction stack is now dead, there are still some of you out there using the legacy code because it “just works”.

As technology evolves, though, more and more pieces of the stack have started to crumble – including Collaboration Server’s multi-file upload. We’ve talked about issues with it in the past and hacked it more than once, but it pretty much just worked in IE7-9, and wasn’t even available in other browsers like Chrome.

So, enough was enough: in search of a better solution, I came across the awesome FineUploader product, which does an incredible job of allowing multiple uploads with virtually any browser (degrading properly based on available features of each browser), and doesn’t rely on any crap technology like Flash or Java.

Rather than completely re-inventing the wheel, I just cracked open the collab.war file and replaced the old crap code with new code leveraging fineuploader.com; uploads themselves are still processed the exact same way that the old java app used to use, so nothing is compromised in terms of features or security. It was really only a few files that needed to be changed, which alters the upload form that used to look like this:
collab-file-upload-java
… to now look like this:
fine-uploader-collab-upload
(more…)

Fix WebCenter Studio Server for IE11

Thursday, September 24th, 2015

IE11 has caused all sorts of problems in the WebCenter Interaction stack thanks to its new new User-Agent header that these legacy products can’t parse.

Today’s issue is how to fix Studio Server. If you’re seeing this exception in your logs, it’s because Studio can’t parse the user-agent string:

StandardWrapperValve[gatewayservlet]: Servlet.service()
for servlet gatewayservlet threw exception
java.lang.StringIndexOutOfBoundsException:
String index out of range: -1
at java.lang.String.substring(Unknown Source)
at com.plumtree.studio.util.BrowserInfo.parse(BrowserInfo.java:334)
at com.plumtree.studio.util.BrowserInfo.(BrowserInfo.java:137)

You could just use Compatibility View, but that’s not always an option when you have a ton of end-users. Instead, I opened up the studio.war file and recompiled in a fix that wraps a try-catch block around this bad code, and simply says “if I can’t figure out what browser is being used, assume it’s legacy IE.”. The class file is at com.plumtree.studio.util.BrowserInfo:

try {
  .... regular legacy browser parsing ...
}
catch (Exception e) {
   browserName = "MSIE";
   browserVersion = 6F;
   browserPlatform = "Windows";
   jsControlsOK = true;
}

Drop me a line if you’d like the replacement class file to use in your version of studio.war.

Using WebCenter Publisher with Internet Explorer 11

Tuesday, May 26th, 2015

The release of Internet Explorer 11 has caused a unique set of issues for WebCenter Interaction. We’ve covered some WCI portal hacks and Collaboration server hacks to work around some of these challenges; today’s post is about Publisher.

First off, you’ve probably noticed that Publisher doesn’t work with IE11:
publisher-ie-5.5
The solution to this problem is simple: Go to Tools: Compatibility View Settings, and add your portal site to the list:
compatibility_list_ie11

This will enable “Compatibility Mode” for IE, which means that (among other things) the user agent string will contain “MSIE”, which lets Publisher use its antiquated user agent sniffing to enable Publisher Explorer:
publisher-explorer
The next one after the break isn’t quite so simple. (more…)

Using Collaboration Server with Internet Explorer 11

Friday, April 3rd, 2015

Webcenter Collaboration 10gR4 was released in May 2013. Internet Explorer 11 was officially released in October/November of that year. Why is this a problem? Because, since Oracle has killed the entire product line, users are left high and dry with compatibility issues, getting a degraded version of Collab Explorer that’s missing key features like Bulk Upload:
collab-ie-11

Why is this? Because the abomination known as Internet Explorer threw developers yet another curveball in IE11: they changed the user agent string to one that doesn’t contain the characters “MSIE”. Sure, Oracle can be faulted for not following best practices on browser detection, but we’ve thrown enough angst Oracle’s way in this blog; it’s Microsoft’s turn today. I mean, they’ve used MSIE in their user agent strings for literally TWENTY YEARS; of course they should change it now to:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko

The solution is yet another Collab Hack requiring you to decompile code. Specifically, in collab-core.jar, we need to update com.plumtree.util.http.BrowserUtil.java. There are two places in the code that need to be updated; you’ll note I didn’t even attempt to implement a generic solution, but am specifically looking for this IE11 user agent string. That, of course, is not completely future-proofed, but since WCI is basically dead, and IE is getting killed off, I’m not too worried. The updated code will look something like this:

    private static float parseVersion(HttpServletRequest request, String searchPattern)
    {
        String userAgent;
        userAgent = request.getHeader("User-Agent");

	if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
		return 11.0F;
	......

… and:

    public static String GetBrowser(HttpServletRequest request)
    {
        if(InStr(request.getHeader("User-Agent"), "MSIE"))
            return "IE";
        else {
	        if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
				return "IE";
			else
	            return "NS";
		}
    }

(more…)

The Dreaded Collaboration Search Index Rebuild

Wednesday, March 18th, 2015

Does the following screen shot fill you with dread?
collab-search-rebuild

If so, you’ve likely one of us who have had the dubious displeasure of having to work with the terribly bad “Collab Reindexing” functionality, where you ask Collab to rebuild the contents of the search index – usually after a migration or upgrade. The problem is that Collab can store hundreds of thousands of documents, and this process tends to fail, fill up disk space, or do various other terrible things like kidnapping your hamster and holding it for ransom. When any of those things happens, you have to just start over from scratch and pray harder next time.

I recently did a WebCenter 10gR4 migration/upgrade because Windows Server 2003 is approaching end of life in July, and we wanted to upgrade to Windows Server 2008 without jumping through any crazy hoops that Oracle wouldn’t support in 10gR3. The 10gR4 support matrix indicates Windows 2008 (x86 and x64) support for WCI 10.3.3, Collab 10.3.3, and Analytics 10.3.0.2 (don’t ask why the versions aren’t the same, or why Publisher is now technically unsupported for those upgrading to 10gR4). I won’t even rant here about how terrible the installation process was, resolving error after error and manually installing services and deploying web apps, but the Collab Search rebuild deserves a special place in hell.

First, let’s get the “good news” out of the way since there isn’t much of it: in Collaboration Server 10gR4, there’s now an option to re-index only the documents that haven’t been submitted to search yet because the process just exploded. Which is super. While I’d prefer the process not “explode” all the time, I’ll take what I can get: restarting the process at document 110,000 out of 230,000 is much better than restarting at document 1.

The bad news is that the process still fails all the time, despite claims of fixes and notes of “re-breakings” (Oracle bug – login required). The logging is terrible (hint: you can tweak some log settings by cracking open the Collab .war file and changing log parameters there, and you can turn on the following in PTSpy – in addition to “Collab” and “SearchService” – to get a more accurate picture of this bizarrely convoluted process: ALUIRemoting, Remoting, dummy, Configuration. When the search rebuild process fails, you can no longer access Collab Administration (because it seems the first thing it tries to do is connect to the Search Service, and that’s dead now). And the errors that show up aren’t even consistent over time. You’re likely to see a ton of different errors after a period of time, usually with the remoting process:
jms-connection-failed
This error seems to be quite common though:

javax.jms.JMSException: Exceeded max capacity of 50

What can you do about this? I changed the transport protocol for the Collab Search Service from TCP to HTTP and it cleared up the problem, although for the life of me I can’t tell you why. Read on for details of how to do this yourself… (more…)

Fix WCI Publisher Search with a simple tweak

Saturday, October 11th, 2014

Ever seen this error in WebCenter Publisher when using Friendly URLs?

INFO | ERROR java.lang.StringIndexOutOfBoundsException: String index out of range: -1
INFO | ERROR at java.lang.String.substring(String.java:1768)
INFO | ERROR at org.apache.jsp.published_005ftools.search_jsp._jspService(search_jsp.java:101)
INFO | ERROR at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
INFO | ERROR at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
INFO | ERROR at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)

Yeah, it’s not the first time that Friendly URLs breaks existing functionality, and like that Excel issue, fortunately the fix is pretty easy. Basically, you’ll need to open up the ptcs.war file and edit the /published_tools/search.jsp file in there. Specifically, there’s a section that looks like this:

       String baseURL = (cspRequest.getReturnURI().toString());

       //SE-VV: 57027 - With the recent portal code changes in Merced, the string "gateway"
       //is not present in the baseURL anymore. As a workaround, we instead look for "?" so that index is a 
       //non-negative integer. Now, when we search for a CI from within a news portlet, it'll take us to
       //the correct search results page instead of throwing an error.
       int index = baseURL.indexOf("gateway");
       if(index < 0){
              index = baseURL.indexOf("?") + 1;
       }
              baseURL = baseURL.substring(0, index - 1);

(more…)

Hidden reset flag for WebCenter Interaction Analytics

Tuesday, March 25th, 2014

Recently I worked on a migration from some WebCenter Interaction servers to a virtual environment (you’re still using physical servers? How 2013…).

After the migration, there were some documents that weren’t showing up in WebCenter Analytics reports. As you probably know, Analytics events are stored in the ASFACT tables using objectIDs, and information about those events are captured in the ASDIM (dimension) tables to record information about those objectIDs (it’s done this way so that, even if you delete the object in the portal, you don’t lose the record of its access). But during some extensive testing, logging, and code decompiling, I discovered some interesting things that may be useful to you:

  • You can dramatically increase the logging that the Analytics sync job writes by changing the log settings to DEBUG in %PT_HOME%\ptanalytics\10.3.0\settings\config\sync-log4j.properties. This will give you details all the way down to the exact queries being run against the database.
  • The number of objects synched to the dimension tables, along with the results of the synch jobs, are stored in the ASSYS_JOBLOGS table – and that table is never cleared:
    wci-analytics-jobs
  • The Analytics Sync jobs that run nightly to update those dimension tables don’t actually look at all objects in the portal database; they look only look for objects that have been updated since the last time the job has run. This time comes from that ASSYS_JOBLOGS table.
  • There’s a hidden flag in the source code for the job called “-reset” that clears this job log table for that particular job entry, causing all objects for that job type to be re-scanned:
    wci-analytics-reset

Bottom line: if some of your Analytics reports don’t seem to contain all of the objects you’re expecting, it’s possible that events have been recorded but the dimensions simply don’t exist for them. If that’s the case, you can resolve this by adding -reset to the external operation in the WCI portal. Just remember to remove the flag after the job runs so that you’re not constantly clearing the logs every night and generating unnecessary load. (more…)

Running Plumtree Portal on IIS7 and Windows Server 2008

Wednesday, September 19th, 2012

The latest version of WebCenter Interaction (aka Neo, or 10gR4) officially added support for IIS7 and Windows Server 2008. But WCI 10gR3 – or (gasp!) Aqualogic User Interaction or Plumtree don’t since IIS 7 didn’t exist way back then. We’ve discussed how to get these older revisions working on 64-bit Windows, but many of you don’t have the luxury of upgrading Plumtree or have cancelled your support and maintenance contracts (and, if you haven’t, why not?) .

Still, time marches on, new application servers and operating systems are introduced, and your server team is antsy to get you to upgrade what you can. So, today’s post is about getting older versions of WCI working on IIS7 and Windows Server 2008. It’s – of course – not officially supported, but from my testing with WCI 10gR3 it seems to work OK. Your mileage may vary, and I can’t say I’ve actually supported a production environment running 10gR3 in this configuration yet, so proceed at your own risk.

The problem starts with the portal installer – you’re likely to see something like the following lines in your error logs:

“E:\bea\alui\installlogs\portalappserver_deployment.log”(51,13): [echo] ERROR: Web Site Default Web Site does not exist. Virtual directory cannot be created.
“E:\bea\alui\installlogs\WebCenter_Interaction_InstallLog.log”(38038,51): Additional Notes: FATAL ERROR – ANT post-installation action returned an error. See e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_config-setup.log for details.
ANT Post-install Check:
Status: FATAL ERROR
Additional Notes: FATAL ERROR – ANT post-installation action returned an error. See e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_config-setup.log for details.
ANT Post-install Check:
Status: FATAL ERROR
Additional Notes: FATAL ERROR – ANT post-installation action returned an error. See e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_setup-service.log for details.
e:\bea\alui\uninstall\ptportal\10.3.0\register\configmgr_setup-service.log:
BUILD FAILED
E:\bea\alui\uninstall\ptportal\10.3.0\register\register-configuration-manager.xml:191: java.io.FileNotFoundException: E:\bea\alui\configmgr\2.0\bin\configmgr.url (The system cannot find the path specified)

Basically, this is telling you that the installer wasn’t able to deploy the web app to IIS7. But, it does copy all of the appropriate files, so they’re ready to be deployed manually. Read on for the steps to get started in getting your old portal working with the latest IIS Application Server… (more…)

Viewing Experience Definition Debug Page

Saturday, November 12th, 2011

Recently we discussed the Experience Definition Debug page. It’s pretty straight-forward: turn on debug mode in Portal Administration, then click the “Show Debug Messages” link that shows up in the WCI header.

But, what if you’ve customized the portal navigation and aren’t using the out-of-the-box header bar? We’ve gotchya covered – there are actually three ways this can be done.

Add the Adaptive Tags to your own header
The following code comes from \imageserver \plumtree\portal \private\pagelayouts \basepagelayout.html. You can stick this code into any header (or footer, or portlet) to get the Debug link to show up, and it will only show up for the appropriate users.

    <pt:core.comment><!-- DCA - get the Rules Debug link; if we don't have access to the rules debug page, the variable won't exist --></pt:core.comment>
    <pt:ptdata.rulesdebugdata pt:id="rulesDebugLink" />
    <pt:logic.existexpr pt:data="rulesDebugLink" pt:key="canAccessRulesDebug"/>
    <pt:logic.if pt:expr="$canAccessRulesDebug">
        <pt:logic.iftrue>
            <pt:core.comment><!-- DCA - there should only be 1 --></pt:core.comment>
            <pt:logic.foreach pt:data="rulesDebugLink" pt:var="link">
                <li><pt:core.html pt:tag="a" target="_blank" href="$link.url"><pt:core.html pt:tag="img" src= "pt://images/plumtree/portal/private/img/icon_subportal_rule.gif" alt="$link.title"/></pt:core.html><pt:core.html pt:tag="a" target="_blank" href="$link.url"><pt:logic.value pt:value="$link.title"/></pt:core.html></li> &amp;nbsp;|
            </pt:logic.foreach>
        </pt:logic.iftrue>
    </pt:logic.if>

Access the URL
The debug Messages page is available at /portal /server.pt? open=space &name=RulesDebugMSGAS. You can just drop that URL in there and the browser should display the debug page if you have access.

Use the MemoryDebug space
Finally, the portal session object stores this information so that it can be accessed through the MemoryDebug page we’ve discussed before. Just flip your URL to /portal /server.pt /debug /memory and you’ll see something that’s a little less readable, but still a functional alternative to the above two methods:

One caveat to all of these methods is if you have Community-based rules. Because sometimes the debug page itself applies its own URL for the rules, in some cases that means you’re no longer in any communities, so that could mean you get a false-negative for that condition. Your mileage may vary.

What Experience Definition is being applied?

Sunday, November 6th, 2011

In Plumtree they were called Subportals. In Aqualogic the name was changed to Experience Definitions, and they continued to evolve in WebCenter Interaction with the introduction of Adaptive Layouts.

Experience Definitions are useful constructs in the portal that allow you to customize the header/footer, navigation, and Adaptive Layouts based on Experience Rules – which can be applied based on the host IP, community, user/group, or user-agent header. So you can apply different rules based on any of those criteria and heavily customize the experience based on any of those conditions.

An useful feature that was introduced with Experience Definitions was the “Debug Mode”, which can be accessed from Administration -> Select Utility -> Portal Settings -> User Settings Manager:

When this option is selected, a new link for “Show Debug Messages” is shown in the standard topbar, or in the out-of-the-box Adaptive Layout:

From this link, you can see the “Rules Debugging Messages”, which explains each rule, whether it matched the condition, and how long the evaluation took: