So you, the Plumtree / AquaLogic / WebCenter admin, get a call from a user indicating that Collab email notifications are not being sent (a plausible symptom that the Collab Notification service is in "stopped" status), or that Publisher is not responding (an indication that the Publisher service might also be down), alternatively Portal searches yielding no results (a sign that the search server is down) ... the issues that a Portal admin can encounter are just myriad.

 

Ideally, we shouldn't be notified from our users that an issue has occurred.  Granted there are a number of monitoring software in the market; e.g. Microsoft Operations Manager that monitors disk space, memory and CPU utilization, among other tasks, presenting the results in console like dashboards, yet we haven't seen a monitoring software dedicated to guarding a Portal deployment alerting its admin staff of potential issues.  Hence, the impetus for Watcher, a software monitoring tool dedicated to watch a Portal installation.

 

Watcher is created to run different types of monitors (currently 10 different rules) for a typical Portal install; these include:

 

1.      "Service" monitor to check if a particular daemon service has stopped and it attempts to restart it.

2.      "File Size" monitor to check if log files have reached a particular threshold size and ensure that the Portal admin is alerted if the size is within a predefined threshold.

3.      "Disk Size" monitor to check if a hard drive has reached a certain threshold size.

4.      "Directory Size" monitor to check the size of a folder.

5.      "File Text" monitor to check if a specific text string has occurred within a log file.  That can be useful to skim through a log file and search for a particular error string.

6.      "HTTP" monitor to check that the Portal URL is responsive and is returning a response within a given time threshold and that the HTTP request status code is 200 (OK).

7.      "Ping" monitor to ping a given host and ensure that the host is reachable within a given time threshold.

8.      "TCP" monitor to telnet a given host and send a command and parse the response.

9.      "Database" monitor to send different SQL statements and validate the result again specific thresholds; e.g. number of records in the ptUsers table should not be less than an "x" number thus indicating that the Active Directory Web Service has successfully executed.

10.  "Search Server" ensuring that all search nodes are in "Run" state.

 

The Watcher architecture is comprised of three components:

 

1)      A lightweight agent deployed as a service with a low footprint in terms of CPU and memory utilization running different monitors that can are configured as needed; i.e. different types of rules.

2)      A server console that receives the monitoring results from the different agents via HTTP requests.

3)      A notification service that alerts the admin of issues if a particular issue or threshold is encountered.

 

Watcher is shipped with preconfigured rules that can be further tailored as needed.  It can also be configured to monitor non Portal related services, database instances, hosts, URLs, etc.

 

To receive further information or schedule a demo, please contact us at info@function1.com

 

 

Thanks.

 

Hani

 

Hey all!

Over the last few months, I've had 2 customers run into 2 separate limitations with the Oracle Web Center Interaction(WCI) product, namely in version 6.1 MP1.  The first of the two cases I had run into previously, so that prompted the idea for this post to share and build a running list of these limitations.  The second of the 2 cases led me to dig deeper to find the reason for these constraints.  What are these limitations you ask?

Well for example, if you're working with ALUI 6.1MP1, did you know that the maximum number of pages created within a community is 25?  Or that a community cannot be created within a folder more than 10 levels deep?

Some of you may be thinking: why would you want to create more than 25 pages.  In my customer's case, their requirement was to have more than 25 pages organized within a community but have the majority of the pages hidden in the navigation.

These fixed values are actually hard-coded in the portal server library (a.k.a plumtreeserver), which I coincidentally covered in my last post.  In particular, it's in the com.plumtree.server.PT_SERVERCONSTANTS class.  It seems as if Oracle is moving towards getting rid of some of these unnecessary constraints.  For example, the constraint on the number of community pages has been removed in 10gR3.  If you're on an earlier version or if you hit another similar limitation, you have 2 simple choices but only one is a viable long term one.  The first option would be to decompile the classes in the plumtreeserver.jar (or DLL for the .Net portal), modify the settings and rebuild the library.  However, this option is not ideal as this would complicate product upgrades and Oracle support contracts.

The best approach is to try to look for some other workaround for these constraints.  For the second limitation with admin folder levels, this still remains in 10gR3.  One possible solution is to create a flatter taxonomy so that more subcommmunity levels can exist.  If this isn't feasible or no other options are available, you may be faced with replacing the fixed value in the portal server library.  Again, we advise you do this only with extreme caution.  Please contact us if you'd like more information.

The initial idea behind this article was not the workarounds, but to create a running list of these "hardcoded" limitations within the WebCenter Interaction product stack and the respective workarounds.  I've started the list off, but please post your comments on other limitations that you have run into along with any solutions.  I'll be updating this post with all of the comments, so please submit any that you have found even if a workaround wasn't.

Portal Limitations

Limitation		Workaround
Cannot create more than 25 pages within a community (in ALUI 6.1 MP1 or earlier)		Create the pages in another community and move them into the target community.
Maximum number of MyPages is 6		None found yet!
Communities cannot be created within a folder which is "10 deep"		Restructure the taxonomy to gains some levels back
Maximum length for the name of a document in the knowledge directory is 255 characters		None found yet.
Maximum folder level in the Knowledge Directory is 28		Restructure the knowledge directory taxonomy when the limit is reached.

thanks,

Vasanth

Howdy all.  Hope the nice weather is finding happy, healthy, and allergy free. As we were doing spring ALBPM house-keeping with a client the other day, we stumbled upon a bit of a problem with the way that BPM loads some images.  This led us to go digging into how the ALBPM->Portal integration works.  And anytime I get a reason to dig into the guts of software, it usually ends up as a blog post....hope you enjoy.

<context-param>

<param-name>com.bea.opencontrols.IMAGESERVER_URI</param-name>

<param-value>http://your.imageserver.url/bpmContext</param-value>

</context-param>

• You'll also need to copy the following directory into your bpmContext folder of your imageserver:

$BPM_HOME/enterprise/webapps/workspace/opencontrols/plumtree

• Bounce the BPM workspace after making the changes above and you should see a marked improvement in workspace performance

https://portal.foo.com/gateway_noise/bpm_portlet_server:123/workspace/jsf/menu/WebResource.resource?r=/a/path/to/an/image.gif

bpm_portlet_server:123/workspace/jsf/menu/WebResource?r=/a/path/to/an/image.gif

bpm_portlet_server:123/workspace/jsf/menu/WebResource?r=/a/path/to/an/image.gif

http://bpm_portlet_server:123/workspace/jsf/menu/WebResource?r=/a/path/to/an/image.gif

<cd $BPM_HOME/webapps/workspace/jsf/>
<Look around at a million different files that aren't very insteresting>
<Stumble upon .../workspace/jsf/view/viewPresentationNormal.xhtml>

<Open viewTableCell.xhtml>

fn:getImage('ATTACHMENT_ICON')

OK, so we've finally managed to dive down to the where the app is making calls to get images. <Quick timeout to pat myself on back and IM friends a steady stream of profanities about how ridiculously ALBPM is built>.  Now, that fn: prefix is a tag libarary.  Let's see what taglib is being used.  Obviously that stupid taglib isn't included in hasAttachments.xhtml, that would be too simple.  So backtrace through the xhtml files until we get to viewPresentationPanel.xhtml which includes that line:

xmlns:fn="http://bea.com/bpmWorkspace/functionsLibrary

Now to find where the actual code for this taglib lives...BACK to web.xml

/WEB-INF/facelets/bpmWorkspace.taglib.xml

fuego.workspace.jsfcomponents.FacletsFunctionLibrary

jar -xvf fuego.jsfcomponents.jar

oc:someMethod

So let's see what the oc: tag library is all about.  ViewPresentationNormal.xhtml was nice enough to include the line:

xmlns:oc="http://bea.com/opencontrols"

Back to our old friend web.xml.

jar -xvf opencontrols.jar

jar -xvf fuego.workspace.jar

jad workspace/jsfcomponents/WorkspaceTableRender.class

grep -i image WorkspaceTableRender.jad

grep -i img WorskpaceTableRender.jad

String urlBase = "/plumtree/common/private/opencontrols/image/table";

jad com/bea/opencontrols/XPResourceRequest

<context-param>

<param-name>com.bea.opencontrols.IMAGESERVER_URI</param-name>
<param-value>http://your.imageserver.url/bpmContext</param-value>

</context-param>

You'll may have noticed that I referred to "we" several times in the text above.  No, I haven't started referring to myself in the royal third.  I actually had a partner in crime for some of this debugging exercise.  Some of you may know him as Howard, some of you might refer to him as Ross, but I just call him HRoss.  In any case, he's one of the best portal consultants still working directly for Oracle.  So if you're still shelling out the big bucks for an Oracle consultant (rather than a more reasonably priced alternative *cough* Function1 *cough*), ask for him by name.

These are exciting times with Aqualogic (ALI) and its direction as a Portal technology after Oracle's acquisition of BEA Systems.  Some of our ALI clients have decided to migrate off ALI's Content Management System (CMS), Publisher, and adopt a different platform; e.g. Adobe Contribute. While others are embracing the new Portal CMS Web Center Interaction stack, more specifically, Universal Content Management (UCM) as a Publisher alternative as they migrate from their existing CMS; e.g. Dynamic Site Framework. Each organization has its unique set of requirements and IT governance that define its decision.  But, under any circumstances, the task of migrating content into Publisher or out of Publisher doesn't have to be a manual or laborious task. 

Since the Portal's inception during Plumtree days, a set of APIs were provided to programmatically interact with the underlying Portal objects.  The API's name might have changed through the product's evolution - Enterprise Development Kit 5.x (EDK) during Plumtree days, Interaction Development Kit (IDK) 6.x during the portal's short lived years with BEA and it seems that Oracle will retain the IDK name as it just prefixed it with "Oracle WebCenter" and just changed the version numbering to 10.x Yet, the concept remains unchanged: a set of interfaces for Portal objects - portlets, documents, projects, folders, communities, security groups, etc.)

With that said, we compiled a high level example of how to programmatically import content items from an external CMS to UCM/Publisher. In a subsequent example we will address how to export content items from Publisher/UCM to HTML and then load these to a target CMS while leveraging its intrinsic API set.

//initially we want to establish a remote session to the portal where soapConnectionURL is web service end point
IRemoteSession remoteSession = RemoteSessionFactory.getExplicitLoginContext(
new URL("http://YourPortalserver/ptapi/services/QueryInterfaceAPI"), yourUserName, yourPassword);
IContentFactory contentFactory = remoteSession.getContentFactory();

// get the required publisher object managers from IContentFactory
folderManager = contentFactory.getFolderManager();
contentItemManager = contentFactory.getContentItemManager();
propertyManager = contentFactory.getPropertyManager();
presentationTemplateManager = contentFactory.getPresentationTemplateManager();
dataEntryEntryTemplateManager = contentFactory.getDataEntryTemplateManager();

// create a text property to store HTML content
ITextBlockProperty textBlockProperty = propertyManager.createTextBlockProperty("htmlTextProperty", "htmlText");
IFolder folder = folderManager.getFolderByPath(targetFolderPath");

// create a presentation template that would use the html property
String templateText = "htmlTextProperty=<pcs:value expr=\"htmlTextProperty\">unset</pcs:value>\n";
IPresentationTemplate presentationTemplate = presentationTemplateManager.createPresentationTemplate(folder, "Presentation Template", templateText);
presentationTemplate.store();

// create a data entry template and attach the newly created presentation template
IDataEntryTemplate dataEntryTemplate = dataEntryTemplateManager.createDataEntryTemplate(folder, "Data Entry Template");
dataEntryTemplate.addProperty(textBlockProperty);
dataEntryTemplate.attachPresentationTemplate(presentationTemplate);
dataEntryTemplate.store();

//create a content item and set the rich/block text property with the HTML from the source CMS
IContentItem contentItem = contentItemManager.createContentItem(folder, "contentItemNameGoesHere", dataEntryTemplate);
textBlockProperty.setTextBlockProperty("Hello <strong><font color=\"#000000\">World</font></strong>");
contentItemManager.checkInItem(contentItem, "Initial checkin.");

// publish the content item
contentItemManager.publishContentItem(contentItem);

 

The above code sample is a draft for how you can upload an HTML string from a separete CMS into Publisher as a content item, some of these method calls should be refactored outside the main method since, more likely, you'll be looping through the source CMS content repository. Feel free to ping us if you have any questions.

 

Thanks.
 

For the past few years, researchers have been perplexed about the causes behind the increased rate of hair loss in ALUI portal administrators.  So, a team from Function1 took on the task of tracking these subjects for a few months and recorded the findings.  One of the interesting things discovered was that the cause was not genetic or gender-specific in most cases.  It was actually the simple explanation of the subjects repeatedly pulling on their hair while investigating problems with the portal.

 

For instance, the team observed one of the subjects being told that an issue with document refresh needs to be resolved right away.  For the sake of research confidentiality, we'll call this subject Jeb.  Immediately, Jeb went to work and used the handy PTSpy utility to gather more information on the problem.  After a few minutes, he had seemed to have found a clue in the log file:

CPTCardRefreshAgent::RefreshCard, caught exception (-2147203840) in refreshing card 4481.

Or on second thought, maybe not!... Jeb's mood quickly changed from being hopeful to being dejected, and he had slowly started to tug on his hair.  When questioned about his frustration, he simply kept repeating the phrase "negative 2 1 4 7 2 0 ....".  The research team noticed Jeb was losing it, so they quickly went to work and found a way to reach out to Jeb.

It took some time, but it turns out the answer lay in the Portal Server API library within the ALUI deployment.  For those not familiar with the Portal Server API (previously called Plumtree Server API), this is a "common" native programming interface used by the Portal, Automation Server, and API Service.  Even though, it's not as simple to use as the IDK, it provides additional capabilities which go beyond those provided by the IDK.

In implementation, the bulk of the interface is in one JAR called "plumtreeserver.jar", or in a DLL with the Windows version.  The interesting part of this API is that half of the definitions are for actual code interfaces and the other half is static constant definitions.  For addressing Jeb's problem, we're actually more interested in the static constants which provide the following types of information:

• task result codes
• object class IDs
• card status codes
• job status codes

Eventhough, they are all useful pieces of information, knowing what the result code values mean will allow Jeb to return to sanity.  It turns out that this error code value can be decoded by looking at the PT_RESULTCODES class in the plumtreeserver library (DLL or JAR).  Eventhough the class is provided in the JavaDocs and NDocs, these numeric error codes are not in the documentation.  So, the team decompiled the DLL, and examined the decompiled class file for PT_RESULTCODES:  PT_ResultCodes.txt

And voila!... the team was able to translate the numeric value seen in the log message to some more meaningful text.  In Jeb's case, "-2147203840" really meant that the "document was not found".  Just providing this translation to Jeb allowed him to return to sanity and continue to solve this issue.

 

Function1

Behavior Research Team

Back when I was in 5th grade, my grandma gave me a New Kids on the Block folder to sport around school.  My immediate reaction of course, was to yell:  "You're sooo lame grandma...New Kids are a big bunch of lame, and I'm not lame."  Let's for a moment forget the fact that my first ever CD was the Milli Vanilli classic "Girl You Know it's True", because that's neither here nor there. 

Howdy all.  It turns out that I may have been a little on the wrong side of correct for the past year that I've been telling people Function1 is perfect.  Shockingly, it turns out we're not:

Howdy all,

Oh, hi there, and welcome back to our corner of the internet boys and girls.  Today we're going to talk about ALBPM 6.0, SSL, and mixed content messages.  Can you say, "ALBPM 6.0, SSL, and mixed content messages"?  I knew you could.

Howdy all....anybody still out there?  No, we're not dead...we've just been hibernating.  Like the great Grizzly bear of the north, we slept the winter away.  Except, in this case, instead of sleeping, we've just been taking a blogging break.  But the weatherman tells me it's going to be 75 degrees this weekend in DC, and just like the nice weather....we've returned.  Be on the lookout in the up-coming weeks for useful BPM tips, our favorite new 3 letter acronym, the gospel according to Oracle (i.e. the direction of ALUI/WCI), thoughts on chasing squirrels,  the first ever Function1 great adventure, and information on the New Kids On the Block.  So stayed tuned, we'll be back soon.