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.
