Scheduling Oracle SOA Suite Composite Applications (or whatever you want) in Weblogic

After reading a nice article about TimerManager functionality in Weblogic, i wanted to see how easy it would be to schedule my test composite application.

First deploy your composite and go to SOA > soa-infra > default > Test > WSDL.
Copy/paste the wsdl, this one we will use to generate the web proxy.
Back in JDeveloper create a new Application (or add it to an existing one), and create a new Web Project.

Select the jsp option, we will use this page later to trigger the scheduler.

Generating the Web Proxy

Right mouseclick on the Project > New > Business Tier > Web Services > Web Service Proxy


Fill in the url which we copy/pasted from the Test console of the composite application.


Fill in your package structure


We only have a synchronious service call


Here we have the option to apply any policies

This will generate all the code we need to invoke the composite application (wsdl).
The class with the name ending with ‘_ptClient’ contains all the code needed to do the invoke from java. This we will reuse later on.
For a little test, change the code so it calls the correct method of your composite application and check the console to see if it triggers a new instance.
Now we know for sure the proxy code itself is working, so we can go on with the code to schedule the invoke.

TimerManager

The code of the TimerManager i borrowed from this excellent blog.
Create both ‘TimerServlet’ servlet and the ‘TimerListener’ class, edit web.xml, and add link to the servlet to the index.jsp which we generated in one of the earlier steps.

Now copy/paste the example code of the ‘_ptClient’ class to the ‘TimerListener’ class, and select the method you want to call (in my case the ‘process’ method).

Deploy and Run

Add a new WAR File Deployment Profile to the project.
Right mouseclick on the Project > Deploy > MyTimerApp and either select to deploy right away to the Application Server or to a local WAR archive.

Go to the url of the index.jsp to trigger the scheduler, for example http://localhost:8001/MyBPELTimer-MyTimerClient-context-root/index.jsp

Console output

inside timerExpired()
Starting schedule bpel, Fri May 21 12:25:03 CEST 2010
Finishing schedule bpel, response is : setOutput
exiting timerExpired()

inside timerExpired()
Starting schedule bpel, Fri May 21 12:25:13 CEST 2010
Finishing schedule bpel, response is : setOutput
exiting timerExpired()

inside timerExpired()
Starting schedule bpel, Fri May 21 12:25:23 CEST 2010
Finishing schedule bpel, response is : setOutput
exiting timerExpired()

Overview of the Composite instances which were created

Resources

http://weblogic-wonders.com/weblogic/2010/05/02/weblogic-timermanager-for-scheduling-tasks/
http://blogs.oracle.com/jamesbayer/2009/04/a_simple_job_scheduler_example.html

Download

JDeveloper Project – It includes the generated code/imports against my own composite application. Regenerate the code against your own wsdl, and revalidate the code.

Advertisements

Weblogic, side-by-side deployment

Weblogic Server supports a nice feature called side-by-side deployment (or versioned deployment). This function is extremely usefull when you need to deploy a new version of an application and still keep the old one up and running. So the running instances will still use the current version and all new instances will be able to invoke the new deployed version of the application.
As soon as all the sessions who’re using the old version of the application are expired, Weblogic will recognize it and will deactivate the old version. So at this moment only the new deployed version is active and all new sessions will make us of it.

So how does this work.

You could either use wlst to deploy the application and specifiy the versionnumber on deployment as one of the parameters or you can use the manifest.mf file. We’ll be using the last one.

  1. Create a webservice project
  2. Edit to manifest file located in WebContent > META-INF and add the next on a new row : ‘WebLogic-Application-Version: v1’
    manifest
  3. Package the service and deploy it in the console

Deployment

  1. Go to the Weblogic Console > Deployments. Click ‘Lock & Edit’ and in the deployments part click Install
  2. Select the just created archive
    install-1
  3. Install this deployment as an application
  4. Optional Settings. And in here we will see the ‘Archive Version’ of our application. Change the name to ‘MyService’ and leave the rest on default value
    install-2

If you look in the list of deployments we will see our application is labeled with a version indication (v1).
deployment1
The current version is still active.

Now create a new version of the application and change the v1 in the manifest file to v2, and package it.

Update Deployment

  1. Go to the Weblogic Console > Deployments. Click ‘Lock & Edit’, select the application we want to update (MyService) and in the deployments part click Update
  2. Click Change Path of the source path and select the just created archive (v2), the application will be deployed as version v2

If we now look in the list of deployments, we will see 2 versions of our application deployed.
deployment2

Version v1 gets status ‘Retired’ and the new version v2 will get status ‘Active’.

Running instances
We have the next scenarios

  1. Version v1 is deployed. Deploy version v2. The new version v2 will get status ‘Active’ and the old version v1 will get status ‘Retired’.
    Since there aren’t any open sessions Weblogic will recognize this and changed the status of the version v1
  2. Version v1 is deployed and has open sessions. Deploy version v2. The new version v2 will get status ‘Active’ and the old version v1 will stay on status ‘Active’ untill all sessions to it will be closes. After that, Weblogic will change the status to ‘Retired’ and the only ‘Active’ version will be v2

Resources
http://edocs.bea.com/wls/docs100/deployment/redeploy.html#wp1020276
http://weblogic.sys-con.com/node/185310