Wednesday, June 19, 2013

Production Redeployment with ADF Shared WebLogic Libraries


Based on my previous post I wanted to know if we can achieve to redeploy parts of an ADF application by using shared WebLogic Libraries. In conjuction with the production redeployment WLS feature the overall goal is to prove that we can update modular ADF applications without downtime.

Introduction

The sample application consists of an employees taskflow that is bundled as ADF Library and deployed as shared library on WebLogic server. The sample is based on ADF 11.1.1.7 / WLS 10.3.5 / HR Schema.

First step: Create ADF Library as Shared WAR deployment

Goto JDev application with the containing Taskflow:

Create a MANIFEST.MF file under ViewController/src/META-INF/ with the following contents
The important parts are

Extension-Name: enpit.sample.empFlow
Specification-Version: 1.0
Implementation-Version: 1.0

Create ADF Library Deployment Profile for the empFlow on ViewController project with dependency on your Model project.
Make sure only connection name is Included in the Library

Having an ADF Library Deployment Profile in the employee taskflow application we create an additional Deployment profile (of type WAR) in the ViewController project. 

Under  WAR Options include the MANIFEST.MF file

Make sure to remove everything from Web Files contributors since we only want to wrap the ADF Library inside this WAR file.

Same to WEB-INF/classes. Exclude everything.

Under Profile Dependencies add the dependency to the ADF Library Profile

Goto WEB-INF/lib Filters and uncheck everything except the desired ADF Library JAR file.

With that WAR deployment configuration we are able to deploy -  the ADF Taskflow -  as shared library to the WebLogic server. (Select ViewController, right click, Choose Deploy > SharedADFLib ...to Application Server)

As a result the library shows up under Deployments in the WebLogic Admin Console

Deploy master application

In the master application that consumes the taskflow from the ADF Library we need to make sure
  • versioning is configured for application deployment
  • ADF Library is not bundled with the EAR
  • Library reference is added to the ADF Shared Library in weblogic.xml (not weblogic-application.xml)
To enable the versioning for the app deployment we add /src/META-INF/MANIFEST.MF file with the contents
Manifest-Version: 1.0
Weblogic-Application-Version: 1.0

Now goto the EAR deployment profile and add the MANIFEST.MF file under the EAR Options

Goto application descriptors Filters and exclude MANIFEST.MF. (Otherwise the EAR won't be created as JDeveloper will try to include 2 MANIFEST.MF files in the EAR. You will see this exception in the deployment log window).

Now exclude the ADF Library from the application deployment. Goto ViewController project properties of the master application and make sure the library is not deployed by default.

In the WAR deployment profile check that the ADF Library JAR is not included


Next create WEB-INF/weblogic.xml and add library reference to the ADF Shared Library.

Important note: In my first try I added that library reference in the weblogic-application.xml. That won't work. At deployment time there will be the following exception
[08:23:54 AM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application enpit_application1 [Version=1.0] on DefaultServer.: javax.faces.context.ExternalContext.
[08:23:54 AM] Weblogic Server Exception: weblogic.application.WrappedDeploymentException: javax.faces.context.ExternalContext
[08:23:54 AM]   See server logs or server console for more details.
[08:23:54 AM] weblogic.application.WrappedDeploymentException: javax.faces.context.ExternalContext
[08:23:54 AM] ####  Deployment incomplete.  ####
[08:23:54 AM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)

So don't try this.

Doing it right you should see the following in Admin Console:

Test the application. It loads the taskflow and displays version 1

Next Step: Test production redeployment based on new version of ADF Shared Library
We are going to 
  • Make changes in employees taskflow
  • Change Library Implementation-Version to 1.1
  • Deploy ADF Library as Shared WLS Library
  • Increase application version to 1.1
  • Redeploy master application
So first we increase the library version
and make some simple changes to the JSFF

Next: Deploy ADF Library to JAR
Next: Deploy sharedADFLib Deployment to IntegratedWebLogic

Check deployment in the Admin Console

Goto the master application and change Weblogic-Application-Version to 1.1

and deploy the master application to Verify deployment in the Admin Console once again. You should notice that previous application (1.0) is in stop running state. Actually it is meant to be RETIRED Mode. Existing web sessions will be served by that version 1.0.

Open a NEW BROWSER WINDOW (a different browser window to be dead sure) and point to the master application URL. You should see new version of the integrated Taskflow.

Conclusion

This mechanism is really powerful. It lets you redeploy application parts - maybe of a huge application - without downtime.

Download Sample Application


Related Posts

6 comments:

  1. When should this approach be considered? Shared task flows across deployed applications? I'd love to hear a good example. My understanding is that we can deploy war files with little or no downtime as well. Love to hear more from an architectural planning approach.

    Great blog though,

    BradW

    ReplyDelete
  2. Hi Brad,

    thx for your feedback. That is a good question indeed. Main motivation for me was to prove it actually works since I heard doubts of some developers it does not work ;)

    From architectural point of view one interesting use case surely is ADF Skinning that can be deployed once and consumed by many Applications.

    A common User registration (or kind of) Taskflow to be shared by separate apps that maybe belong to a huge app suite.

    Some forms customers complain that there is only a "deploy all" approach although only one simple form has been changed. Those separate "forms" (use cases) could be deployed separately without affecting the overall deployment. This approach is less risky and faster to single WAR/EAR deployment.

    So far my thoughts on possible scenarios.

    @all If there are any other scenarios feel free to comment or start a discussion on ADF EMG Group.

    Regards,
    Andreas

    ReplyDelete
  3. Am i missing something? somehow the change in the later version of shared lib is not taking effect until i restart the main app. I followed exactly same steps. Trying on Integrated WLS on Jdev 11.1.1.7 with WC PS7. Is there any other setting that enables 'Production mode deployment' ?

    I versioned both the apps. but still no luck.

    ReplyDelete
  4. Hi echo,
    sorry can't reproduce your behaviour. If the wepApp is deployed including the "Weblogic-Application-Version" Metadata then this version should pic up the referenced shared library with highest version number.

    BR, Andreas

    ReplyDelete
  5. One other question around user experience while re-deploying a shared library. What will be the impact on the users running the application? Would we still need an outage or, will the application start using the new classes, taskflows etc? I will have to try it out, but was curious your thoughts on this.

    Thanks again,


    BradW

    ReplyDelete
    Replies
    1. Hi Brad,

      the main idea behind the concept it is to deploy a new version of a shared library in parallel. Now there are 2 options to make these new version (of a module that is provided by the shared lib, e.g. taskflow, etc) available to the running application
      Option 1: Stop application, start application. => Short outage.
      Option 2: Make use of "Production redployment". That means: Deploy new version of the application side by side to the existing application version. Now existing clients sessions will be served from the existing (old) application plus old version of shared library bundled taskflow for example. New client sessions will be served by the new application version.

      Further: Using shared libraries as deployment artefakt for "business applicaiton units" the risk of a broken deployment can be minified.

      BR
      Andreas

      Delete