This year I embarked on a journey
to migrate a group of
ASP.NET web applications developed
to integrate with WebLogic Portal 9.2 via
the
AquaLogic® Interaction .NET Application Accelerator 1.0
to instead use
the Oracle WebCenter
WSRP Producer for .NET and integrated with WebLogic Portal 10.3.4. It has
been a very winding path and this blog entry is intended
to share both
the
lessons learned and relevant approaches that led
to those learnings. Like most journeys of discovery, it was not a
direct path, and there are notes
to let you know when it is practical
to skip a
section if you are in a hurry
to get from here
to there.
For
the Curious
From
the perspective of necessity, this section would be
better at
the end. If it were there, though, it would probably be read by far
fewer people, including those that are actually interested in these types of
sections. Those in a hurry may skip past and be none
the worst for it in
dealing with
the hands-on bits of performing a migration from .NET Accelerator
to WSRP Producer. For others who want
to talk about why they did what they did
after they did it, or just want
to know for themselves, enjoy.
A Brief (and edited) History of
the WSRP for
.NET Technologies (as Relevant
to the this
Post)
Note: This section is
for those who are curious about why
the migration path is not as simple as many
other Oracle technologies. You can skip this section in its entirety and still
be just as competent in performing a migration as if you had read it.
The currently deployed architecture that was
to be migrated
and upgraded achieved initial integration between .NET and J2EE over
the WSRP
protocol through
the use of
The
AquaLogic Interaction .NET Application Accelerator.
The .NET Accelerator
allowed
the applications that were written in ASP.NET and deployed on a
Microsoft Internet Information Server (IIS)
to interact with a WebLogic Portal
application deployed on a WebLogic (J2EE application) Server (both version 9.2,
the state of
the art at
the time of its creation). At
the time this
architectural decision for
the application was made, both
the AquaLogic and
WebLogic brands were owned by BEA Systems.
The AquaLogic brand included
products acquired by BEA through
the acquisition of Plumtree, whose flagship
product was a portal platform available in both J2EE and .NET versions. As part
of this dual technology support an adaptor was created
to facilitate
the use of
WSRP as a communication protocol where customers wished
to integrate components
from both versions of
the Plumtree portal.
The adapter evolved over several
product generations
to include a broad array of both standard and proprietary
WSRP integration capabilities.
Later, BEA Systems was acquired by Oracle. Over
the course
of several years Oracle has acquired a large number of portal applications and
has taken
the strategic direction
to migrate users of these myriad (and
formerly competitive) products
to the Oracle WebCenter technology stack. As
part of Oracle’s strategic technology roadmap, older portal products are being
schedule for end of life, including
the portal products that were part of
the
BEA acquisition.
The .NET Accelerator has been modified over a very long
period of time with features driven by users of that product and developed
under three different vendors (each a direct competitor in
the same solution
space prior
to merger).
The Oracle
WebCenter WSRP Producer for .NET was
introduced much more recently with
the key objective
to specifically address
the needs of
the WebCenter customers developing solutions accessible through
both J2EE and .NET platforms utilizing
the WSRP
specifications.
The Oracle Product Development Team also provides these
insights on
the drivers for developing
the WSRP Producer:
*****************************************
Support for ASP.NET AJAX. Controls using
the ASP.NET AJAX script
manager do not function properly in
the Application Accelerator for .NET.
Support 2 way SSL in WLP. This was not possible with
the
proxy/bridge set up in
the existing Application Accelerator for .NET.
Allow developers
to code
portlets (Web Parts) using
the .NET
framework rather than a proprietary framework. Developers had
to use
the Application
Accelerator for .NET plug-ins
to Visual Studio
to manage preferences and
profile data. This is now replaced
with
the .NET Framework Personalization (for preferences) and Profile
providers.
The WSRP Producer for .NET was created as a new way of
developing .NET portlets. It was never
designed
to be an upgrade path for
the Application Accelerator for .NET. .NET developers would create new .NET portlets
with
the WSRP Producer for .NET and leave any existing .NET portlets running in
the Application Accelerator for .NET.
*****************************************
The advantage
to creating a new solution for WSRP is a
product that is far easier for Oracle
to maintain and support which in turn improves
quality, reliability and maintainability for their customers. No changes
to
J2EE applications consuming
the WSRP portlets previously rendered by
the.NET
Accelerator is required
to migrate from
the Aqualogic WSRP solution. For some
customers using
the .NET Accelerator
the challenge is adapting their current
.NET applications
to work with
the WSRP Producer (or any other WSRP adapter as
they are proprietary by nature). Part of this adaptation is
the need
to deploy
the .NET applications as a child
to the WSRP producer web application as root.
Differences between .NET Accelerator and WSRP
Producer
Note: This section is
for those who are curious about why
the migration is not as pluggable as
something such as changing security providers in WebLogic Server. You can skip
this section in its entirety and still be just as competent in performing a
migration as if you had read it.
The basic terminology used
to describe
the participating
applications in a WSRP environment are
the same when applied
to either
the .NET
Accelerator or
the WSRP Producer: Producer and Consumer. In both cases
the .NET application serves as what
is referred
to as a WSRP environment as
the Producer.
The difference lies in
how the two adapters create
the WSRP
translation of
the .NET application.
The .NET Accelerator, as
the name implies,
is meant
to serve as a quick way of adding WSRP capability
to a .NET
application. As such, at a high level,
the .NET Accelerator behaves as a proxy
for requests between
the .NET application and
the WSRP Consumer. A WSRP request
is sent from
the consumer
to the .NET Accelerator,
the.NET Accelerator
transforms this request into an ASP.NET request, receives
the response, then
transforms
the response into a WSRP response.
The .NET Accelerator is deployed
as a stand-alone application on IIS.
The WSRP Producer is deployed as a parent application on IIS
and all ASP.NET modules that will be made available over WSRP are deployed as
children of
the WSRP Producer application. In this manner,
the WSRP Producer
acts more as a Request Filter than a proxy in
the WSRP transactions between
Producer and Consumer.
Highly Recommended
Enabling Logging
Note: You can skip
this section now, but you will most likely want
to come back
to it later, so
why not just read it now?
Logging is very helpful in tracking down
the causes of any
anomalies during testing of migrated portlets.
To enable
the WSRP Producer
logging, update
the Application_Start method in
the Global.asax.cs for your .NET application by adding
log4net.Config.XmlConfigurator.Configure();
IIS logs will usually (in a standard configuration) be in a
sub folder under C:\WINDOWS\system32\LogFiles\W3SVC.
WSRP Producer logs will be found at C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault\Logs\WSRPProducer.log
InputTrace.webinfo and OutputTrace.webinfo are located under
C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault and can be useful in
debugging issues related
to markup transformations.
Things You Must Do
Merge Web.Config
Note: If you have been
skipping all
the sections that you can, now is
the time
to stop and pay
attention J
Because
the existing .NET application will become a
sub-application
to the WSRP Producer, you will want
to merge required settings
from
the existing Web.Config
to the one in
the WSRP Producer.
Use
the WSRP Producer Master Page
The Master Page installed for
the WSRP Producer provides common,
hiddenform fields and JavaScripts
to facilitate portlet instance management and
display configuration when
the child page is being rendered over WSRP. You add
the
Master Page by including it in
the <@ Page declaration with MasterPageFile="~/portlets/Resources/MasterPages/WSRP.Master"
. You then replace:
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
With
<asp:Content
ID="ContentHead1" ContentPlaceHolderID="wsrphead"
Runat="Server">
And
</HEAD>
<body>
<form
id="theForm" method="post" runat="server">
With
</asp:Content>
<asp:Content ID="ContentBody1"
ContentPlaceHolderID="Main" Runat="Server">
And finally
</form>
</body>
</HTML>
With
</asp:Content>
In
the event you already use Master Pages, adapt your
existing Master Pages
to be sub masters. See Nested ASP.NET Master Pages for a
detailed reference of
how to do this.
It Happened
to Me, It Might Happen
to You…Or Not
Watch for Use of Session or Request in OnInit
In
the event
the .NET application being modified has pages
developed
to assume
the user has been authenticated in an earlier page request
there may be direct or indirect references in
the OnInit method
to request or
session objects that may not have been created yet. This will vary from
application
to application, so
the recommended approach is
to test first. If
there is an issue with a page running as a WSRP portlet then check for
potential references in
the OnInit method (including references by methods
called within OnInit)
to session or request objects. If there are,
the simplest
solution is
to create a new method and then call that method once
the necessary
object(s) is fully available. I find doing this at
the start of
the Page_Load
method
to be
the simplest solution.
Case Sensitivity
.NET languages are not case sensitive, but Java is. This
means it is possible
to have many variations of SRC= and src= or .JPG and .jpg.
The preferred solution is
to make these mark up instances all lower case in
your .NET application. This will allow
the default Rewriter rules in
wsrp-producer.xml
to work as is. If this is not practical, then make duplicates
of any rules where an issue is occurring due
to upper or mixed case usage in
the .NET application markup and match
the case in use with
the duplicate rule.
For example:
<RewriterRule>
<LookFor>(href=\"([^\"]+)</LookFor>
<ChangeToAbsolute>true</ChangeToAbsolute>
<ApplyTo>.axd,.css</ApplyTo>
<MakeResource>true</MakeResource>
</RewriterRule>
May need
to be duplicated as:
<RewriterRule>
<LookFor>(HREF=\"([^\"]+)</LookFor>
<ChangeToAbsolute>true</ChangeToAbsolute>
<ApplyTo>.axd,.css</ApplyTo>
<MakeResource>true</MakeResource>
</RewriterRule>
While it is possible
to write
a regular expression that will handle mixed case usage, it would be long and
strenous
to test and maintain, so
the recommendation is
to use duplicate rules.
Is it Still Relative?
Some .NET applications base relative paths with a fixed root
location. With
the introduction of
the WSRP Producer,
the root has moved up one level. References
to ~/ will need
to be updated
to ~/portlets and many ../ paths will need
another ../ in front.
I Can See You But I Can’t Find You
This issue was first discovered while debugging modules with
code that referenced
the form on a page from
the code-behind by name and/or id.
The initial error presented itself as run-time error that was difficult
to
interpret over WSRP but seemed clear when run as straight ASP.NET as it
indicated that
the object with
the form name did not exist.
Since
the form name was no longer valid after implementing
the WSRP Master Page,
the likely fix seemed
to simply update
the references in
the code. However, as
the WSRP Master Page is external
to the code, a compile
time error resulted:
Error
155
The name 'form1' does not
exist in
the current
context
C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault\portlets\legacywebsite\module\Screens
\Reporting.aspx.cs
51
52 legacywebsite.module
Much hair-pulling research later it was discovered that it
was
the use of
the FindControl method causing
the issue. FindControl doesn’t
work quite as expected once a Master Page has been introduced as
the controls
become embedded in controls, require a recursion
to find them that is not part
of
the FindControl method.
In code where
the page form is referenced by name, there are
two steps
to the solution. First,
the form needs
to be referenced in code
generically with Page.Form. For example,
this:
ToggleControl ctrl = new ToggleControl(frmManualEntry, FunctionLibrary.ParseArrayLst(userObj.Roles));
Becomes this:
ToggleControl ctrl = new ToggleControl(Page.Form, FunctionLibrary.ParseArrayLst(userObj.Roles));
Generally
the form id is referenced in most ASP.NET
applications as a path
to a control on
the form.
To reach
the control once a
MasterPage has been added requires an additional method
to recurse through
the
controls collections within
the form and find
the control ID.
The following
method (found at Rick
Strahl's Web Log) corrects this very nicely:
public static Control FindControlRecursive(Control Root, string
Id)
{
if
(Root.ID == Id)
return
Root;
foreach
(Control Ctl in
Root.Controls)
{
Control
FoundCtl = FindControlRecursive(Ctl, Id);
if
(FoundCtl != null)
return
FoundCtl;
}
return null;
}
Where
the form name is not referenced, simply using
the
FindControlRecursive method in place of FindControl will be all that is
necessary. Following
the second part of
the example referenced earlier,
the
method called with Page.Form changes its value extraction code block from this:
Label lblErrMsg =
(Label)frmRef.FindControl("lblBRMsg"
To this:
Label lblErrMsg = (Label) FunctionLibrary.FindControlRecursive(frmRef,
"lblBRMsg"
The Master That Won’t Step Aside
In most migrations it is preferable
to make as few changes
as possible. In one case I ran across an existing Master Page that would not
function as a sub-Master Page. While it
would probably have been educational
to trace down why,
the expedient process
of updating it
to take
the place of
the WSRP Master Page is
the route I took.
The changes are highlighted below:
…
<asp:ContentPlaceHolder ID="wsrphead"
runat="server"></asp:ContentPlaceHolder>
</head>
<body leftMargin="0" topMargin="0">
<form
id="TheForm" runat="server">
<input type="hidden" name="key"
id="key" value="" />
<input type="hidden"
name="formactionurl" id="formactionurl" value=""
/>
<input type="hidden" name="handle"
id="handle" value="" />
<asp:ScriptManager
ID="ScriptManager1" runat="server"
EnablePartialRendering="true" >
</asp:ScriptManager>
This approach did not work for all existing Master Pages,
but fortunately all of
the other existing Master Pages I have run across worked
fine as a sub-Master
to the WSRP Master Page.
Moving On
In Enterprise Portals, even after you get everything
working,
the work is not finished. Next you need
to get it where everyone will
work with it.
Migration Planning
Providing that
the server where IIS is running is adequately
sized, it is possible
to run both
the .NET Accelerator and
the WSRP Producer on
the same server during
the upgrade process.
The upgrade can be performed
incrementally, i.e., one portlet at a time, if server administration processes
support it. Those processes would include
the ability
to manage a second
producer in
the consuming portal and
to change over individual portlet
instances from one provider
to the other. If processes or requirements demand
that all portlets be cut over at
the same time, it needs
to be determined if
this cut over should include a new producer, updating all of
the portlets in
the consumer, or if
the WSRP Producer portlet configuration must maintain
the
naming conventions used by
the .NET Accelerator and simply
change the WSRP end
point configured in
the consumer.
In some enterprises
it may even be necessary
to maintain
the same WSDL end point, at which point
the IIS configuration will be where
the updates occur.
The downside
to such a requirement is that it
makes rolling back very difficult, should
the need arise.
Location, Location, Location
Not everyone wants
the web application
to have
the
descriptively obvious wsrpdefault location, or needs
to create a second WSRP
site on
the same server.
The instructions below are from
the product team and,
while targeted towards making a second site, will work for creating a site with
a different name and then remove
the old site. You can also
change just
the
name in IIS.
Manually Creating a WSRP Producer Site
Instructions (NOTE: all executables used are
the same ones
used by
the installer and “wsrpdev” will be
the name of
the new instance):
1. Copy
C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault
to C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev.
2. Bring up a command window as an administrator
3. Run
C:\Oracle\Middleware\WSRPProducerForDotNet\uninstall_resources\IISAppAccelSiteCreator.exe
install WSRPProducers wsrpdev "C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev"
8678 2.0.50727
4. Run
C:\Oracle\Middleware\WSRPProducerForDotNet\uninstall_resources\PermManage.exe
add FileSystem C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev "NETWORK
SERVICE" 3 1
5. Run
C:\Oracle\Middleware\WSRPProducerForDotNet\uninstall_resources\PermManage.exe
add FileSystem C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev EVERYONE 1 1
6. Open up
C:\Oracle\Middleware\WSRPProducerForDotNet\wsdl\1.0\WSRPService.wsdl and
replace wsrpdefault with wsrpdev
7. Open up C:\Oracle\Middleware\WSRPProducerForDotNet\wsdl\2.0\WSRPService.wsdl
and replace wsrpdefault with wsrpdev
Tests:
1. Bring up a browser on
the host itself and go
to
http://localhost:8678/wsrpdev/wsdl/1.0/WSRPService.wsdl and make sure that
the
URLs in
the XML returned include
the wsrpdev changes you made in step 6.
2. Bring up a browser on
the host itself and see if
the
default sample comes up:
http://localhost:8678/wsrpdev/portlets/ASPNET_AJAX_sample/default.aspx
3. Register
the producer in WLP and test
the portlet.
Changing
the Port used by WSRP Producer
The pre-configured port for
the WSRP Producer is 8678. You
can
change this port by updating both
the IIS configuration and C:\Oracle\Middleware\WSRPProducerForDotNet\[WSRP_APP_NAME]\wsdl\1.0\WSRPService.wsdl.
Do You Need
to Migrate?
Oracle Premier Support ended in November of 2010 for AquaLogic
Interaction .NET Application Accelerator 1.x and Extended Support ends in
November 2012 (see http://www.oracle.com/us/support/lifetime-support/lifetime-support-software-342730.html
for other related dates). This means
that integration with products released after November of 2010 is not
supported. If having such support is
the policy within your enterprise, you do
indeed need
to migrate. If changes in your enterprise cause your current
solution with
the .NET Accelerator
to no longer function properly, you may need
to migrate. Migration is a choice, and if
the goals of your enterprise are
to
take full advantage of newer technologies then migration is certainly one
activity you should be planning for.
