Tuesday, September 23, 2014

Oracle Forms and Reports 11g Installation on Windows 7(32 bit) and Sample Form Test

1.Below installation tested on Windows7 Ultimate, 32 bit, 3GB RAM
Weblogic Server 11g(10.3.5)
Forms and Reports Server 11g(11.1.2)
Oracle Enterprise Pack for Eclipse(11.1.1.7)

2.Download files from below location.(Login to http://www.oracle.com/)
#wls1035_oepe111172_win32.exe
Link: http://download.oracle.com/otn/nt/middleware/11g/wls/1035/wls1035_oepe111172_win32.exe?AuthParam=1411119662_8b9496fcbef19a07ca48ae945021306c

#ofm_frmrpts_win_11.1.2.0.0_32_disk1_1of1.zip
Link: http://download.oracle.com/otn/nt/middleware/11g/111200/ofm_frmrpts_win_11.1.2.0.0_32_disk1_1of1.zip?AuthParam=1411124435_ea027c60bc5c8ba6727bad23f0c15175

#Patch: 6880880-OPatch Update
File:p6880880_111000_WINNT.zip (http://support.oracle.com)

#Patch: 17448420-Java Security Issue(Old Manifest file in jars)
File:p17448420_111200_Generic.zip (http://support.oracle.com)

3.Follow below link to install Weblogic Server
http://www.oracle-base.com/articles/11g/oracle-weblogic-server-11gr1-1035-installation-on-windows.php

4.Restart your machine and make sure that weblogic server is not in running status.
Simple check: http://localhost:7001/console should not open login page. (Replace localhost with your hostname)

5.Follow below steps to install Forms and Reports Classic 11g Home1.
Extract ofm_frmrpts_win_11.1.2.0.0_32_disk1_1of1.zip file into stage directory.
Open directory Disk1 and double click on setup.exe file.
 
 
 
 
 
 
6.Follow below steps to configure Forms and Report Development Enviroment.(if required)
Go to Start>Programs>OracleClassic11g-Home1>Configure Classic Instance.









7.Follow below steps to configure forms and report servers in existing weblogic server.
Go to Start>Programs>OracleClassic11g-Home1>Configure Classic Instance.
 
 
 
 
  
 
 
 

8.Your programs should look like this once all installations are done successfully.

9.Apply below patch to get latest version of OPatch. Enter correct version(in this case 11.1.1) when download the patch from metalink. After download, you need to copy OPatch folder from extracted directory and place it/override existing middleware OPatch folder. Take backup of existing OPatch folder.
Patch: 6880880 -OPatch Update
File:p6880880_111000_WINNT.zip

10.Apply below patch to override Java Security issues(Old Manifest file in jars). Download file from oracle metalink. Enter correct version(in this case 11.1.2) when download the patch from metalink.
Patch: 17448420 - Java Security Issue
File:p17448420_111200_Generic.zip

11.Check below links to confirm all servers are up and running status.
http://localhost:7001/console
http://localhost:9001/forms/frmservlet
http://localhost:9002/reports/rptservlet

if servers are not in running status then follow below order to start severs from Start>Programs>Oracle Classic Instance-asinst2
Start Weblogic Admin Server
Start Weblogic Server-WLS_FORMS
Start Weblogic Server-WLS-REPORTS

12.Create sample form using Forms Builder11g and compile. Copy .fmx file into any location on your drive(Should not have any spaces in the path).

13.Open Enterprise Manager Console(em)
http://localhost:7001/em

14.Click on "Forms" section from left side panel, click "Web Configuration" link to see configured applications details.

15.Create new Section by clicking on "Create" button and enter some name. This is the config name of your application. Enter Form field value as full path of your .fmx file. Including file name and extension. Leave remaining fields as it is.  Apply changes.

16.Now open your form and test it.
http://localhost:8888/forms/frmservlet?config=  [enter application config name]
 

Friday, May 30, 2014

What is new in R12

MOAC

Multi-Org in simple term means the implementation of multiple business units (or Organization) under a single installation of Oracle Applications. The concept of Multi-Org will manage the operations of an enterprise which has got subsidiaries across globe under a single oracle apps window, taking appropriate care of data security and data maintenance.
It decides how transactions flow through different organizations and how those organizations interact with each other.
  • By MOAC (Multiorg Access Control) , we can be able to access  multiple operating units at a time.
  • Mutiorg views were replaced with MOAC Based synonyms.
  • MO:Security Profile is a new profile added in R12.
  • VPD(Virtual Private Database) System will take care of  Data security in R12
  • Org Initialisation process in R12 :
begin
   mo_global.set_policy_context('S','204');
 end;
MOAC Synonym Initialization:
begin
   FND_GLOBAL.APPS_INTILISE('APPLICATION_ID','RESPONSIBILTY_ID,'USER_ID');
   MO_GLOBAL.INIT('SQLAP'); -- Application Short Name
end;

Module wise change 11i to R12

1) General Ledger :

  • gl_sets_of_books table was replaced with gl_ledgers and gl_ledger_Sets.
  • 4c’s comes in R12  Currency,Calendar,Chart of accounts, Accounting Convention , In 11i,  there are 3c’s ( Currency,Calendar,Chart of accounts)

2) Accounts Payable :

  • ap_invoice_lines_all table added in R12.
  • ap_invoice_distributions_all table populates the data when ever invoice gets accounted.
  • Supplier form was converted from form based solution to webbased solution.
  • po_vendors tables replaced with ap_suppliers tables.
  • Supplier and customer information was defined together Under TCA(Trading Community Architecture).
  • Accounting Tables were modified.
  • Both supplier and customer bank information was defined under payments(New application in R12) Application.
11i Tables R12 Tables
po_vendors ap_suppliers
po_vendor_sites_all ap_supplier_sites_all
po_vendor_contacts ap_supplier_contacts
ap_banks ce_banks
ap_bank_branches ce_bank_branches
ap_ae_headers_all xla_ae_headers
ap_ae_lines_all xla_ae_lines
ap_ae_accounting_events xla_events

3) Suppliers

11i Tables R12 Tables
po_vendors ap_suppliers
po_vendor_sites_all ap_supplier_sites_all
po_vendor_contacts ap_supplier_contacts
Additional supplier related tables in IBY (Payments) and HZ (TCA):
IBY_EXTERNAL_PAYEES_ALL – stores Payee(supplier) information.
HZ_PARTIES – Party data for the suppliers.
HZ_PARTY_SITES – Party site data for the supplier sites.

4) Invoices:

In 11i , Only two table ,AP_INVOICES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL but R12 Additional table  AP_INVOICE_LINES_ALL
Allocations – AP_CHRG_ALLOCATIONS_ALL is obsolete in R12

5) Bank Account Details

11i R12
AP_BANK_ACCOUNTS_ALL CE_BANK_ACCOUNTS
AP_BANK_ACCOUNT_USES_ALL CE_BANK_ACCT_USES_ALL
AP_CHECK_STOCKS_ALL CE_PAYMENT_DOCUMENTS

 6) Sub-ledger Accounting

SLA is rule based accounting hub in Release 12 (R12) of the Oracle E-Business Suite of applications. SLA is used to derive all attributes required to account a transaction in Oracle General Ledger.
SLA can be configured in many ways to help derive accounting attributes such as the entered amount, accounted amount, date, currency code as well as the more complex attributes like ledger, code combination ID (CCID). SLA accounting attributes are interfaced to GL from SLA, thus in R12 no sub ledger application module (i.e. AP, PO, PA etc) interfaces the transactions directly to GL.
Create Accounting :  Subledger tables and xla_events -> xla_ae_headers, xla_ae_lines and xla_distribution_links
Transfer to GL -: xla_ae_headers and xla_ae_lines -> gl_je_headers and gl_je_lines
Post to GL : gl_je_headers and gl_je_lines -> gl_balances
Subledger Accounting Balances Update  :  xla_ae_headers and xla_ae_lines -> xla_control_balances
11i R12
AP_ACOCUNTING_EVENTS_ALL XLA_EVENTS
AP_AE_HEADERS_ALL XLA_AE_HEADERS
AP_AE_LINES_ALL XLA_AE_LINES

7) Trial Balance:

New R12 Table
XLA_TRIAL_BALANCES
AP_LIABILITY_BALANCE-> not used in new R12 transactions
AP_TRIAL_BALANCE -> not used in new R12 transactions

8) Taxes:
Functionality provided by E-Business Tax
New tables in R12
ZX_LINES – Detailed Tax lines for the invoice (trx_id = invoice_id)
ZX_LINES_SUMMARY – Summary tax lines for the invoice (trx_id = invoice_id)
ZX_REC_NREC_DIST – Tax distributions for the invoice (trx_id = invoice_id)
ZX_LINES_DET_FACTORS – Tax determination factors for the invoice (trx_id = invoice_id)

9) Order Management

RA_CUSTOMERS ,RA_SITE_USES_ALL ,RA_ADDRESSES_ALL views were removed in R12. in place of ra_customers,ra_site_uses_all,ra_addresses_all views need to use the below mentioned base tables.

  • HZ_CUST_ACCOUNTS
  • HZ_PARTIES
  • HZ_CUST_SITE_USES_ALL
  • HZ_CUST_ACCT_SITES_ALL
  • HZ_PARTY_SITES
  • HZ_LOCATIONS

Requisitions Import/Interface

Application.
Purchasing PO.

Validations.
. Requisition Type should not be null.
. Item Type should not be null.
. Item category should not be null.
. Item description should not be null.
. UOM should not be null and should be a valid one.
. Quantity should not be null and should not be negative or 0.
. Item Should exist in the system.
. Supplier should not be null.
. Ship to locaton should not be null.

Interface Tables.
PO_REQUISITIONS_INTERFACE_ALL.
PO_REQ_DIST_INTERFACE_ALL.

Base Tables.
PO_REQUISITION_HEADERS_ALL
PO_REQUISITION_LINES_ALL
PO_REQ_DISTRIBUTIONS_ALL

Import Program Name.
Requisition Import.

Source: http://www.surereddy.com/po-requisitions-interface.php

Friday, May 23, 2014

RowMatch: In-memory filter

RowMatch is used to apply in-memory a qualifying expression to rows in memory. The user specifies a SQL expression.

A RowMatch may be used stand-alone or used a qualifying RowMatch for a ViewObject. To use it stand-alone, one would create a RowMatch. Then, to see if a Row qualifies, one would invoke rowQualifies(Row). Here is an example:

    RowMatch rowMatch = new RowMatch("Deptno = 30");
    if (rowMatch.rowQualifies(row))
    {
       System.out.println("We have a row whose Deptno is 30");
    }

To use a RowMatch for a ViewObject, invoke ViewObject.setRowMatch(RowMatch). Rows will be qualified in-memory.

RowMatch differs from the where-clause of a database query statement mainly in that one should use row's attribute names as opposed to the database column names. Note that database column names are by default case-insensitive, while attribute names are case-sensitive.

Where-clause qualfication only applies to rows already exsiting in the database table. RowMatch will apply to rows as they are read from database query as well. Additionally, RowMatch is applied to rows that are created because of view link consistency.

View link consistency allows a RowSet to see new rows (unposted) created by another RowSet. Internally, when a new row is created by the other RowSet and the row's primary key is set, the original RowSet (if view link cosnsistency is on) receives an event indicating a new row has been created. This RowSet creates a row and inserts it in its collection. Before this copy row is inserted, it is tested against the view object's RowMatch. Only if the row qualifies will it be inserted.

If a qualification can be expressed in a query's where-clause, one should use the where-clause, because database will skip unqualifying rows. If one relies solely on the RowMatch for in-memory qualification, he may incur unnecessary performance overhead, because rows will be read from database query and formed in memory.

Unlike a where-clause, a RowMatch can evaluate expression involving transient attributes and not-yet-posted attribute values.

ViewLinkConsistency/AssociationConsitency

When multiple instances of entity-based view objects in an application module are based on the same underlying entity object, a new row created in one of them can be automatically added (without having to re-query) to the row sets of the others to keep your user interface consistent or simply to consistently reflect new rows in different application pages for a pending transaction.

#The default setting for this parameter is the word "DEFAULT" which has the following meaning. If your view object has:
-A single entity usage, view link consistency is enabled
-Multiple entity usages, and:
--If all secondary entity usages are marked as contributing reference information, then view link consistency is enabled
--If any secondary entity usage marked as not being a reference view link consistency is disabled.
#To set the feature programmatically, use the setAssociationConsistent(true) API on any RowSet. When you call this method on a view object, it affects its default row set
#If you call setWhereClause() on a view object to set a dynamic WHERE clause, the view link consistency feature is disabled on that view object.
#If a row set has view link consistency enabled, then new rows added due to creation by other row sets are added to the bottom of the row set.
#If a row set has view link consistency enabled, then when you call the executeQuery() method, any  qualifying new, unposted rows are added to the top of the row set before the queried rows from the
database are added.
#If viewCriteria is applied on VO2 instance, then framework switch off the association consistency mode at the view object level. This does not allow to reflect changes done in VO1 in VO2. We can programmatically enable it in VO2's executeQueryForCollection method by calling setAssociationConsistent(true).

/*Override below method in VO2Impl.java file to
protected void executeQueryForCollection(Object qc, Object[] params, int noUserParams) {
  super.executeQueryForCollection(qc, params, noUserParams);
  setAssociationConsistent(true);
}

More Details: http://radio-weblogs.com/0123729/

How to find modified rows of EO/VO

Sample Code from AM:

    public void findModifiedRow(){
        Iterator itr = EmpEOImpl.getDefinitionObject().getAllEntityInstancesIterator(getDBTransaction());
        while (itr.hasNext()) {      
            EmpEOImpl eEOImpl = (EmpEOImpl) itr.next();
           
            if (eEOImpl.getEntityState() == Entity.STATUS_NEW){
                System.out.println("Emp "+eEOImpl.getEmpId()+"is a new Row");
            }
            if(eEOImpl.getEntityState() == Entity.STATUS_MODIFIED ){
            System.out.println("Emp "+eEOImpl.getEmpId()+"is a modified Row");
            }          
            if(eEOImpl.getEntityState() == Entity.STATUS_DELETED){
                System.out.println("Emp "+eEOImpl.getEmpId()+"is a deleted Row");
            }              
        }
    }

Query Execution Modes of View Criteria

There are 3 types Execution modes for a view criteria that can be helpful in filtering out the data.

Database: The search results are filtered from the Database table every time the query is hit.
In Memory: The results are filtered from the VO cache memory. It will use the rows which are already in the row set. It will stop the unnecessary hits to the DB.
Both: The results are filtered from the existing row set and also from the filtered results from Database. This is useful when you want to filter from uncommitted records also.


How to trace ADF BC Queries

Set Java option as -Djbo.debugoutput=console in Run/Debug/Profile for the model project. This is just to trace the queries being executed at runtime.

The easiest way to set this system property while running your application inside JDeveloper is to edit your project properties and in the Run/Debug panel, select a run configuration and click Edit to edit it. Then add the string  -Djbo.debugoutput=console to the Java Options field.

What is View Link Consistency

When multiple instances (say VO1, VO2, VO3 etc) of an EO-based VO are based on the same underlying EO, a new row created in one of these VO instances (say VO1)can be automatically added (without re-query) to the row sets of the others (VO2, VO3 etc ). This capability is known as the view link consistency. This feature works for any VO for which it is enabled, regardless of whether they are involved in a view link or not.

Most Commonly Used ADF Business Components Methods

http://docs.oracle.com/cd/E15051_01/web.1111/b31974/appendix_mostcommon.htm#CACHIEBH

Thursday, May 22, 2014

JBO-25014: RowInconsistentException

Cause: Comparison of the cached entity failed with the values in the database for that entity. This could happen when another user or operation has committed modifications to the same entity-row in the database. This exception can also be thrown if the equals() method on one of the domain-type attributes in the entity fails.
Action: Choose from the following options:
  • Verify that another user or operation has not modified the same row in the database. If this entity has attributes of a domain type verify that the equals() method on these domains do not fail when comparing the existing cached value with the newly fetched value.
  • For any attributes/columns that are updated by the database, modify the entity attribute definition by selecting Refresh after update on the Attribute Settings page of the Entity Object Wizard.
  • Use view.executeQuery() frequently, especially after any operations that result in data being changed.

Wednesday, May 21, 2014

AM -executeCommand()

public int executeCommand(java.lang.String command): Executes a SQL command using a JDBC Statement under the current transaction. Applications should use this method to execute application-specific JDBC statements. This method provides a way of bypassing the framework to query the database directly. Internally, the method passes the specified SQL command to a statement on the JDBC connection and executes it.

The following code example uses executeCommand. The SQL string is designed to update the EMP table. This example passes the string to executeCommand, then prints a message to report how many rows were actually updated.

 public static void demoUpdateColumn(ApplicationModule appMod) {
     String sqlStr = "UPDATE EMP " +
                     "SET MGR=7007 " +
                     "WHERE MGR=7698 ";
     int n = appMod.getTransaction().executeCommand(sqlStr);
     System.out.println("Updated " + n + " rows.");
   }

Be careful when using executeCommand, because it will execute any valid SQL statement. For example, you could perform an operation like the following DDL command:

 appMod.getTransaction().executeCommand("DROP TABLE MYTEMPTABLE");

A pending database transaction could be committed inadvertently due to the implicit commit performed by DDL operations, as well as having any row locks released.

Monday, May 19, 2014

Page Flow Scope and Multiple Regions

Every ADF region maintains its own Page Flow scope, this means even if you have two ADF regions on the same page - each ADF region will have its own Page Flow scope and it will not be allowed to enter another region Page Flow scope. If we would be allowed to share Page Flow scope between different regions, it would be easy to pass data from one ADF region to another, however this is not allowed by design.

Solutions:
1. ADF Task Flow parameters - preferable option, is simple to use, however sometimes is not enough for complex scenarios

2. Contextual Events - flexible and powerful approach, but can be too complicated. When application grows, is hard to maintain and understand dependency between different Contextual Events. In certain situations, its mandatory to use Contextual Events, for example dependent region refresh

3. Page Definition Access through Data Control - we can access separate ADF region page definition through Data Control directly. While this works, is not advisable because it creates direct dependencies between regions

4. Session Scope-session scope values are accessible by both regions.  

Source:http://andrejusb.blogspot.in/2011/02/adf-region-communication-data-exchange.htm

Life Cycle Phase details on First page load and on Submit action

ADF Life Cycle:
The ADF and JSF phases work together

On First Page Call

1. Restore view.
As the session is fresh, there's no means of any UIViewRoot to restore, so nothing to see here.
2. Apply request values.
This phase is skipped because there is no form submit.
3. Process validations.
This phase is skipped because there is no form submit.
4. Update model values.
This phase is skipped because there is no form submit.
5. Invoke application.
This phase is skipped because there is no form submit.
6. Render response.
The bean is constructed. Behind the scenes a new UIViewRoot is created and stored in the session. If the component binding getters returns precreated components (precreated in e.g. the constructor) and not null, then those will be used, otherwise JSF will create new components. The components will be stored in the UIViewRoot and the bounded components are set in the component bindings. The values to be shown are retrieved from the value binding getters in the backing bean. If the values aren't set yet, they defaults to null. The component bindings are not required by the way. Only use them if you actually need the component in the backing bean for other means than getting/setting the value. In this article they are included just to demonstrate what all happens in the lifecycle.


On Page Submit Action:

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.
2. Apply request values.
Nothing to see here. Behind the scenes the submitted form values are obtained as request parameters and set in the relevant components in the UIViewRoot, for example inputComponent.setSubmittedValue("test").
3. Process validations.
The submitted values are passed through the converter getAsObject() method and validated by the validator. If the conversion and validation succeeds, then the initial input value will be retrieved from the value binding getter and behind the scenes the inputComponent.setValue(submittedValue) and inputComponent.setSubmittedValue(null) will be executed. If the retrieved initial input value differs from the submitted value, then the valueChangeListener method will be invoked.
4. Update model values.
The converted and validated values will now be set in the value binding setters of the backing bean. E.g. myBean.setInputValue(inputComponent.getValue()).
5. Invoke application.
The real processing of the form submission happens here.
6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean. If a converter is definied, then the value will be passed through the converter getAsString() method and the result will be shown in the form.

Source: http://balusc.blogspot.in/2006/09/debug-jsf-lifecycle.html

Life Cycle phases involved with Validations and ValueChangeEvents

ADF Life Cycle Phases:

The ADF and JSF phases work together

  • Apply Request Values: Each component in the tree extracts new values from the request parameters (using its decode method) and stores the values locally. Most associated events are queued for later processing. If a component has its immediate attribute set to true, then the validation, the conversion, and the events associated with the component are processed during this phase.


  • Process Validations: Local values of components are converted from the input type to the underlying data type. If the converter fails, this phase continues to completion (all remaining converters, validators, and required checks are run), but at completion, the lifecycle jumps to the Render Response phase.
    If there are no failures, the required attribute on the component is checked. If the value is true, and the associated field contains a value, then any associated validators are run. If the value is true and there is no field value, this phase completes (all remaining validators are executed), but the lifecycle jumps to the Render Response phase. If the value is false, the phase completes, unless no value is entered, in which case no validation is run.

  • What we understand here is that, for input components, by default, the validations are going to be fired in the Process Validations phase. Furthermore, they have a specific order:
    1)  converters
    2)  required checks (check if it is required)
    3)  validators

    NOTE: Of course there are some other cases were the required checks are not fired.. but the above is the general idea.

    As you may have noticed, in the Apply Request Values phase, it is mentioned that if the component has it's immediate property to true, then the validations will take place in tha phase.

    Which means, that they are not skipped.

    What we understand here is that validations will fire no matter if the component is immediate =true or not.

    But when does the ValueChangeEvent is triggered? Again, according to the documentation:
    ValueChangeEvent is an intermediate phase between Process Validations and and updae model Values. This means that ValueChangeListener are invoked right after validations. It does not matter if the component is immediate true or not. The difference lays in the phase those operations will be executed.

    The case of the commandButton:
    CommandButtons will trigger the validations and valueChangelisteners of inputComponent while pressed. It is the same case weither the the button is partialSubmit and the inputComponent partialTriggered by the button, or the button is not partialSubmit.

    If we set the commandButton to immediate true, then some phases are skipped:



    According to documentation:  When actionSource components (such as a commandButton) are set to immediate, events are delivered in the Apply Request Values phase instead of in the Invoke Application phase. The actionListener handler then calls the Render Response phase, and the validation and model update phases are skipped.

    This means that if the button is set to immediate only the ApplyRequestValues phase will be invoked, the Process Validations phase will be skipped.

    So, if we will have a selectOneChoice component with autoSubmit=false and immediate=false and a commandButton with immediate=true. 

    According to what we know so far, the commandButton will invoke the ApplyRequestValues phase and then render response phase. Our selectOneChoise, will invoke the validation and ValueChangeListener in the Process Validations phase.. which in our case, will not be invoked.

    So we are bypassing everything...

    If we want to invoke validators and valueChangeListeners while having the button immediate=true, we will have to have the selectOneChoice to immediate=true as well!

     why? simply because, according to documentation, while having the input component immediate=true, all validators and valuChangeListeners will be shifted to ApplyRequestValues. Which is exactly what we want.

    Conclusion: Validators are executed before ValueChangeListeners. They are executed even if the input component is immediate=true. The only change is the which phase they will be executed in.
    The combination of commandButton can bypass he validations and valuechangelisteners if it set to immediate=true. We can still have validations and valueChangeListeners triggered if we have the inputComponent to immediate=true. Since the validations and ValueChangelisteners will be triggered in a different phase and more specifically, they will be triggered in the ApplyRequestValues phase.

    Source: http://dstas.blogspot.in/2011/12/validator-or-valuechangelistener-adf.html

    Saturday, May 17, 2014

    VO Current Row Refresh

    refresh(int refreshMode): Refreshes the row's attributes with values from database. refreshMode should be a combination of REFRESH_.... See REFRESH_... constants for further information.

    Sample:
    EmpVOImpl eVO = getEmpVO();
    EmpVORowImpl eRow = (EmpVORowImpl)eVO.getCurrentRow();
    eRow.refresh(Row.REFRESH_UNDO_CHANGES|Row.REFRESH_WITH_DB_FORGET_CHANGES);

    REFRESH_WITH_DB_FORGET_CHANGES forgets edits that the current user made to the row. The row data is refreshed from database. The latest data from database replaces data in the row regardless of
    whether the row was modified or not.

    If the current user had called ApplicationModule#postChanges() REFRESH_WITH_DB_FORGET_CHANGES will pick up the data that he himself wrote through his call to postChanges().

    If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_WITH_DB_FORGET_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.

    REFRESH_WITH_DB_ONLY_IF_UNCHANGED works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database. If a row was already modified by this transaction, the row is not refreshed.

    If locking mode is pessimistic, the fact that you (this user) were able to change the data means that you were able to lock the row and that you got the latest data.

    When using this refresh mode, if the locking mode is optimistic, the framework could bring the latest data for unmodified attributes and merge them into the row, while retaining changed attributes as is. However, this could lead to data integrity problems. Thus, for consistency sake and data integrity, we leave the row alone if it was modified even for optimistic locking mode.

    If REFRESH_REMOVE_NEW_ROWS is not specified, calling refresh with this mode will be a no-op (treated just like a modified row). If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.

    REFRESH_UNDO_CHANGES works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database.

    For a modified row, this mode refreshes the row with attribute values at the beginning of this transaction. This mode will back out changes that have been posted to database through postChanges(), but not yet committed. Suppose a row's attribute value was modified from 'A' to 'B' and 'B' is posted. Suppose further the user changes 'B' to 'C' (after the post). Calling refresh(int) with this mode will restore the attribute value to 'A'.

    Out on database, the attribute value is still 'B'. However, the row is marked as modified, so that when the changes are posted later 'A' will replace 'B' out on database.

    If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_UNDO_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new is removed.

    Friday, May 16, 2014

    Custom Error Message

    Sometimes user wants to display custom error message instead of default message. For such cases ADF framework provides a way to create custom error handler class which extends default DCErrorHandlerImpl class. You are not required to write any code to register your custom exception handler class. Instead, you’ve to select the root node of the DataBindings.cpx files in the Structure window, and then use the Property Inspector to set the ErrorHandlerClass property to the fully qualified name of the error handler you want to use.

    Example:
    Default Message: JBO-25013 Too many object match primary key
    CustomMessage: Duplicate Employee Id Found

    Source: http://www.adftutorials.com/adf-custom-error-handler-to-display-custom-message-to-user.html

    Monday, April 21, 2014

    ADF Business Components

    When building service-oriented Java EE applications, you implement your core business logic as one or more business services. These backend services provide clients with a way to query, insert, update, and delete business data as required while enforcing appropriate business rules. ADF Business Components are prebuilt application objects that accelerate the job of delivering and maintaining high-performance, richly functional, database-centric services. They provide you with a ready-to-use implementation of Java EE design patterns and best practices.

    Oracle ADF provides the following key components to simplify building database-centric business services:

    Entity object
    An entity object represents a row in a database table and simplifies modifying its data by handling all data manipulation language (DML) operations for you. It can encapsulate business logic to ensure that your business rules are consistently enforced. You associate an entity object with others to reflect relationships in the underlying database schema to create a layer of business domain objects to reuse in multiple applications.

    View object
    A view object represents a SQL query and simplifies working with its results. You use the SQL language to join, filter, sort, and aggregate data into the shape required by the end-user task being represented in the user interface. This includes the ability to link a view object with other view objects to create master-detail hierarchies of any complexity. When end users modify data in the user interface, your view objects collaborate with entity objects to consistently validate and save the changes.

    Application module
    An application module is the transactional component that UI clients use to work with application data. It defines an updateable data model along with top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task.

    Oracle ADF Architecture

    Fusion web technology stack achieve a clean separation of business logic, page navigation, and user interface by adhering to a model-view-controller architecture. As shown in figure in an MVC architecture.

    ■ The model layer represents the data values related to the current page
    ■ The view layer contains the UI pages used to view or modify that data
    ■ The controller layer processes user input and determines page navigation
    ■ The business service layer handles data access and encapsulates business logic



    ADF VO Methods

    clearCache

    Clears the View Object cache. This method can be called for resource conservation. Calling this method also forces an automatic reexecution of the query for all RowSets, which refreshes the cache from the database.

    reset

    Resets the iterator. This method delegates to the default RowSetIterator. The iterator is positioned to the slot before the first row, the state of a newly-executed row set.

    createRow

    Creates a new view row. The new row is not placed in the entity cache until its primary key is initialized. It is inserted into the database when changes are posted to database and the transaction is committed.
    Note that the constituent entities will be added to the entity-cache if the primary key of these entites are populated/set when the relevant entity's create() method is called. PrimaryKey attributes of Bc4J generated ID types (like RowID, DBSequence, etc) are defaulted before Entity.create and thus entities with such types as Primary Key attribute will be placed in the entity cache during create.

    notifyRowInserted

    This method is invoked by the framework when inserts are made to the given ViewRowSet for this ViewObject. This method can be overridden to perform calculations in a subclass or to cache a list of new rows for some other reason.

    notifyRowDeleted

    This method is invoked by the framework when a row is deleted from the given ViewRowSet for this ViewObject. This method can be overridden to perform calculations in a subclass or to cache a list of deleted rows for some other reason.

    notifyRowUpdated

    This method is invoked by the framework when updates are made to any attribute for rows in the given ViewRowSet for this ViewObject. This method can be overridden to perform calculations in a subclass if a particular attribute changes. Also, if the sub-class wants to block event-propogation to some/all rowsets of this viewobject, this method could be used to perform such filtering.

    AccessMode

    • SCROLLABLE - if this RowSet should fetch rows and cache the ViewRows in a collection. This is the most flexible mode for accessing rows and working with a RowSet.
    • FORWARD_ONLY - if this RowSet should only provide sequential access to Rows in its collection. The iterators on this RowSet will not allow scrolling back.
    • RANGE_PAGING - if this RowSet should fetch rows in ranges (set using setRangeSize() - the default range size is -1 to fetch all rows), such that on scroll to the the next range or to fetch a row that's not in the current range, it's fetched back from the database using ROWNUM query and the row at the desired index is placed as the first row in the current range. New rows inserted in this mode will be inserted at the beginning of the rowset to maintain their row indices.
      If an attempt is made to get a row outside of the range when a new row is inserted or a row is removed in the current range, then an InvalidOperException is raised as the current set of changes needs to be posted to recalculate the right ROWNUM.
    • RANGE_PAGING_AUTO_POST - if this rowset should also post any changes in this transaction to access a row out of the current range.

    writeXML

    Renders data in a canonical XML-format. The classes ViewObjectImpl and ViewRowImpl implement this method to render data in XML.
    Use this method whenever data is required in XML format, either to present a UI (after converting XML data into some HTTP format using a stylesheet) or to pass the data as payload for messages via JMS.

    Source: http://docs.oracle.com/cd/B14099_19/web.1012/b14022/oracle/jbo/server/ViewObjectImpl.html#createRow__

    ADF: VO getRowCount

    Counts the total number of rows in this row set.
    This method retrieves all rows from the View Object by executing the View Object's query and then calling next() until the last row is retrieved. Thus, since it iterates through the View Object one record at a time, this method may be slow.
    If you are working with a large number of rows, or if your application demands a fast response, use getEstimatedRowCount to obtain a quicker count.

    ADF: VO getFetchedRowCount

    Counts the number of rows fetched from the JDBC result set.

    This method delegates to the default RowSetIterator.

    This method can be used to determine whether the View Object has read all the rows from the cursor. For example, getEstimatedRowCount returns an equivalent of count(*) on the View Object. The getFetchedRowCount() method returns the count of rows already fetched. If getFetchedRowCount() returns a value less than getEstimatedRowCount(), then the View Object has not read all rows from the cursor.

    ADF: VO Method getEstimatedRowCount

    This method estimates the number of rows in the row count by calling getQueryHitCount (which performs a SELECT COUNT (*) FROM table). Internal logic in Business Components for Java keeps the EstimatedRowCount up-to-date as rows are inserted and removed. Thus, after the first call to this method, it can return the estimated count quickly.
    For example:
     // Get the rowcount again because of deleted or inserted row   
    rowCount = (int) iter.getRowSet().getEstimatedRowCount();     
    If you are working with a large number of rows, or if your application demands a fast response, use this method instead of getRowCount.
    Note however, that this method might not be as accurate as getRowCount(). To test whether the View Object has read all the rows from the cursor, you can use getEstimatedRowCount() in conjunction with getFetchedRowCount(). For example, getEstimatedRowCount() returns an equivalent of count(*) on the View Object. The getFetchedRowCount method returns the count of rows already fetched. If getFetchedRowCount() returns a value less than getEstimatedRowCount(), then the View Object has not read all rows from the cursor.
    Source: http://docs.oracle.com/cd/B14099_19/web.1012/b14022/oracle/jbo/server/ViewObjectImpl.html#getEstimatedRowCount__

    Tuesday, February 4, 2014

    Inputtext content(Number type) right align

    Set  contentStyle="text-align:right"
    Related Posts Plugin for WordPress, Blogger...