Friday, April 30, 2010

Monitoring Dashboard in WLS Administration Console introduced

Type: Info
Applies to: Oracle WebLogic Server: 10.3.3

Just after JDeveloper 11.1.1.3 was released of course I had to give it a try;-) Somehow I am always curious about changes the Admin Console of the WLS. Since WLS is integrated it is really easy and quick to do. Just start a simple ADF Fusion Web app and open http://localhost:7101/console

The following things catched my eyes:

a) The Admin Console  is internationalized. On my laptop the login form appears in german by default now:
image 
To change the language you just have to change the preferred language in the browser settings and reload the page.

b) On the Homepage I recognized a new entry:
image 
This opens the so called “Monitoring Dashboard” which obviously is developed by ADF Faces RC. Cool! No activation of the diagnostic console needed! No slowly loading Applet;) Thanks!

image

c) the diagnostic-console can still be activated in the preferences but just in order to inform that it has been replaced by the new monitoring dashboard….and the Request Performance

d) Request performance
image At the first look the view is a bit disappointing because you will not see anything here until you “…first configure WLDF instrumentation to use the ElapsedTimeAction diagnostic action attached to "Around" diagnostic monitors. Only data from the ElapsedTimeAction action is shown on this page.” See the context help for more information. (Maybe I will blog about it in more detail in a separate post)

It would be nice if this information (to first configure a WLDF inst) would be visible as INFO or WARNING directly on the Request Performance Tab.

Sunday, April 18, 2010

ADF 11g: Be aware of the right run context

Used version: JDeveloper 11.1.1.2.0

Problem description

Last week I did a two days training on fusion development with Oracle ADF BC / Faces RC. Everything worked fine except the following:

While doing the “Part 2 Create a Simple User Interface” from the cue cards some of the attendees (and me too) had the effect that at runtime the control flow rule defined in the bounded task flow did not worked.

image

So what actually went wrong here at runtime? Why a click on the Edit Order-Button did not trigger the control flow rule? Instead of that you just stay on the browseOrders page.

Solution

After some time of investigation I recognized that I had started the application under the wrong context. To test the application I selected browseOrders.jspx in the application navigator and have chosen “Run” because normally I am using taskflows with page fragments. So in real world projects you typically won’t start the application from a bounded task flow.

But because in this example the taskflow is based on whole pages rather than page fragments, the application must be started from within the bounded taskflow. Otherwise the control flow rules won’t be working at runtime!

image

You can check the correct run context by examining the URL in the browser. In the wrong case the URL will be …/faces/browseOrders.jspx of course whereas running the app from taskflow the URL is …/faces/adf.task-flow?adf.tfId=orders-flow&adf.tfDoc=/WEB-INF/orders-flow.xml

Lesson learned

Don’t panic if control flow rules seem not work as expected. Check the following

  • Which type of taskflow? (bounded /unbounded, with/without page fragment)
  • Does the action attribut of the command component match the control flow outcome?
  • How the application has been started?