Red Samurai Performance Audit Tool - Up and Running

It's been some time since we created Red Samurai Performance Audit Tool in August, 2012. This tool was deployed and it was logging all performance related issues in one of the projects, already for 8 months. I thought to share with you how it goes, below you can see the results logged continuously from August, 2012 till now:

As project was growing and becoming more complex, performance was going down. But after complexity reached a peak and we were able to locate performance bottlenecks with audit tool for fixing - performance started to improve in the recent months.

Oracle University Training - ADF/WebCenter Spaces 11g & BPM Suite 11g Integration

I will teach one more Oracle University training course, this time in Slovakia, Bratislava. Training will be about ADF/BPM/WebCenter integration and is scheduled for November 7th - 8th. You can get more details and registration on Oracle University site.

If you are interested in ADF/BPM integration topic - read my previous blog posts on this topic.

ADF Generator for Dynamic ADF BC and ADF UI - Recreate

Last year in November, I was blogging about ADF generator for dynamic ADF BC and ADF UI. This approach allows to generate ADF BC from metadata and draw ADF UI dynamically based on ADF BC structure. You can read more about it here. This approach works without issues. However, if you want to change dynamic ADF BC and redraw ADF UI while staying on the same fragment or page, there is special trick to recreate dynamic iterator declared in Page Definition. This trick is described in Duncan Mills blog - Refresh Problems using Adaptive Bindings, I will apply it to my sample app posted here.

Without this trick applied, if you try to change ADF BC dynamic VO - there will be error generated from ADF bindings:

Sample application - ADFDynamicReportUI_v2.zip, works better with the workaround applied. Just before ADF BC dynamic VO is changed, ADF bindings iterator is refreshed - this allows to reload ADF View based on changed ADF BC VO:

Iterator is defined in Page Definition, this is regular static iterator created out of predefined VO (later dynamically initialized, see my previous blog mentioned above). There is not table or attribute bindings, because I'm using ADF dynamic form component on the ADF UI:

Dynamic VO is constructed in AM Implementation class, based on parameter - different VO structure is created:

Different SQL statement is created:

It works now to switch to different VO structure - see the checkbox coming as part of recreated VO:

Workaround - BPM 11g JDeveloper IDE PS5 Bug for Process ExecData

BPM 11g JDeveloper IDE PS5 bug described in my previous blog - BPM 11g JDeveloper IDE PS5 Bug for Process ExecData can be handled with workaround. Thanks to colleague Danilo Schmiedel who provided workaround. Workaround is pretty simple but effective - refresh BPM project from BPM Project Navigator window. Important here - refresh not from Application Navigator, but from Project Navigator, exactly as you can see on this screenshot:

ExecData object will be accessible again, even after JDeveloper restart:

BPM 11g JDeveloper IDE PS5 Bug for Process ExecData

I was hitting ugly BPM 11g JDeveloper IDE PS5 bug recently. This bug is strange, because is reproduced just after JDeveloper restart for the working process. Imagine you have valid BPM process, everything works well - restart JDeveloper and suddenly BPM process is corrupted. In my specific scenario I was referencing system attribute from BPM execData - execData object is suddenly lost after JDeveloper restart. I don't have solution for this yet, just want to share with you the use case for this BPM 11g JDeveloper IDE PS5 bug.

Sample application (SimpleProcess.zip) contains BPM process with one basic Human Task activity:

When you create Human Task activity - execData object is available in Data Associations:

We can use various system variables from execData, for example taskId. We could assign it to the local process variable:

It works well, until you restart JDeveloper 11g PS5. After the restart - there is an error in Human Task:

As you can see - execData object is not found anymore in BPM process - too strange:

DB Connection Leaking During ADF Login

I will describe a case of leaking DB connections during ADF login phase. This case is reproduced for ADF application with Login screen and programmatic login action from managed bean. If you call ADF BC before calling ADF authentication servlet and doing authentication - no DB connection leaking. But if you call ADF authentication servlet first and then as next action call ADF BC in the same method - DB connection will remain active.

Download sample application which demonstrates this case - SecurityFormLogin_v6.zip. Sample is configured to use DB connection pooling for ADF, this means DB connection will be released after request is completed (read more here: Stress Testing Oracle ADF BC Applications - Do Connection Pooling and TXN Disconnect Level):

Temporary in memory store is enabled to keep data between requests, when DB connection is returned to the pool:

To test this sample application, login into:

ADF screen will be rendered after authentication is completed:

Here you can see source code of Login class, where I'm calling ADF BC before performing ADF authentication:

ADF BC call is done through ADF bindings:

In this case, when ADF BC logic is invoked before calling ADF authentication servlet - DB connection is used and immediately returned back to the pool:

Test now with ADF BC invocation just after calling ADF authentication in the same login method:

You will notice now - DB connection acquired by ADF BC from Login method, will not be returned back to the pool:

Imagine now, if the same behavior will be reproduced in production. This means if you support 500 concurrent users, they will reserve 500 DB connections. This may break your application, if DB connections max size is not large enough. My point is - test your application before going to production and monitor DB connection usage, this will help to have stable ADF application.

Coding Validation in ADF BC View Object Before Commit Method

First thing you should do - never implement validation logic in beforeCommit() method, this is especially true for beforeCommit() in VO Implementation class. Why? Because beforeCommit() method will be invoked even if data will not be changed, it is enough just to open VO instance and query data. We can have many VO instances for the same EO and all of them will trigger beforeCommit() methods implemented in VO Implementation. You could open one page, close it without changes and open another page. Once you invoke Commit operation in second page, beforeCommit() method from the VO's involved into first page will be called as well. This means it would trigger validation for the page which is currently closed. On other hand, it is understandable why developers try to code validation logic in beforeCommit(), standard ADF BC validation lifecycle is unpredictable sometimes, it fires validation rules too early. But it still not a good excuse to use beforeCommit() - I will show you why.

Download sample application - BeforeCommitVOApp.zip. This application contains two View Objects based on two different Entity Objects, each View Object is mapped with Implementation class:

First VO - Departments, contains overridden beforeCommit() method, where developer implemented validation rule to check department name text length:

Second VO - Employees, contains overridden beforeCommit() method, where validation rule to check salary amount is implemented:

Open Departments VO in ADF BC tester and close it without any change:

Open Employees VO in ADF BC tester, change data now and try to save it by committing transaction - you will get validation error from the first (already closed) Departments VO, fired from beforeCommit() method:

We can see it in the log - ADF BC tries to update Employees record, but just before completing transaction commit, it calls beforeCommit() from previously opened VO and it fails there. Entire transaction is interrupted:

Issue with First Transient Attribute in ADF BC Entity Object

There is one interesting bug reproduced across all ADF versions - related to the order of attributes in ADF BC Entity Object. Specifically to the order of transient attributes within the Entity Object attributes list. If transient attribute is set as a first attribute in the Entity Object - it will break, when trying to commit transaction. SQL Select for Update executed from Entity Object will fail, because ADF BC includes invalid comma for the transient attribute defined in the Entity.

Here is the case - add transient attribute to the EO and make sure it is set as first in the list:

Now add the same attribute from EO to VO (field order in VO is not important):

Transient attribute is created in the EO, VO SQL includes only DB column fields - this is correct:

However, when you run such VO, change data and try to commit - will get error about wrong select:

In the log we can see that SQL statement is corrupted - there is comma before the first attribute:

You can fix this error, by moving first transient attribute lower in the list:

SQL Select works well with the fix above applied:

Here you can download working sample application - FirstTransientApp.zip.

Reusable ADF Region with Dialog Framework

This post is about reusable ADF region and its usage from ADF Dialog Framework. If we have ADF Task Flow with fragments and want to use Dialog Framework, we need to create intermediate ADF Task Flow with pages and include our reusable region there - this will allow to load ADF Dialog from the fragment (dialog is always running in ADF page). I will describe in this post how to pass data from/to ADF region included into ADF Dialog to the calling fragment.

There is main ADF Task Flow in the sample - empls-flow (download sample application ReusableDialogRegionApp.zip):

This task flow is configured to call intermediate ADF Task Flow with wrapper page. We are passing  and getting parameters to/from the dialog:

Dialog is opened from the button in the main employees fragment:

Button is configured to open dialog:

There is dialog listener defined for this button, it receives return value. Alternatively we can get return value from the dialog return parameter directly:

Intermediate ADF task flow (which actually implements ADF dialog), contains a page and return activity. This page is only a wrapper, it includes reusable ADF region:

Intermediate ADF task flow with wrapper page defines input and output parameters:

Wrapper page contains Close button, this button sets return value, it retrieves return value from the bindings. Because Data Control is shared between reusable ADF region and intermediate ADF task flow with wrapper page, we can access bindings from ADF region and return it from the wrapper page. You can see that this page includes our reusable ADF region:

Here is binding definition for the attribute in the page definition for wrapper page:

And the last bit - ADF reusable region, JSF fragment view:

Bindings for ADF reusable region, you can see where CountryId attribute value is set. We are getting the same value in dialog wrapper page through shared Data Control:

I should mention one important thing - intermediate ADF dialog task flow is configured to run in isolated scope. This is important and allows to reset reusable ADF region in the dialog always to its initial state on opening:

Countries region is loaded and DepartmentId value is passed into:

Selected value is returned back:

The same reusable region is opened from another fragment - region state is reset, user can select value and return it: