18 June 2014

Oracle Apps : Truncate VS Delete


Truncate will effectively just move the high water mark of a table back to "zero" and either release allocated space back to dba_free_space or keep it for the segment. It just moves a pointer and says "magically there is no data in this table". It doesn't actually touch the data, it just says "we don't have it anymore"


Delete physically deletes, row by row. It deletes from the table, it deletes the index entry. The space is not given back and the high water marks stay exactly where they are. if there were a million rows in the table, the high water mark will be at the million row mark (or above).

12 June 2014

Deleting Layout RTF Template from Data Template

Use below script TO DELETE the existing Template in BI Publisher.

  SET SERVEROUTPUT ON DECLARE
  -- Change the following two parameters
  var_templateCode VARCHAR2 (100) := 'Template Code'; -- Template Code
boo_deleteDataDef  BOOLEAN        := TRUE;            -- delete the associated Data Def.
BEGIN
  FOR RS IN
  (SELECT T1.APPLICATION_SHORT_NAME TEMPLATE_APP_NAME,
    T1.DATA_SOURCE_CODE,
    T2.APPLICATION_SHORT_NAME DEF_APP_NAME
  FROM XDO_TEMPLATES_B T1,
    XDO_DS_DEFINITIONS_B T2
  WHERE T1.TEMPLATE_CODE  = var_templateCode
  AND T1.DATA_SOURCE_CODE = T2.DATA_SOURCE_CODE
  )
  LOOP
    XDO_TEMPLATES_PKG.DELETE_ROW (RS.TEMPLATE_APP_NAME, var_templateCode);
    DELETE
    FROM XDO_LOBS
    WHERE LOB_CODE             = var_templateCode
    AND APPLICATION_SHORT_NAME = RS.TEMPLATE_APP_NAME
    AND LOB_TYPE              IN ('TEMPLATE_SOURCE', 'TEMPLATE');
    DELETE
    FROM XDO_CONFIG_VALUES
    WHERE APPLICATION_SHORT_NAME = RS.TEMPLATE_APP_NAME
    AND TEMPLATE_CODE            = var_templateCode
    AND DATA_SOURCE_CODE         = RS.DATA_SOURCE_CODE
    AND CONFIG_LEVEL             = 50;
    DBMS_OUTPUT.PUT_LINE ('Selected template has been ' || var_templateCode || ' deleted.');
  END LOOP;
  COMMIT;
EXCEPTION
WHEN OTHERS THEN
  ROLLBACK;
  DBMS_OUTPUT.PUT_LINE ( 'Unable to delete XML Publisher Template ' || var_templateCode);
  DBMS_OUTPUT.PUT_LINE (SUBSTR (SQLERRM, 1, 200));
END;
/

12 March 2014

Oracle Applications Multiple Organizations Access Control for Custom Code (Doc ID 420787.1)

Overview of Multiple Organizations Architecture (prior to Release 12)

The primary objective of multiple organizations architecture, introduced in Oracle Applications Release 10.6, is to secure data from unauthorized access by individuals belonging to different operating units in an enterprise.

A new or fresh installation of an Oracle Applications instance does not automatically enable multiple organizations. The system administrator creates operating units using the Define Organizations window in Oracle Human Resources Management System (HRMS), and runs the Convert to Multiple Organization program from AD Administrator to enable the multiple organizations feature. Typically, the system administrator defines "MO: Operating Unit" profile at Responsibility and/or User level. The "organization_id" of the "MO: Operating Unit" profile option value filters the transactional data. The CLIENT_INFO application context space stores the multiple organizations context value.

Multi-Org views use the following WHERE clause to filter application records:'org_id = substrb(userenv(''CLIENT_INFO''),1,10)'
Overview of Multiple Organizations Access Control Architecture (Release 12)

The Access Control feature in Release 12 allows the user to enter or query records in one or more operating units without changing application responsibility. It is the system administrator’s discretion to either implement the feature or use the same multiple organizations profile option setting available before Release 12 by using the single operating unit mode (i.e. one operating unit for a responsibility).

In Release 12, the multiple organizations context value is no longer initialized by the FND_GLOBAL.APPS_INITIALIZE routine thereby reducing unnecessary context setting and resource consumption for applications that do not use operating unit context for data security.

To use the single operating unit mode, you must set the value for the "Initialization SQL Statement – Custom profile" to "mo_global.init('S',null);". This initializes the operating unit context based on the "MO: Operating Unit" profile option and the "MO: Security Profile" profile option must not be set.

Fresh install of Release 12 Application is enabled with multiple organizations, however, the system administrator must create operating units to use multi organizations sensitive application products. The user can create new operating units in the Accounting Setup Manager page in addition to HRMS’s Define Organizations page.

Multiple Organizations Initialization

The profile options MO: Security Profile or MO: Operating Unit populate the multiple organizations global temporary table. The profile option MO: Security Profile takes precedence over MO: Operating Unit. You can combine the following under one application menu:
Products at different levels
Products that are access control enabled
Products that are not access control enabled (i.e. in transition)

In such cases, initializing the multiple organizations depends on the application of the calling module and not the application tied to the responsibility, since the profile Option MO: Security Profile must be ignored for products that are not access control enabled or are in the transition phase.

A new table (FND_MO_PRODUCT_INIT) is introduced which contains a value Y for products that are enabled with the multiple organizations access control feature. The multiple organizations initialization API uses the module owner to initialize the temporary table depending on the value for the product in the FND_MO_PRODUCT_INIT table.

Application_Short_NameStatus
ARY
JTFY
Y or N

Legend: Y indicates multiple organizations access control is enabled, N indicates otherwise.

Use the shared services API to register products that are enabled with access control. For example to enable or remove access control for Payables (SQLAP), enter the following code:To enable access: FND_MO_PRODUCT_INIT_PKG.register_application('SQLAP', 'SEED','Y'); To delete your application entry: FND_MO_PRODUCT_INIT_PKG.remove_application('SQLAP');

The Payables system administrator must then seed a row in the Multiple Organizations table to indicate that Payables is enabled with access control.

Products must call the MO_GLOBAL.init() API to execute the multiple organizations initialization.

Multiple organizations initialization performs the following:
Initializes the security policy predicate
Populates a global temporary table that is used in the user interfaces and the security policy function.

Attention:
Do not access the global temporary table directly. Instead, use the PL/SQL functions to access data from the temporary table.
The FND_GLOBAL.APPS_INITIALIZE routine does NOT automatically call mo_global.init routine. You must explicitly invoke the mo_global.init routine to initialize the organization context.

06 March 2014

Windows: Set the JAVA_HOME Variable

Set the JAVA_HOME Variable in Windows

Once you have the JDK installation path:
Right-click the My Computer icon on your desktop and select Properties.
Click the Advanced tab.
Click the Environment Variables button.
Under System Variables, click New.
Enter the variable name as JAVA_HOME.
Enter the variable value as the installation path for the Java Development Kit.
Click OK.
Click Apply Changes.

You might need to restart windows.

28 February 2014

Oracle E-Business Suite Timeout Parameters / Profiles

The following E-Business Suite profile options control screen timeouts for Forms, as well as Self Service sessions. Again, please note, some of the ICX profiles also control Forms Session timeouts! This can be confusing since Inter-Cartridge Exchange (ICX) is often associated with Self Service applications. This is no longer the case since the release of Framework for the ICX Profiles control the timeout functionality. 
Parameter
Default
Recommendation
ICX:Session Timeout
None
30 (minutes)
ICX: Limit Time
4 (hours)
4 (hours)
ICX: Limit Connect
1000
2000
ICX:Session Timeout - This profile option determines the length of time (in minutes) of inactivity in a user's form session before the session is disabled. Note that disabled does not mean terminated or killed. The user is provided the opportunity to re-authenticate and re-enable their timed-out session. If the re-authentication is successful, the disabled session is re-enabled and no work is lost. Otherwise, the session is terminated without saving pending work. This functionality is available via Patch 2012308 (included in 11.5.7, FND.E). Note: Setting the profile value to greater than 30 minutes can drain the JVM resources and cause ‘out of memory’ errors.

· ICX: Limit time - This profile option defines the maximum connection time for a connection – regardless of user activity. If 'ICX:Session Timeout' is set to NULL, then the session will last only as long as 'ICX: Limit Time', regardless of user activity.

· ICX: Limit connect - This profile option defines the maximum number of connection requests a user can make in a single session. Note that other EBS internal checks will generate connection requests during a user session, so it is not just user activity that can increment the count.

CRM Application Timeout Profile Values

CRM applications use the afore-mentioned ICX timeout profiles (ICX:Session Timeout, ICX: Limit Time, and ICX: Limit Connect), but additionally, CRM also utilizes the JTF_INACTIVE_SESSION_TIMEOUT profile option. 
Parameter
Default
Recommendation
JTF_INACTIVE_SESSION_TIMEOUT
None
30 (minutes)
JTF_INACTIVE_SESSION_TIMEOUT - This profile option affects CRM-based products only, and serves the same purpose as the ICX:Session Timeout profile. This profile option exists for legacy reasons, and its value should be set the same as ICX:Session Timeout.

Jserv (Java) Timeout Settings
Parameter
Recommendation
disco4iviewer.properties:session.timeout
5400000 (milliseconds)
formservlet.ini:FORMS60_TIMEOUT
55 (minutes)
formservlet.properties:session.timeout
5400000 (milliseconds)
jserv.conf:ApJServVMTimeout
360  (seconds)
mobile.properties:session.timeout
5400000 (milliseconds)
zone.properties:session.timeout
5400000 (milliseconds)
zone.properties:servlet.framework.initArgs
5400000 (milliseconds)
These settings are located at: ../*ora/iAS/Apache/Jserv/etc

JServ Timeout is specified by the value of the property session.timeout in the JServ configuration file zone.properties, and represents the number of milliseconds to wait before ending an idle JServ session (the default is 30 minutes). This timeout is used by products based on Oracle Applications Framework (OAF). 
 
Apache HTTP Timeout Settings

The following parameter settings control timeout behavior within Apache.

Parameter
Recommendation
httpd.conf:Timeout
300 (seconds)
httpd.conf:KeepAliveTimeout
15 (seconds)
httpd.conf:SSLSessionCacheTimeout
300 (seconds)
These settings are located: ../*ora/iAS/Apache/Apache/conf
Forms 60 Environment Timeout Variables

The following parameter settings control timeout behavior within Oracle Forms.

Parameter
Recommendation
FORMS60_TIMEOUT
55 (minutes)
FORMS60_CATCHTERM
0
You should modify the APPL_TOP/.env setting to include the following settings:

FORMS60_CATCHTERM=0
FORMS60_TIMEOUT=55 (minutes)

I recommend using a timeout value of 55 because it is less than the 60 minute value recommended for the web apache timeout values. Note that these values may vary depending on security policies.
Oracle Single Sign-On Server Timeouts

The following parameter setting controls timeout behavior within Oracle Single Sign-On.

‘Single Sign-On Session Duration’ represents the number of hours a user can be logged in to the server without being timed out and having to log in again. This timeout value can be specified from the "Edit SSO Server Configuration" link on the SSO Server Administration page. When a user logs in to Release 11i via the Single Sign-On Server, an SSO login session is created and remains valid for the duration specified by this setting.

27 February 2014

Concurrent Processing - Operating Unit LOV has no values When Submitting Concurrent Requests For MOAC Responsibility (Doc ID 837615.1)

To support this, concurrent programs are defined with an operating unit mode of 'S' for single
operating unit or 'M' for multiple operating units. This mode is set automatically during
the upgrade to release 12.

However, if you have modified the definition for any concurrent programs, the upgrade will not set
this. This is done to preserve your customizations. Depending on how you run the customized
program, you may need to set this operating unit mode.
To do this, execute the following SQL to set a concurrent program to run for a single operating
unit:

UPDATE FND_CONCURRENT_PROGRAMS
SET MULTI_ORG_CATEGORY='S'
WHERE CONCURRENT_PROGRAM_NAME = ''


Enter 'M' instead of 'S' for multiple operating units.

If you want to know which setting is appropriate for a given program, you may
review the setting in the appropriate .ldt file.
Please note, however, that if you have customized the concurrent program definition,
this setting may not be appropriate given the way you use the program.



This can also be done via Applications User Interface:


1. Login into application with System Administration responsibility (NOT System
Administrator)
2. Navigate: Concurrent -> Programs
3. Query for short name of the concurrent program
4. Click on Update pencil icon of your program
5. Under 'Update Concurrent Program' region, select Request tab
6. Under 'Request Setting' region, select 'Single' from the drop down of 'Operating Unit
Mode' field
7. Save changes by clicking on 'Apply' button.

21 February 2014

Oracle E-Business Suite R12 & 11i Form form in Google chrome .

Install following chrome extension to launch Oracle Apps in Google Chrome browser. 


More details or source code visit developer's website : https://github.com/zorrofox/ebs-chrome-enablement