A GWT application code consists of the generated GWT static resource files (HTML, Javascript, and CSS) on the front end, and server-side service code on the middle and back end. For performance reasons, static resource files are often deployed to the image server. And as of version 1.6, Google Web Toolkit easily allows for seamlessly changing the location of the generated GWT static resource files from the default location in the war deployment.

If you do wish to pursue separating the generated static resources from the backing server code, there are a few steps to take. The primary reason for this change is to avoid potential cross-domain issues that will arise from separating your resources; your imageserver may be running on imageserver.domain.com:80, while your application service might be running on appserver.domain.com:7001.

For this example, we’ll assume your application is called formbuilder.

• Under the war folder that GWT generates, you will find a folder with your application name, formbuilder. Copy that folder to a target folder on the image server, such as /imageserver/RemoteGadgets/formbuilder/gwt/.
• On the GWT entry point JSP page, you’ll make two changes. The first is to create a Javascript variable that stores the gatewayed URL of the servlet. The second is to change the GWT entry point Javascript reference.

• After the changes, your JSP will look something like the screenshot below.

• Finally, in the Java class that implements the EntryPoint interface, you will reference the gatewayed service URL using GWT’s Javascript Native Interface (JNSI).

Bonus tip: As discussed earlier in this post, Google Web Toolkit provides tools to create rich, complex web applications entirely through Java code. GWT was built with cross-browser compatibility in mind, but not all generated HTML is treated equally. For example, adding a widget that generates a block level element into a container that generates an inline element may result in an “Error: Invalid source HTML for this operation.” error in Internet Explorer. When building in GWT, remember that while you are coding in Java, your output is HTML + CSS + Javascript. As with any web application, be sure to test your GWT app in a variety of browsers.

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

thanks,

Vasanth

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

Here’s a not-so-well-kept secret about the software business: software and maintenance is a high-margin business for vendors.  This means that there is no list price on that shiny new piece of software X that you’re thinking of buying…”list price” is just a starting point for negotiating, alot like the tag in the window of a used car.  What’s more, most software sales folks have a sales target each and every quarter.  The difference to a salesman between beating and missing their quarterly number is pretty significant.  Beat their number and they:

• Likely get a trip on the company to some exotic resort where they sip on delicious fruity drinks.
• Buy that new convertible weekend car that they’ve been eying.

Miss their number and they can expect:

• Lot’s of yelling from angry VPs
• Lot’s of meetings and “planning sessions” with aforementioned VPs on how they’re going to make their number next quarter
• Perhaps start looking for a new job

The upshot here is that, come end of the quarter, if a vendor isn’t meeting their financial targets, it’s firesale time.  In short, you have leverage to negotiate a much better price for your software.  Say, for instance, you’ve received a quote to buy a site license for some software at $500K + 20% annual maintenance.  Let’s also say that, come end of the quarter, your favorite salesman is $300K short of meeting his sales target.  Let’s also say that the economy is currently in the toilet, and the vendor you’re working with is in danger of missing the financial target they’ve given to Wall Street.  All these factors add up to a perfect storm of you saving a bunch of cash.  If you’re not afraid to say, “No” to a price, there’s a good chance you get the $500K software for $300K…if you buy before the end of the quarter.  So, not only have you saved $200K from your budget immediately, but you’re also realizing an annual maintenance savings of $40K…that’s real money.  Money you can use to:

• Take your team on a trip to some exotic resort where you sip on delicious fruity drinks.
• Throw a kick-ass holiday party
• Hire your favorite consultants at Function1 to give you a hand in getting the most out of your new software purchase

That’s about all for now.  Hope you find this tip helpful, and that it saves your some $$$.  If you’re really in the holiday spirit, feel free to send us a check for 10% of any money you save :)

The HTML rewrites cause the browser to make the HTTP request “behind the scenes”, and when a response comes back, the portal refreshes the content inside the portlet <div> tag.

But there are some things to know about this AJAX stuff, so here are a couple of refresher points about AJAX:

1) The response to an AJAX request is basically just a text string to a browser, and it’s up to your JavaScript to interpret it.  Often you do something like:

document.getElementById("responseDivTag").innerHTML = response.getResponse();

… to refresh content.  But note that this doesn’t tell the browser to “process” the response – specifically, JavaScript that comes back in the response won’t run, because all we’re doing is setting the HTML to a string that comes back from the server.  In order to run JavaScript in the response, you should look into the JavaScript “eval()” method, which will take a string returned from the server and run it as JavaScript.  Just make sure you don’t include the <script> tags in your response if you really are returning JavaScript and are parsing it as such.

2) The response does not have to actually be HTML!  It’s just a string to the browser, and you can do anything with it.  The most common use (which all of our products use) is to return JSON, or “JavaScript Object Notation”, which can then be treated as objects that your script can handle however you want.  Let’s say you just want to know if there was a success or failure: you could literally just return a “0″ or “1″ in your response and write something like:

if (response.getResponseText.equals("1"))


   alert("success!");

else

   alert("fail");

Obviously, this just barely scratches the surface on AJAX, and you can rest assured that you haven’t heard the last of it.  AJAX is the cornerstone of pretty much all future Oracle portal technologies, and if you’re a web developer who’s not all that familiar with it, trust me:  you will be soon.

The authentication ID and the DB password are both written out to the file.  Obviously this isn’t a critical security hole (if a malicious user has access to your system, you’ve got other things to worry about), but a concern nonetheless.  Until the issue is resolved, I’d recommend just upping your log threshold to WARN by modifying the \ptcollab\4.5\settings\config\wrapper.conf file.  Change:

wrapper.logfile.loglevel=INFO

to:

wrapper.logfile.loglevel=WARN

The gist of his post is that there are a lot of moving parts in performance tuning, including the portal, remote tier, and the database: the performance chain is only as strong as its weakest link.

To get more of his great high-level overview on performance tuning, click on through for a good read!

I had written a blog several weeks ago about how tune portal applications for performance on the dev2dev.bea.com website. As I am accumulating more material on this topic, I decided to write a more detailed blog with Function1.

The ALUI portal is based on a stacked and component-based architecture.

The following diagram shows various ALUI portal modules.

Over the years, the ALUI portal has grown to provide a rich set of functionality. This means that the skill required for managing the portal and the complexity for implementing high performance applications (portlet) increased as well.

In addition to having functional & integration tests, high performance applications should also be vigorously tested under stress tests (in conjunction with the portal). Load tests help to detect issues, such as the application’s buckling & failure threshold – the maximum of users, load, and throughput, uneven load distribution, etc.

There could be many “moving parts”; a systematic approach is recommended for diagnosing performance bottleneck(s). We recommend using a checklist such as the one below to comprehensively test as many of these “moving parts” as possible:

1. Examine high-level system architecture, e.g. component & deployment diagram, network infrastructure, to identify design flaws.
2. Obtain & review performance metrics/reports and stress-test results
3. Perform a detailed analysis of subsystems & servers, e.g. resource consuming, job scheduling, etc.
4. Carry out a sequential (time-series) study of 2 & 3 in a time period over few weeks or several test runs.
5. Use profiler to pinpoint specific implementation issue, e.g. insufficient caching & code optimization, etc.

A broad task is reviewing the architecture diagrams and performing a capacity planning analysis. This helps you identify whether sufficient resources (bandwidth, CPU, disk I/O, load balancing) have been allocated for the corresponding number of users. The ALUI Portal Deployment Guide shows some baseline numbers (http://edocs.bea.com/alui/deployment/docs604/planning/index.html), e.g. hits/pages per second for a system of certain CPU and memory configuration.

The next step is to review performance metrics. Leading Stress-testing tools such as Load Runner or Microsoft Web Application Stress Tool, can produce diagrams showing correlation between load and system performance.

Stress Test – User Load

Stress Test – Throughput

Stress Test – Hit per Second

System performance has many different perspectives, e.g. CPU load, network bandwidth consumption, Memory, Disk I/O. Therefore, it is a good practice to design multiple test-cases for different criterions. For example, a “login-only” test consumes less network bandwidth than a “community page test” which needs to repaint the entire browser window. Therefore, the “login-only” test could help you identifying the maximum sustainable “Virtual Users”; whereas, “community page test” identifies the maximum “Throughput per Second” & “Hits per Seconds”.

Time progression tests (e.g. tests from week one, to week two, to week three, so on) can be used to further identify improvements in the application performance.

All systems have “saturation points”, beyond which the performance “levels off” (the response time no longer increases) even as the load continues to expand. This is similar to a car engine, where power is a byproduct of RPM. This phenomenon can be explained by examining various joints in the entire system. Caching mechanisms exists at various points & sub modules, e.g. application server, web server, network load-balancer, Database cluster, etc. They are buffers against increased load.

There is also a “buckling point”, at which the system fails. This can be identified by observing huge spikes in the number of errors, time-out, and the system hanging or rebooting.

Next, system resource consumption should be examined. Windows based systems use Perfmon tool for recording the system metrics during the stress-test, e.g. Processors load, network bandwidth consumption, Memory allocation, virtual memory swapping, Page Fault, Disk I/O, Process Execution Time, Request Wait, number of Worker Process Restart, etc. On Unix based machine, there are many powerful and robust tools for gathering resource consumptions, e.g. “iostat”, “cpustat”, “vmstat”, “top”, “sar”, to name a few, … Those data can also be used in making capacity planning/sizing decisions.

Portlets are hosted within application servers. The app servers’ log and performance metrics should also be reviewed. Depending on which platform, various tools can be attached to monitor the application servers’ health. On Java-based application, JMX plug-ins monitor performance metric and manage the application server. IIS servers can be managed thorough MMC plug-ins.

ALUI has a tool called PTSpy, which is based on Log4J and Log4C. PTSpy has several useful performance logging calls. Performance results can be recorded using various appenders (network, file, DB) and reviewed later.

It is also recommended to use application profilers in the development environment to optimize the portlet code. Application profilers can identify both common issues, such as lacking caching mechanisms, insufficient connection pooling, memory leaks, as well as showing less obvious things, such as how often certain methods are called, the size of objects being passed between methods, how many instances of an object or method are created, etc. Many IDEs offer either free or commercial grade application profiler plug-ins. The Eclipse IDE has a Test & Performance Tools Platform (TPTP) Project. It allows you to examine the code down to a line-by-line granularity as well as monitor the application at much higher-level, e.g. Web-Services calls. Similar tools are exists for Netbeans IDE, MS Visual Studio, Together J, etc.

Application & Server configuration files should also be examined. These include web.config, web.xml, portlet.xml, resources.xml, jdbc pool parameters (connection timeout, max number of connections), etc.

Applications use the database to persist non-volatile data. Therefore, properly tuning the database (SQL calls & package) will be very important aspect of performance management. Aside from system level indicators, including memory-consumption, network activity, total CPU utilization in minutes & seconds, number of worker threads, DB monitors can show the frequency of tables being used and updated and how long it takes to join different queries. These metrics can lead to better designing the database schema and/or improving queries.

Database Server Resource Utilization

A system is only as good as its weakest link; whether it is the network, application logic (e.g. caching, patterns), database, or management. For example, job scheduling can also affect the system performance. Running virus-definition update and doing file backups during peak usage hours will degrade system performance. All non-essential activities, such as system back-ups, anti-virus scanning, and security policies (LDAP sync), should be scheduled to run during off-peak hours.

Portlet application performance tuning is a methodical process. It covers multiple facets, e.g. infrastructure, management & planning, profiling, patterns, etc. Some improvements are low-hanging fruit; others are not. They can be placed into following quadrants.

1. Easy to implement, significant performance improvement.
2. Easy to implement, insignificant performance improvement.
3. Difficult to implement, significant performance improvement.
4. Difficult to implement, insignificant performance improvement.

Decisions to modify the system can be influenced by time, budget, and required skill-sets.