millseconds to CT date time zone

select to_char(from_tz(CAST (to_date('1970-01-01 00:00:00000','yyyy-mm-dd HH24:MI:SSSSS') +(wl_access_time)/(1000*24*60*60) AS TIMESTAMP),'GMT')at  TIME ZONE 'US/Central','YYYY-MM-DD HH:MI:SS') from wl_servlet_sessions;

javax.xml.ws.WebServiceException: javax.net.ssl.SSLKeyException: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received.

Webservice call fails with BAD certificate error SSL certificate cipher signed by SH256WITHRSA. 

This cipher is not supported in weblogic server by default.

Certicom is currently the default SSL implementation in Weblogic Server. However, JSSE may be enabled as an alternative SSL implementation.The Certicom SSL implementation is currently deprecated and will be replaced by the JSSE-based implementation in a future release.

Error Text

javax.xml.ws.WebServiceException: javax.net.ssl.SSLKeyException: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received.

Resolution 

Use JSSE SSL Based Implementation by enabling JSSE under server_name--> SSL --> advanced

PKCS error

In case could not parse key values exception was thrown after enabling JSSE

weblogic.security.SSL.jsseadapter: SSLENGINE: Exception occurred during SSLEngine.unwrap(ByteBuffer,ByteBuffer[]).

java.lang.RuntimeException: Could not parse key values

add -Dsun.security.pkcs11.enable-solaris=false to server start Reference

http://docs.oracle.com/cd/E23943_01/web.1111/e13707/ssl.htm#SECMG494

Oracle bug document number (2001812.1)

ADF DynamicTable is not picking up iterator changes from model layer after rollback is invoked

DynamicTable isRefreshRequired method caches the ViewDefName, then it compares the cached value with actual viewDefName, if they are the same it skips child creation.

This fix was needed to force the dynamic table to refresh in case of rollback to recreate its children
                    ((DynamicTable)child).getFacesBean().setProperty(PropertyKey.createPropertyKey("ViewDefNameForTable"), null);

Changing ViewCriteria Operators on fly - Used to filter TreeTable elements

In this scenario I developed a search form that would filter treeTable elements based on parent child view access link.

I have Parent viewCriteria used in the page as AF:Query along with TreeTable, There is also a child viewCriteria applied to the child view, the parent view has the same query in the exists clause to filter parent items.

Parent View:

Child View:

Then use this code to filter and change view Criteria operators by passing the change of the operators from the parent view criteria to the detail one:

Make DynamicForm survive passivation/Activation - Error javax.el.PropertyNotFoundException: Target Unreachable, 'DynamicForm_dynamic_VO_form1' returned null

This was very wired error when creating viewObjects and ViewDef Objects on the fly and using dynamicForm tag.

I just used the code mentioned in Thirumalaisamy blog and created a method used as a common method when creating Def Objects.

public ViewDefImpl createDynamicViewDef(String packagePath, String viewName) {
PackageDefImpl newPackage;
java.lang.reflect.Method setParentMth;
try {
java.lang.reflect.Method mth =
MetaObjectManager.class.getDeclaredMethod("createContainerDefObject", new Class[] { boolean.class });
setParentMth = oracle.jbo.server.DefObject.class.getDeclaredMethod("setParent", new Class[] { oracle.jbo.common.NamedObjectImpl.class });
mth.setAccessible(true);
setParentMth.setAccessible(true);
newPackage = (PackageDefImpl)mth.invoke(MetaObjectManager.getSingleton(), new Object[] { true });
} catch (Exception ex) {
         throw new JboException(ex);
        }
newPackage.setDefScope(PackageDefImpl.DEF_SCOPE_SESSION);
newPackage.setName(packagePath);
newPackage.setFullName(packagePath);
MetaObjectManager.insertSessionMetaObject(newPackage.getFullName(), newPackage);
ViewDefImpl reportParamsViewDef = new ViewDefImpl(packagePath + "." + viewName);
reportParamsViewDef.setFullName(packagePath + "." + viewName);
reportParamsViewDef.setComponentClass(ViewObjectImpl.class);
try {
    setParentMth.invoke(reportParamsViewDef, new Object[] { newPackage });
   } catch (Exception ex) {
   ex.printStackTrace();
   throw new JboException(ex);
}
  return reportParamsViewDef;
}


Many thanks to Thirumalaisamy Thangavel who started the whole topic with oracle support
http://thirumalaisamyt.blogspot.com/2013/04/life-of-dynamic-vo-eo-across.html

Dynamic Form Iterator

Great resources to create dynamic form iterator
http://andrejusb.blogspot.com/2013/03/adf-generator-for-dynamic-adf-bc-and.html

Refresh issue need to pay attention to when creating dynamic form specially when rebuilding the form on the same page, execute this before invoking the method that will recreate you dynamic VO.

https://blogs.oracle.com/groundside/entry/refresh_problems_using_adaptive_bindings

Oracle BI set User Identifier before running report

You can set a pre process property to execute a function at database level before running some set of queries. This is can be accomplished at report DataModel layer or before BI server connects to database in JNDI pre process property and post process property.


set_pre_process_username(:xdo_user_name,'AM START','BI')

set_post_process_username(:xdo_user_name,'AM FINISH','BI')

in the example above I am passing the logged in user in BI to the database to accomplish some kind of database row filtering.

A java usage (BI publicReportService):

You can impersonate the logged\-in user in your Java application by using the impersonate and runReportInSession methods.

String sid =reportService.impersonate(biUserName, biPass, loggedInUser);
repRes = reportService.runReportInSession(repReq, sid);

Clear TreeTable or Table selectedRowKeys from MDS

table.getSelectedRowKeys().clear();
RowKeySetAttributeChange rks =
    new RowKeySetAttributeChange(table.getClientId(FacesContext.getCurrentInstance()), "selectedRowKeys",new RowKeySetTreeImpl());
            RequestContext.getCurrentInstance().getChangeManager().addComponentChange(FacesContext.getCurrentInstance(), table, rks);

ADF PASSIVATION/ACTIVATION - previously selected row gets populated in detail ViewObject, even it doesn't belong to Master ViewObject

JDeveloper 11.1.1.7

Updateable detail view object with viewCriteria applied at application module level, populates previously selected row from another parent, this only happens when running the application while application module pool set off to force Passivation/Activation, and the detailed viewObject have a viewCriteria applied to it.

This is reported to Oracle under (Bug 19203478 - ADF PASSIVATION/ACTIVATION - PREVIOUSLY SELECTED ROW GETS POPULATED).

A sample ADF application is attached here (EmplDeptPassivate.zip)

To reproduce this:
- Create new ADF application with default Model project and view Controller
- Database connection points to HR schema
- Create Business components from tables, only select Employee and Department tables, don't add the view Objects to application module.
- Add DepartmentView as master vo then EmployeesView as detail for departments.
- Create view criteria("EmployeesViewCriteria") in EmployeesView where ManagerId=102
- Return back to application module -> data model and edit EmployeeView1 and apply the view criteria.
- Set Application Module pool off, and disconnect upon release on
- Create a view criteria in DepartmentView to search for department name used in search page only.
- Create two ADF pages in bounded or unbound Taskflow
- First page drag DepartmentViewCriteria and add Query with Table, select single selection, filtering and sorting
- Second page drag EmployeeView1 as table, select single selection, filtering and sorting.
- Add navigation links between the two pages, convert department id outputText to link and set the action to the detail page(Employee page)
- Add back and commit buttons to the Employee page
- back should navigate back to search Departments page
- commit because we will change one record at first time
- run the Department Search page
- Search and select the first department with id=10
- Change the manager ID to 102 and save
- Back
- navigate to Department id=60 IT or any other department it shows the selected record from department id=10
- rerun the application many times as you want with changing the manager id to 102 this time because its one time change only, problem will still persists
- enable application module pool on again, problem disappears.

As a workaround to solve this problem, just change the ViewObject that have the ViewCriteria to expert mode Voilà.

Another cause of error (JBO-25014: Another user has changed the row with primary key oracle.jbo.Key[x])

Note this bug happens when using JDeveloper 11.1.1.7, I didn't test it on 11g release 2 versions or 12c, but I assume it might happens as well.

Apparently there is another cause of "JBO-25014 user changed primary key error" other than the ones discussed in Chris Muir post (The_case_of_the_phantom) or Jobinesh post (what-you-may-need-to-know-about-nested). This is related when Passivation/Activation occur while the user is changing a record on Master view object that uses an entity and this entity has a reference usage in the detailed view object.

You can test this by setting Application Module pool off. Assuming the user want to change the hire date of the employee in the master form for specific employee, at the same time the hire date is being referenced in the detail job description table showing readOnly hire date field next to the employee job description (Using Entity reference of-course).

When the user changes the field and the field has autosubmit set on, Passivation/Activation process will happen at the stage, then the user hit the save/commit button, ADF will do another Passivation/Activation process. It will activate the (VOs) including field values (New submitted along with Original) as first step of execution, thus while trying to activate the DoDML method will fail and throw a JBO-25014 error. This because the system will go and check the Entity state if it Synced with the database table to find any mismatch in field values.

It will compare the original field value against the database value, the original field value which is Passivated was overwritten from the detail Entity reference when the first Passivation/Activation happens, thus comparing two different value ( which contains the new data after the first Passivation/Activation process) with the original database value which is not changed or touched at all, and then throwing JBO-25014 exception.

This is a bug in ADF that only happens when Passivation/Activation happens in the system and there is a circular dependency between Entities used in the same page. The workaround is use a inline sub-query inside the detail ViewObject rather than using Entity reference specially when you know that you will build a screen that will have that field 1- editable, 2- referenced at the same time in the same screen, and 3- there is a possibility that Passivation/Activation will occur at some stage.

I will address anther bugs in Passivation/Activation mechanism in the following posts that I already submitted SRs for, at Oracle Support.