Archive for May, 2011

Cool Tools 19: Frevvo Live Forms (with WCI Integration!)

Friday, May 27th, 2011

We’ve spent some time recently talking about AquaLogic Studio Server, and even got a tip from our buddy Geoff Garcia about the date Oracle officially stopped supporting it (November 2010).

So now what? You still have requirements to easily build forms and workflows and reports, but aren’t planning on a full move to another platform in the short term. Well, at a recent project where we’ve deployed Atlassian’s Confluence (also integrated with WCI), we came across this great form-builder plugin called Frevvo Live Forms.

In a word, it’s awesome – check out this quick demo (more videos here):

That got us thinking: what about using Frevvo as a replacement for Studio? We could develop the integration so that forms could be added as portlets and administered just like Studio. It’d do everything Studio can (integrate with portal security settings, custom-define forms and fields), have great new features (new data types, drag-and-drop form building, workflows), and, well, it wouldn’t suck like Studio.

So, that’s exactly what we did:

Interested in how to dump Studio and move on to a more powerful form-builder with workflows and much cooler reports? Contact us.

Prevent Analytics From Logging Gigabytes of Data

Wednesday, May 25th, 2011

This one comes courtesy of Fabien Sanglier, a WCI guru of epic proportions (no, he didn’t make me say that…).

At our client site, we noticed that Analytics was logging gigs worth of data to the weblogic.out file – a catch-all file for logging reported via the standard out pipe. Note that IIS doesn’t record logs on this stream, so this is a Weblogic-only problem. The line recorded over and over (one for each hit):

OPENUSAGE(INFO ): ==> Event sent to: //UsageTracking@openusage/ wci-analyticscollector| port=31314/ BYTEARR

To prevent these events from being logged, he suggests updating %PT_HOME%/settings/configuration.xml to reduce logging and turn off console logging:

<component name="analytics-communication:config" type="http://www.plumtree.com/config/component/types/analytics-communication">
<setting name="logging:level">
<value xsi:type="xsd:string">WARN</value>
</setting>
<setting name="console-logging:enabled">
<value xsi:type="xsd:boolean">false</value>
</setting>

</component>

(more…)

Increasing the Character Limit for ALI Studio in SQL Server

Sunday, May 22nd, 2011

By now you’re aware of our stated problem – we need to increase the size of text fields in Aqualogic Studio. We’ve already found the file used for the JavaScript, and used a new Cool Tool (HxD) to assist in the recompile, but there’s still a problem: when Studio creates new forms, it also creates a separate table in MS SQL Server. And the size of text fields in those tables that already exist is still 1,000. So if we just update the Javascript, our existing forms aren’t going to have the proper error checking, because our JavaScript is preventing field sizes of, say, 10,000 characters, but at the database layer, the size of those fields is still 1,000 characters. Even worse, if you try to increase the size of the table in the code to >4,000 characters, SQL Server will reject it because the regular nvarchar data type doesn’t go over that limit:

2011-04-21 14:54:54,819 ERROR [rocessor25] AppDesignerHandler: Error processing wizard form post
Error creating new user database ‘Survey Database’.
– [XNRC39]The size (10000) given to the column ‘test_10000’ exceeds the maximum allowed for any data type (8000).
at com.plumtree. studio.model.data. access.TableDAOSQLServer.create (TableDAOSQLServer.java:220)
at com.plumtree. studio.model.app. Table._create (Table.java:585)
at com.plumtree. studio.model.app. Table.save (Table.java:618)

So, we have two problems: first, we need to tell Studio to create these fields with a type of NVARCHAR(MAX) rather than NVARCHAR(10000), and second, we need to update all existing tables.

The first problems is pretty straightforward – we just need to update the TableDAOSQLServer.java file (or, if you’re on Oracle, TableDAOOracle.java). Change:

      sqlBuffer.append(this.mUserColumnType).append("(").append(this.mUserColumnWidth).append(") ");

…to:

      sqlBuffer.append(this.mUserColumnType).append("(MAX) ");

… and recompile as mentioned in the last post.

The second problem requires some SQL Server voodoo – we need to write a SQL Script that generates a SQL Script. So, if you run this script as your studiodbuser:

SELECT 'ALTER TABLE ' +  syo.name 
    + ' ALTER COLUMN ' + syc.name + ' NVARCHAR(MAX);'
   FROM sysobjects syo
   JOIN syscolumns syc ON
     syc.id = syo.id
   JOIN systypes syt ON
     syt.xtype = syc.xtype
   WHERE 
     syt.name = 'nvarchar' 
    and syo.xtype='U'

… it will produce a SQL Script that looks like this:

ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN Additional_Comments NVARCHAR(MAX);
ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN U__Is_the_work_proceeding_i NVARCHAR(MAX);
ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN U__Is_progress_towards_the_ NVARCHAR(MAX);

So basically, you’re using s script to find all the existing text fields, and creating a new one to actually increase the size limits on those fields.

Cool? Cool.

Cool Tools 18: HxD Hex Editor

Thursday, May 19th, 2011

Continuing our journey on increasing ALI Studio’s character limit, we’ve now identified the code that needs to change – it’s in com.plumtree. studio.model. data.access.TableDAO.java.

The problem is, Studio is ancient, so while we can easily update the following code:

  protected int mUserColumnWidth = 1000;
  protected int mUserColumnWidthChars = 1000;

… we can’t just recompile the file using the latest JDK without expecting problems.

So, we need to figure out what Java version was originally used to compile this file. To do this, we need today’s Cool Tool: HxD Hex Editor. Why? Because all Java .class files have the same set of bytes at the beginning identifying them as Java files, along with the JDK version used to compile.

HxD allows us to view the actual bytes, and and it does it well. Opening the TableDAO.class file in HxD, we see:

Bytes 6 and 7 are “00 2E”, which represent JDK 1.2.

Once we’ve made our changes and have the correct JDK downloaded, we rebuild the file, making sure to include the proper .jars in the CLASSPATH:

set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\log4j-1.2.8.jar
set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\jakartaRegexp1dot2.jar

C:\jdk1.2.2\bin\javac -classpath %CLASSPATH% com\plumtree\ studio\model\ data\access\ TableDAO.java

Take the TableDAO.class file, jam it back into your studio.war file, and you’re good to go – assuming you haven’t increased that value over 4,000 characters! There’s still one more glitch in this journey

Increase Plumtree Studio Character Limit

Monday, May 16th, 2011

We don’t write much about Aqualogic Interaction Studio ’round these here parts anymore. That’s because Studio has long since been end-of-life’d (by BEA, even before the Oracle acquisition!). But, that doesn’t mean it isn’t alive and gasping its last breath in many of your portal sites. Sure, it’s an over-the-hill product but it does serve a functional need: the ability to easily create forms, polls, and other data entry forms.

So, it’s with reluctant enthusiasm that I start the first of a three-part series on “How to increase the 1,000 character limit in Plumtree Studio”. Even if you don’t actually use Studio, hopefully you’ll find the journey interesting and informative for your other portal diagnostic needs. I’ll walk you through the process of identifying the code here, recompiling and reintegrating in Part dos, then some SQL Server diagnostics in Part tres.

The problem, as recently presented by a client, was that Studio has a 1,000 character limit on text fields. If an end user tries to type more than 1,000 characters, they get this lovely message:

But, we needed to increase that value. While it would be really nice if there was just some configuration file somewhere, sadly, the 1,000 character limit is hard-coded. So we first need to find the file that’s producing this alert. (more…)

100% CPU in Collaboration Server on Solaris?

Tuesday, May 10th, 2011

Today’s post comes from a Rock Star Consultant in the WebCenter Consulting space.  It has to do with WCI Collaboration Server consuming 100% CPU on Solaris, but might be relevant to those Windows users out there.  While I personally haven’t experienced this particular issue at client sites (virtually all of them Windows), it sounds like if you’re running Collab in Unix, it might be worth upgrading your JVM.

Problem:

Collab periodically starts chewing up CPU until it maxes out the box and ultimately dies.

Details:

This looks to ultimately be a problem at the JDK level.  Out of the box, the Tomcat Collab is deployed to uses JDK 1.5.  There’s a bug in JDK 1.5 that causes the NIO connector in tomcat to sometimes freak out, resulting in Collab spinning out of control and eating all the server CPU.  For details, see this thread:

http://www.mail-archive.com/users@tomcat.apache.org/msg36900.html

Diagnosis:
Here’s the rundown on the diagnosis we did (Collab on Solaris)

Symptom:
Collab is eating up a huge amount of CPU minimal user load(80%+ on a server where it usually uses ~10%).

Troubleshooting performed:
1) Generated a stack trace for Collab
2) Run prstat -Lp <Collab Pid>.  This shows us how much CPU each thread in Collab is taking. Note that the top three threads in the attachment are taking up 22% of the CPU each.  Also note that those threads have used a huge amount of CPU time: 3-4 hours each).

3) Note the LWPID of each of the busy threads:  6248, 3413, 8198.
4) Now convert those numbers to Hex:
6248 -> 1868
3413 -> d55
8198 -> 2006
5) Now look for those hex thread ids in the thread dump.  You’ll see they all have the same stack (for example: nid=0xd55).  Specifically:

—————————

“http-7127-exec-23” daemon prio=10 tid=0x00000001008ee360
nid=0xd55 runnable [0xfffffffeff0fa000..0xfffffffeff0ff728]
at org.apache.coyote.http11. InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:610)
– waiting to lock <0xffffffff40927c48> (a org.apache.coyote.http11.InternalNioOutputBuffer)
at org.apache.coyote.http11. InternalNioOutputBuffer.access$000(InternalNioOutputBuffer.java:44)
at org.apache.coyote.http11. InternalNioOutputBuffer$SocketOutputBuffer.
doWrite(InternalNioOutputBuffer.java:794)
at org.apache.coyote.http11. filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:126)
SNIP

Again, note that all the stack traces are the same and they appear to be trying to flush/close and output stream, but it looks like they’re blocked.

Fix:
Update the Collab JVM to a recent release of the 1.6 JDK (1.6u23 for example).  Restart Collab

Results:
Prior to change, Collab was crashing multiple times a day and using at least 20% of the CPU on a beefy Solaris box.  Post change, no Collab crashes, and Collab is pretty consistently using about 4% of CPU on the server.

WCI Analytics Startup Order

Saturday, May 7th, 2011

If you’re using WebCenter Analytics, you’ve no doubt seen this issue before:

The Analytics Context could not be created.  This is typically due to a configuration problem.  Review the Analytics UI log for more information.

While there are many causes for this and many fixes such as re-scripting the security database, sometimes the simplest solution is overlooked: startup order.

When Analytics needs to be (re)started, the services need to be restarted in the proper order:

  1. WSAPI Server.  The API Server provides SOAP access to the portal objects, such as users.
  2. LDAP Directory Service.  The LDAP Directory Service connects to the API Server to surface Plumtree users and groups via LDAP.
  3. Analytics UI.  This is the service that ultimately provides all the fancy reporting, and can’t work without the other two already set up, since it needs to check credentials (which introduces its own set of problems):

As a side note, the Analytics Collector doesn’t require the API or LDAP service.  It simply accepts inbound events such as searches and logins via UDP from the portal and records themto the database.  It’s a good thing that the services are separate, since even if the UI isn’t working, in most cases you can be reasonably confident events are still be recorded and not lost forever.

 

Cool Tools 17: WordPress 3

Wednesday, May 4th, 2011

Blogs and Wikis, Wikis and Blogs.  We’ve been hearing it from Plumtree, then from BEA, and now from Oracle for the Plumtree/ALUI/WCI stack.  Remember PEP (Pages, Ensemble, Pathways), and how it promised wiki and blog functionality?  And how ’bout this semi-official Oracle WCI blog that … well, you be the judge.

It’s true:  Plumtree has a checkered past in delivering us to the promised land of user-generated content in the early noughties – to say nothing of the Enterprise 2.0 (Social Networking) trend of the past couple of years.  The WebCenter Suite promises to start getting us there, and there are unconfirmed rumors of WebCenter Collaboration Server getting this much-needed functionality, but for now user-generated content remains largely a pipe dream for those clients still on the WebCenter Interaction stack.

We all have blogs and wikis, so why haven’t we seen a serious contender for one of these products to work well in the WebCenter Interaction stack?  The answer is maybe that we’re looking for too tight of a coupling from Oracle:  the reality is that if you follow the Four Tenets of Portal Integration, you can provide a pretty compelling and integrated experience for your users, which is exactly what we’re doing with this blog and demonstration site:  notice how the URLs of this site change as you click through the tabs at the top?  That’s because some pages come from WebCenter Interaction, and some from WordPress – but the user (that’s you!) is none the wiser.  Administrators (that’s me!) love it:  in addition to the insanely easy setup and configuration and the vast library of third party plugins that can do pretty much anything and everything you might need, there’s also an almost comically easy upgrade process:

That’s right, WordPress knows when it’s out of date, and prompts you to update. Seven seconds after clicking “upgrade Automatically”, we’re all done:

 

Try upgrading WCI in 7 seconds!

Oh, and while this blog isn’t demonstrating integrated search or authentication, we’ve got that too