This is one of the fruits of the recent purchases by Oracle of Hyperion (Data Relationship Manager), Tangosol (Coherence *) and Sunopsis (Data Integrator) and with a bit of Application Server, BPEL and Enterprise Service Bus thrown in and the ability to use an embed data quality and profiling product from Trillium *

* Coherence and the data quality options are add-on to the base ODI Suite

This looks interesting, I might write more on this later

The customer has spent quite a bit of time and money on their new system, and they need to make sure it works, and that Oracle Portal can handle a large number of students logging in, viewing their timetables and results, and enrolling on their student records system. In particular, they want to review:

1. Their proposed Oracle Application Server architecture, plus any supporting infrastructure databases
2. Review the hardware sizing they’ve carried out, and if neccessary make recommendations to change this
3. Make recommendations around Portal and Infrastructure performance tuning, together with recommendations around Portal deployment and development, and
4. Review their arrangements for resilience and recovery for both the application server and the database.

Doing a performance healthcheck of an Oracle Application Server deployment can get quite interesting as there are potentially so many moving parts for you to review and understand. Starting off from the application itself, it’s usually something built in Java (JSPs, servlets etc), PL/SQL, Forms or similar, and it’s going to interact with a database just like any other application – it might scale, it might not, it might have bottlenecks and so on. When you get to the application server, in Oracle’s case you’ve got WebCache, OC4J, mod_plsql, the various application server tiers, the single sign-on server, the infrastructure database and so on. Then you get down to the server level, where you can use commands such as vmstat, sar, top, iostat or utilities such as Orca to monitor CPU load, memory usage or IO load over time. You can take a more holistic view by using applications such as Grid Control to present data from multiple tiers in a single view, but it’s very difficult to monitor and diagnose performance problems across the whole stack as not everything is instrumened and integrated.

In this case though, we can probably narrow down the investigation to three main areas:

1. Oracle Portal, i.e. have they sized their hardware sufficiently for the proposed load, and have they deployed it properly
2. Is their overall Application Server deployment correct, does it load balance properly, cache properly, can it handle the load, and
3. Have they deployed their databases correctly, i.e. are they resilient enough and can they cope with the load they’ll expect?

Now as this is only going to be a two day exercise, and part of that will be set aside for the report write-up, we’re not going to be able to go into too much detail, but if we ask the right questions and know what to look for, it should be possible to give some initial worthwhile recommendations fairly early on.

Starting off with their Oracle Portal deployment, it’s worth taking some time out early on to define a few terms and set out a scope. As a good starting point, the Oracle Portal : Performance & Sizing page on OTN has a set of pretty useful papers and presentations on the subject, and there’s a particularly good one by Jason Pepper titled “How to Effectively Size Hardware for your Portal Implementation” that has a good glossary and set of initial questions that would be a good way of starting things off. In particular, some terms that are worth understanding at the start are:

• Concurrency – the ability to handle multiple requests at the same time. In our instance, the student records portal will need to handle many simultateous users logging in, accessing reports, adding their details and so on (but how many at a time, and how does their activity break down?)
• Contention – competition for resources, a familiar issue for database developers
• Failover – a method of allowing one machine or process to provide a service if the original one fails
• Latency – the time that one system component spends waiting for another
• Response time, Service Time – needs little introduction
• Scalability – the ability of a system to provide throughput in proportion to, and limited only by, hardware resources. In our case, will the system scale up to handle the expected load (one would hope so) – but also, if the load increases, can they just add more hardware or is there some limiting factor in the software they’ve deployed or developed?
• Throughput – the number of requests – Portal pages, in our case – processed in a set amount of time.

This page on OTN looks in more detail at three of the metrics – peak page throughput, page cache hit ratio and peak login rate – and shows how the figures are calculated. See also “Sizing Frequently Asked Questions”.

Clearly there’s a lot to think about. In Jason’s paper and in the OTN article, three ways to go about sizing your Portal implementation are put forward:

1. Calculator, i.e. have some sort of a spreadsheet or ready-reckoner that produces figures for numbers of processors, amount of RAM and so on for a given set of requirements (concurrent users, page throughput, response time etc). There’s something along these lines available for Discoverer on OTN. The trouble with this approach, the author however argues, is that it’s often the most innaccurate way of producing sizings.
2. Size by Example. This is where you compare your proposed layout to some predefined examples, ideally customer case studies carried out in the real world. You pick the one nearest to what you’re planning and use that as your guideline. This is a bit more accurate than calculating using formulas.
3. A Proof of Concept. This is where you build a representative version yourself, scale it up and measure it yourself. This is going to be the most accurate way of producing your sizings, but it’s also the most costly and takes the most time, as you actually have to build something.

Whichever route you go down, there are some intelligent questions you can ask at the outset to get you off in the right track. Going back to Jason’s presentation, these can be classified into three areas: sizing scope, Portal requests/load, and Portal content/complexity.

1. Sizing Scope

• Are we sizing for peak (the highest possible) load, or for average loads?
• Is high availability needed? i.e. is it “mission critical”, or can we take a hours/days outage? Remember high availability will require redundant servers or oversized machines, and will increase the work required to run and maintain the servers.
• Are there any particular maintenance issues, i.e. preferred / mandatory hardware, vendors, OS, storage etc? Are we re-using old hardware?

1. Portal Requests / Load

• What is the planned total number of users, and how many of them will be concurrent at any one time (max, average)?
• What is the desired page throughput, i.e. given the estimated concurrent users above, how many pages will they request in say 10 minutes? Divide this down to pages per minute, or even per second.
• What is the login frequency, say as a percentage of total pages requested per user? Logins are a special kind of page request, in that any login process will keep the portal machine from delivering pages, i.e. it’s a serialization event, just like a lock or a latch in the database.
• What is/are the desired response time, including the response time for remote as well as local (intranet) users?

1. Portal Content / Portal Complexity

• Where does the portal content come from? Is is “internal” portlet content, say from database or java portlets build using Oracle’s SDKs, or is it external content?
• How cacheable is the portal content? What is their cache strategy?
• What is the average content lifetime?
• What is the planned integration technology?

More on these questions can be found in Jason Pepper’s presentation and article.

At this point, we know the scope of the sizing exercise, any desires and constraints, and the sort of workload the Portal setup will need to be able to handle. Now we know what we’re aiming at, we can start to look at the three sizing approaches – calculation, examples and proof of concept.

The paper suggests a way of carrying out the calculation approach through using a standard Portal example – Oracle’s GlobalXChange knowledge management portal, which can be “generated” using a set of scripts, and then using the benchmark figures as the constants to feed into a series of calculations. The paper has the calculations and some details on the benchmarking approach, but being honest I can’t really see this happening with our client as I they’re looking for something a bit more immediate, more a validation of their approach. Funny enough, the third approach, to build a proof of concept, is sort of possible, as the system is already there, and it (presumably) runs – but they’re more looking for confirmation that what they’ve got is “correct” and the numbers roughly check out OK. Therefore, I’ll be using the second approach, to find some examples of similar systems, and compare it to what they’ve got, and see whether the figures the example systems turn out compare favourably to the figures our client is producing.

To do this, I need three things.

1. A set of example Portal configurations, with figures to indicate the capacity that each could be expected to handle,
2. Details on how they’ve set up their Portal environment (topography, use of hardware etc), and
3. Some diagnostic and performance data from their setup to compare against the example configurations.

Looking back at the Performance and Sizing page on OTN, there are in fact three sample implementations that can be used as reference points when sizing your own Portal implementation. Looking through them, they are:

1. The small implementation, with 10000 registered users, 2.4 concurrent requestors requesting one page each every 60 seconds, equating to 0.081 page requests per second. In this instance, the recommended topology a single load-balancing router (A), two mid-tier Portal servers (B,C) with 2GB of RAM (either 2 CPU Intel boxes, or Sun V280Rs), and a single infrastructure tier (D) with the same number of CPUs but with 4GB of RAM.
   

   This compares well with our implementation, except the number of concurrent users might be higher. We’ll have to ask the question and find out.

2. The medium implementation. This has 2,500 users who may be logged in at any one time, of which around 15% are active (and therefore concurrent). These 375 concurrent requestors generate around 2 page requests per minute, giving an overall page throughput of around 12 pages per second. This configuration works out to be a single load-balancing router (A), three Webcache servers (B) with 2 x 1.4GHz CPUs (assuming Intel), configured as a cluster (i.e. not using hardware load-balancing) and with 4GB of RAM. Then there are 2 Mid-tier servers (C), again clustered but this time with 6GB of RAM, and then two infrastructure servers (D), clustered using Redhat Cluster Manager server for fail-over support (not load-balancing), with the two of them attached to a shared disk (E).
   

   This could be a viable solution if we need to handle more page requests per second, and if we’re looking for some resilence/fail-over.

1. The large implementation. This has 300,000 registered users, 1% concurrent and a total page throughput of around 100 per second (259m page requests per month). I won’t list out the details of this solution as it’s well beyond what we’d need to cater for, except to say that it uses for example 8 webcache servers, separates out identity management and the portal repository on to separate servers, and is probably sized for something along the lines of OTN or a large company website.

It’s also worth reading through the preamble to each of the examples especially where it talks about factors such as “hits”, “page requests”,’ concurrency” and “high availability”. When you size a client-server application it’s fairly easy to define things such as concurrent users, but on a web application users tend to connect and disconnect all the time, and make page requests on an irregular basis, and therefore the examples define concurrency in terms of page requests per second, which is the most accurate way of expressing how much simultaneous work the server is going to have to do.

Now that we’ve got some sample implementations to use as “best practice cases”, the next step is to get hold of the client’s proposed topology and deployment. and compare this to the examples. One slight issue is like most university customers, they’re using “big box” Sun hardware to hold multiple application server tiers and database instances, rather than the single-use Linux Intel commodity hardware proposed in the examples, but it’s still possible to compare the logic layouts and use of products between the client and example implementations.

At this point, we know the following things:

• What the client’s expectations are of their system
• What Oracle propose as being best practice deployments for a set of example customers, and
• What our customer is proposing as their application server deployment.

It should be fairly straightforward to compare the client setup to the Oracle setup for a similarly sized organization, to see whether what they’re proposing sounds realistic. What it’d be nice to do now though, is to capture some performance metrics on the customer setup if it’s already running, or point them in the direction of some ways to do this, to see whether what they’ve set up is performing as expected.

Just like with the Oracle database, there are many ways to capture performance and diagnostic data so that you can measure the performance of your system. You can do it graphical, in real-time, using Oracle Application Server Control, or you can look at data over time using Grid Control. Portal itself has some Portlets that provide information on usage, most popular portlet and so on, and you can access the logs generated by the underlying OC4J and mod_plsql processes. You can use Unix command line tool such as vmstat and iostat and utilties such as orca to track the performance of the underlying servers, and if you’re looking for very low level, trace data you can use Application Server utilities such as dmstool and aggrespy to track the performance of individual components.

This presentation and paper by Mick Andrew and Jitiner Sethi goes through the facility available in Oracle Portal and Oracle Enterprise Manager (AS Control and Grid Control) concerned with monitoring and diagnostics. Every installation (tier) of Oracle Application Server has an installation of Management Agent on it, and this collects performance and diagnostic data which then either gets fed to the local AS Control application or uploaded to a node running Grid Control. One key difference between AS Control (free with Application Server) and Grid Control (an extra license cost) is that AS Control only displays real-time, “as of now” performance data for one particular node, whilst Grid Control shows real-time data and historical data for all nodes that it is managing.

The basic Enterprise Manager portal metrics can be accessed using ASControl and look like this:

This page provides some general metrics such as status and portal performance, plus information on the status and version of the Portal Repository. It’s also useful for viewing the status of Portal components such Providers, Syndication Service and Ultrasearch. Using Grid Control, you can show metrics collected over a period of time, and use these metrics to monitor historical trends. I think it’s unlikely our client will have licensed Grid Control though so I won’t spend too much time on this.

For more detailed reports on Portal usage, you can run a few post-configuration steps and start loading the logs generated by Oracle Portal into the database and start running something provided by Oracle called the “Portal Performance Reports”, a set of text-file reports that provides information on:

• What is the peak login time per day?
• How many logins per day does the portal receive ?
• How long have portlets been taking to execute ?
• What is the slowest portlet ?
• How many total hits does the portal receive each day ?
• Most/Least popular portlets
• How often are users viewing a page or portlet?
• How many unique users have logged in each day?
• Which portlets were called?
• How many hits does each page receive each day?
• How many hits does each portlet receive each day?
• Request breakdown by IP address or host name

These replace the reporting and monitoring portlets that you used to get under the “Monitor” tab with Portal, but that are now obsolete with the advent of WebCache. Using the post-configuration steps linked to previously, you can set up logging such that the whole process is automatic and the reports are generated for you on a daily basis. For more details on how you can monitor Portal using inbuilt functionality, check out “Monitoring and Administering Oracle Portal” in the online documentation.

If you’re feeling particularly adventurous, “Oracle Application Server Tuning Techniques” by John Garmany and Don Burleson (ODTUG membership required) looks at some database and application server parameters that are useful when tuning the infrastructure database, and examines the use of utilities such as the Dynamic Monitoring Service (dmstool) and Aggrespy, a Java Servlet that can be used to display metrics for many Application Server 10g processes. My instinct is to leave the infrastructure database parameters as they are for the time being – the Oracle example implemenations just used the default settings – and if I’m looking to suggest any database tuning at all, it’ll be on the database used to hold the student record application data. It’s useful to know this facility is out there though, especially if Forms is used at all as there’s a fairly comprehensive section in the paper about interpreting the Forms Servlet logs.

So there we go then. I think I’ve managed to cover off all of the requirements – review proposed setup, compare to “best practices”, propose a way of monitoring and benchmarking the Portal installation, and review their arrangements around resilience and high availability.

)
I’ve given recently, you’ll probably be interested to know that I’ve been given
early access to a release candidate of the next version of the product, known as
XML Publisher 5.6. I featured this new release in the presentations on the
product I’ve given recently, but up until now what I’ve spoken about has been
based on conversations with the product team and access to documentation. I’ve
got my hands on an early version of the product now and I’m starting to give it
a walkthrough. Over the next few days I’ll be going through the process of
setting XML Publisher 5.6 up, accessing the new XML Publisher Enterprise
reporting portal and running some reports, using the new Microsoft Excel
integration, and then creating an XML Publisher Enterprise online reporting
application from scratch. I’m doing this as a way of working through the product
prior to writing an article on it for OTN, so if there’s an area I cover that
you’d like a bit more information on, drop me a line and I’ll see what I can do.
As a quick recap, XML Publisher 5.6 is the second stand-alone release of XML
Publisher and the hot new features include:

• a new “Enterprise” application that provides online access to reports
  using a folder-based portal, with reports accessed via users and groups

• Microsoft Excel integration, so that you can analyze reports, change
  parameter values and rerun them using the familiar Excel interface

• Easy installation as part of the OC4J install
• A pivot table-style OLAP analysis feature

XML Publisher 5.6 currently runs as an application hosted in either OC4J
10.1.2 / 10.1.3, or Apache Tomcat 5.x, and the plan is for the production
release to include OC4J along with the product in the same installer so that you
can get up and running straight away. With the version I had I had to do a
manual install (it’s just an early preview release) and so it was a case of
installing OC4J 10.1.3, start up the OC4J admin console, pick up the .ear file
for XML Publisher and then deploy the application – even this manual process was
easier than with XMLP 5.5 although that’s more down to the choice of OC4J 10.1.3
rather than 10.1.2 on my part.

As well as the server element that gets
installed on OC4J or Tomcat, there’s also a Desktop element that installs as a
plug-in to Microsoft Word. This is a straightforward Windows installer (someone
asked me last time about Open Office support, as far as I know it’s MS Word only
at this point) and it’s a similar process to 5.5. The Desktop version of XMLP is
used for building and then previewing report templates, but for the time being
I’ll put this aside and we’ll take a look instead at the server element, which
is where the main differences are from the previous release.

If you read
the postings on XMLP 5.5 a few months ago, you’ll be aware that this first
release didn’t really come with a server application for viewing your reports.
What you got with 5.5 was a set of java libraries, and some example applications
that showed how the libraries could be used. What’s new in 5.6 is that Oracle
have taken these libraries and build a complete report viewing, scoping and
administering environment using these libraries and delivered these as XML
Publisher Enterprise. Taking a look at it, and the XML Publisher Desktop
element, is quite suprising actually as they’ve done a pretty good job – the
online Enterprise part is way in advance of what you get with Oracle Reports,
which pretty much left you to your own devices in coming up with an environment
for your users to select and then run their reports, with jobs like scheduling
pretty much being a DBA-only task that required you to submit arcane URLs to the
reports server to create jobs and return status information. With XMLP 5.6 all
this has a pretty new HTML front-end and you can obviously see that XMLP rather
than Reports is where Oracle’s reporting effort is going in
future.

Anyway, once you start up XML Publisher Enterprise you get
presented with a login screen. The default login and password is “admin/admin”
which you should obviously change once you’re up and running.

Once you’re in, you’re presented with a view of the
folders and reports that you can access, plus a taskbar on the left-hand side
for creating new folders, reports and uploading existing reports. The admin tab
lets you define datasources and other settings, I’ll cover those
later on.

Navigating over to the HR Manager folder, I first
clicked on the Employee Salary Report; after a couple of seconds the report came
up – pretty fast actually, no noticable lag, much faster than Discoverer or
Reports. The report looked like this:

Pretty standard stuff. Note the parameter drop-downs at
the top of the report, the links for scheduling and viewing report history, the
template and output format changer, and the Analyzer and Excel Analyze buttons
(more on those later).

The next report I ran was the Sales Dashboard in
the Executive folder. Now this looked quite impressive – again very quick to
display, very little load on the server as it’s rendered.

What this dashboard is showing is a number of separate
queries coming both from the datbase, and from XML document datasources. It’s
interesting to think about this in terms of Oracle Portal – obviously Portal is
a pretty good framework and gives you lots of additional features – Single
Sign-on, ability to host Oracle and JSR-168 portlets, Discoverer integration and
so on – but this feature in XMLP is pretty nifty and is an alternate solution
when you need to put a lightweight portal together. I’ll be looking at this in
more detail at a later date, but for the time being it looks like a pretty
impressive BI feature.

The next feature I thought I’d try out is the
Microsoft Excel integration. This works via a .NET Framework 2.0-based plug-in
to Excel that gets downloaded to your PC when you first use the “Excel Analyzer”
feature. To test this out I loaded up the Employee Report again and clicked on
the Excel Analyzer button:

Once you’ve pressed the button, the first thing that
happens is that Excel starts up, loads the report data into a worksheet and then
formats it to look like the report template. You then get a new XML Publisher
menu item at the top of the page that gives you the ability to log in to the XML
Publisher server, using the same credentials as you used to log into the online
web interface.

Once you’ve logged in, you can then bring up a toolbar
that lets you select from the reports parameters, then rerun the report to bring
back a new view of the data. This is where the value comes in – you’re connected
to the XMLP server, which gives you the ability to rerun the report from within
Excel, have XMLP server return the data, and then present it to you again in
Excel – there’s no need to use another tool and XML Publisher is doing all the
hard work in retrieving the data, applying security and scoping, and providing
interaction features such as toolbars and parameter lists.

Going back to the online interface, there’s a nice
scheduler based on the OpenSymphony Quartz Scheduler that allows you to
submit a report for running now or in the future, run it at regular intervals
and send the results via email, PDF, HTML, XML or RTF.

Finally, and for me this is one of the most interesting
features, there’s an “Analyzer” button on the top of each report page that lets
you analyze your data using a pivot table-style crosstab interface. Going back
to the folders and reports page, selecting the Sales Analysis report and then
pressing the Analyzer button, you get presented with this interface that lets
you pick data items for the pivot table:

You can then drag and drop data items onto the pivot
table, add other items in as page items (as with Discoverer), and then drag on
the measures that you’d like the pivot table to analyze. You can even nest
dimensions by dragging a second row or column item on top of an existing one,
and change the orientation of the crosstab by dragging a row field over to the
column field area and vice-versa. A very impressive bit of code actually, I
wonder if Oracle bought this in as a component or developed it themselves?

From what I understand, XML Publisher does all the
indexing and rotating of data at the server mid-tier, i..e. there’s no extra
load on the database server, a bit like how Discoverer works when using Oracle
Application Server. Again from my conversations with the product team, they’ve
in addition to regular SQL queries, got this feature working with Oracle OLAP in that you can analyze data extracted
using SQL views using OLAP_TABLE, although as the XMLP server does the indexing
and caching obviously you’re not going to get the benefit of Oracle OLAP’s
summary management and indexed data access. Still, it looks a very impressive
feature, obviously not quite as featurefull as Discoverer but an excellent way
of presenting data to users so that they can analyze it online. Good
stuff.

Right, that’s it for now. Over the next few days I’m going to look at the process of putting
your own reports together, publishing them using XMLP Enterprise, and using the scoping
and user management features to add a layer of security. Back in a day
or so.

"Lately I have been playing around with Oracle’s HTML DB. This is a
rapid development environment for small applicaiton that is entirely web
based. Unlike J2EE, the web application actually runs as PL/SQL in the
database, although you can load the OHS on a separate server. Basically a
fast and surprisingly easy way to create a mod_plsql application.

One cool aspect of HTML DB is that it can be integrated into the application
server midtier instances and take advantage of the AS10g Web Cache.
Integrating HTML DB into the application server is relitivaly straight
forward since the heavy lifting is performed in the database."

The rest of the article goes into the steps you need to take to copy the HTML
DB files into the Application Server ORACLE_HOME, what change you need to make
to configuration files, and how to update the new configuration in the metadata
repository. Good stuff.

Another excellent OTN article by
Justin Lokitz on using the spatial data and mapping features of Oracle 10g
and Oracle AS 10g. You might remember Justin’s previous article on
Spatial/Locator and Oracle Discoverer ("Using
Location Information in Enterprise Reporting") and a similar article of mine
("GIS-Enabling Your Oracle Data
Warehouse") that Justin contributed
some examples to. This article looks at building portlets that comply to the new
JSR 168 standard – and are therefore deployable to any compliant portal product
- that use the built-in spatial (pay-extra) and locator (free) features of 10g
together with Oracle Map Viewer, part of Oracle AS10g.

There’s also mention of the JDeveloper Portal add-in
that makes developing JSR 168-compliant portlets fairly straightforward, and a
brief look at the Mapviewer JSP tag library that’s used to display the map
within the portlet. An interesting and useful article by Justin, and one to
bookmark and take a look at when you’ve got a spare twenty minutes.

As with AS10g Release 1, I made sure I had around 20GB of free hard disk
space on my laptop, and with 2GB of RAM this is usually OK. I’ve got Windows XP
Professional SP2 which officially isn’t supported, but as it’s on the laptop
anyway I thought I’d give it a go before going through the process of installing
Windows 2000 or Windows 2003. I”ll go on to it later but the upshot of this is
that I’ve not had any problems.

The first disks I installed were the AS10g Release 2 Portal and Wireless
disks [1,2,3]
as I guess (rightly it turns out) that these would contain the infrastructure
install. After unzipping the files to three directorys (Disk1, Disk2 and Disk3)
I ran the installer on Disk 1 and eventually the install options page came up.

Obviously what’s happening here is that these three disks
contain two AS10g tiers; the infrastructure tier, and a mid-tier containing
Portal and Wireless, together with the AS Developer Kits. I selected the
OracleAS Infrastructure Tier and was presented with the following option:

What we’re being given here is the choice of installing the
infrastructure database together with OID, just OID or just the infrastructure
database. I selected the first option (to install both at the same time) and
went on to the next stage of the install.

A couple of steps on a rather scary-looking dialog box came up,
asking me about the service running on port 1521.

I guess what’s going on here is that the installer has detected
something listening on 1521 (the regular port for Oracle databases) and is
checking that it’s a 10g database – given that the infrastructure database about
to be installed is a 10g 10.1.0.3 database, I know I’ve had problems getting 10g
databases to automatically register with 9i listeners, so what’s happening here
is that the installer is only going to add the infrastructure database to a 10g
listener, which it knows will go ok.

After a couple more questions to do with OID, the familiar SID
and Service Name screen for the 10g database comes up, which obviously means
we’re about to go into the infrastructure database install (10g release
10.1.0.3).

After that it was just a case of naming the infrastructure
instance, setting the password and kicking off the install.

Once this part of the install has completed, you then go through
the configuration stage (which went ok) and then make a note of the URLs and
port numbers that have been assigned.

Now the infrastructure has been installed, the next step is to
install the Portal and Wireless mid-tier, which you do by running the installer
on Disk1 again, and this time select the Oracle Application Server 10g option.

The Portal install goes through as with earlier releases without
any problems (although a warning comes up that this mid-tier isn’t supported on
Windows XP). One issue that did crop up during the setup of the Portal install
was that it wasn’t immediately obvious which port number my OID instance was
running on – the two numbers (SSL and Non-SSL) suggested in the online help
didn’t work and in the end I had to log on to the EM Website for the
infrastructure instance and retrieve the OID port number from there (which isn’t
the end of the world, but everything so far had been so easy)

.

After installing the Infrastructure tier and the Portal
mid-tier, the next install was the Business Intelligence mid-tier
[1,2].
On earlier Application Server releases both Portal
and Discoverer had been on the same mid-tier, but now they’re separated out – as
is Forms and Reports, which means that if you want Portal, Discoverer and
Reports, you’ve going to have to install four separate AS10g tiers. First of all
a quick check of Enterprise Manager for the infrastructure and Portal tiers…

and then off with the install. As with the
Infrastructure and Portal installs, the BI install went without any problems.

So now it was time to test out Discoverer Drake. The first thing
you need to do with Drake (if you’re going to use the OLAP Option) is to fire up
Enterprise Manager, install the Discoverer Catalog, and authorise the schemas
that will contain data that Discoverer will analyze.

Then it’s just a case of starting up Discoverer Plus, selecting
the Discoverer Plus OLAP Option, logging in and then bringing up Discoverer
Drake.

One point I noted was that, like earlier AS releases, Discoverer
by default doesn’t use SSO, so you have to log on twice using your Discoverer
username rather than Discoverer just falling back to the standard SSO login
page. Going into Discoverer Plus OLAP you notice the new look and feel (compared
to the beta) but other than that it’s pretty much as you’d expect.

The total size of the install was 2.38GB for the software,
another 1.66GB for the infrastructure database (total of 4.04GB). The start menu
has two entries for each of the tiers (a standard Oracle Home entry, and a tier
control entry) with menu items for starting and stopping each tier instance

.

That’s it for now, more news as I get to play around with the
various bits more.

The Backup and Recovery Tool is actually a Perl script that backs up all
of the configuration files for a tier. If the tier is an infrastructure tier and
contains a metadata repository database, it will back that up also. "
More…

1. What technologies are already built into the Portal
   architecture/framework that can be used to leverage existing location data?
2. Will users need to see the information in tabular/report-based formats
   rather than just as maps?
3. What technologies are the portal and map developers comfortable
   developing in?

Because the user-base I was targeting for this project are primarily users
whom already use Oracle Discoverer for business intelligence, and also use
end-user layers (EUL) that were built to query location information (see

http://www.oracle.com/technology/pub/articles/lokitz_location.html for
instructions on how to do this) I figured the next logical step would be to add
the functionality so that those same users would be able to see ALL of the
information, tabular and maps, on the same page sort of a BI dashboard. As I
had already built some dynamic JSP maps for the Discoverer project, I decided to
use those same maps within the portal framework." Read the rest on how
Justin Lokitz built a dynamic map portlet using Oracle Portal (10g), the JPDK
and Oracle Application Server MapViewer in in
Justin’s OraGIS
blog.