Oracle Apps Notes

A collection of my random notes, primarily on Oracle Apps

Category Archives: AOL

Prevent users from uploading specific files in Oracle EBS

Oracle EBS provides a way to restrict the type of files which can be uploaded though the front end. This will, for example, prevent users from uploading specific file types through the Generic File Manager or from uploading XML report files (which is how I came across this feature).
The two main parts to this feature is the Attachment File Upload Restriction Default profile option and the FILE_MIME_TYPES table.
The FILE_MIME_TYPES table lists the various file types and specifies whether they are allowed to be uploaded or not. The Attachment File Upload Restriction Default profile option controls those file types which have not been explicitly allowed or disallowed in the FILE_MIME_TYPES. Attachment File Upload Restriction Default can have a value of Yes or No. If it is set to Yes, a file type can be uploaded from the front-end even if it has not been explicitly allowed or disallowed in FILE_MIME_TYPES. Setting this value to No will prevent the user from uploading any file type which has not been explicitly allowed in FILE_MIME_TYPES.
When this feature prevents users from uploading a file, they will see this message on the screen: This file type is not allowed. Please choose another file
For more details please check Metalink Note#1357849.1: Security Configuration Mechanism in the Attachments Feature in Oracle E-Business Suite.

Changing Oracle HRMS installation from FULL to SHARED

When Oracle HRMS is installed in the FULL mode, users may encounter errors while accessing HRMS forms from non-HRMS responsibilities. For example, users cannot access the Employees form from Customer Support responsibility or the Positions form from Purchasing Super User responsibility. This happens because forms included in non-HRMS responsibility menus are to be used on a Shared HR environment and cannot be used on an HR full installed environment.

The best way to resolve this problem is to work on the forms from an HRMS responsibility. But if that option is not available, then the Oracle HRMS installation has to be manually changed from FULL mode to SHARED mode.

The steps involved in changing Oracle HRMS installation from FULL to SHARED are:

1. Check whether the hrglobal.drv file has been run in the instance. In case the hrglobal.drv file has already been run against the instance, then the only way out is to perform a new installation in SHARED mode and export all data from the old instance to the new one. (I sincerely hope that no one reading this post has to choose this option! )

2. If the hrglobal.drv file has NEVER been run against the system, then find the application_id of all HRMS related products installed in FULL mode in the instance.

3. Update the FND_PRODUCT_INSTALLATIONS table to change all HRMS related products from FULL to SHARED


update FND_PRODUCT_INSTALLATIONS
set STATUS = 'S'
where APPLICATION_ID IN (<appl_id1>,<appl_id2>);

Where appl_id1, appl_id2 are the application_id obtained from step#2.

Note:

1. Consult Oracle Support and raise an SR before trying to change the installation mode of Oracle HRMS.

2. The following SQL query checks whether hrglobal.drv has been run in an instance


select substr(application_short_name,1,4) app
, rpad(decode
(Legislation_code,null,'GLOBAL',Legislation_code),7,' ') LE_CODE
, rpad(status,14,' ') "Install Status"
, rpad(action,15,' ') "DataInst Action"
, last_update_date
from hr_legislation_installations
where application_short_name in ('PER','PAY')
order by LE_CODE,app;

If the Install Status column is ‘I’ for any row, it means that hrglobal.drv has been run in the instance.

3. The following SQL query shows the install status of HRMS related products


col a.application_name for a40
col a.application_short_name for a4
col b.status for a1
SELECT a.application_name,
a.application_id,
application_short_name,
DECODE(b.status,'I','I',
DECODE(b.status,'S','S',
DECODE(b.status,'N','N',b.status)))
FROM fnd_application_vl a, fnd_product_installations b
WHERE a.application_id = b.application_id
AND b.application_id IN (453,800,801,804,805,808,809,810,8301,8302,8303,8403)
ORDER BY a.application_id;

References:

Metalink Note#369459.1: How Does One Verify which HRMS Products have been Installed?

Metalink Note#414631.1: SQL: HRMS Products Installation Status

Metalink Note#116376.1: You Have Installed, Now Before You Setup, Read This! – HR Shared

There was another note on the entire process of going from full to shared install but that seems to be no longer publicly available.

 

Dynamically enabling and disabling Concurrent Program Parameters

Suppose a concurrent program has three parameters – ParamA, ParamB and ParamC. If the value for ParamA is ‘ENABLE_B’, then ParamB should be enabled and if the value fo ParamA is ‘ENABLE_C’, then ParamC should be enabled. Assume that the values for the second and third parameters are fetched from a table.

The first approach that might come immediatly to mind is to setup the three parameters ParamA, ParamB and ParamC in the manner and link them up using $FLEX$:
ParamA has value set VS1 attached to it. VS1 is of type Independent and has the values ‘ENABLE_B’ and ‘ENABLE_C’.
ParamB has value set VS2 attached to it. VS2 is of type Table and in the Where/Order By clause the condition :$FLEX$.ParamA=’ENABLE_B’ is added.
ParamC has value set VS3 attached to it. VS3 is of tye Table and in the Where/Order By clause the condition :$FLEX$.ParamA=’ENABLE_C’ is added.

When the program is run, both parameters are initially disabled.

But the moment we select a value for the first parameter, ParamA, both ParamB and ParamC get enabled thus defeating our purpose. The only consolation, if it may be so called, is that the list of value for ParamC contains no values.

The correct approach is to use two additional dummy parameters to enable or disable the second and third parameters. We will look into this appoach in more details.
1. ParamA has value set XXSB1_VS1 attached to it. The value set XXSB1_VS1 is of type Independent and contains two values ‘ENABLE_B’ and ‘ENABLE_C’

2. The dummy parameter ParamA1 has a seeded character value set attached to it. Note that the Displayed checkbox is unchecked. Its default value is derived from the SQL statement


select decode(:$FLEX$.ParamA,'ENABLE_B','Y', null) from dual

The value for this parameter will be ‘Y’ if ParamA has the value ‘ENABLE_B’ and null otherwise

3. ParamB has value set XXSB1_VS2 attached to it.

4. Value set XXSB1_VS2 is of type Table and in the Where/Order By clause the condition :$FLEX$.ParamA1=’Y’ is added

5. The dummy parameter ParamB1 has a seeded character value set attached to it. Note that the Displayed checkbox is unchecked. Its default value is derived from the SQL statement

select decode(:$FLEX$.ParamA,'ENABLE_C','Y', null) from dual

The value for this parameter will be ‘Y’ if ParamA has the value ‘ENABLE_C’ and null otherwise

6. ParamC has value set XXSB1_VS3 attached to it.

7. Value set XXSB1_VS3 is of type Table and in the Where/Order By clause the condition :$FLEX$.ParamB1=’Y’ is added.

That is it, all the parameters have now been set up. When the program is run, the second and third parameters are initially disabled like in the previous approach.

Depending on the value of the first parameter, the second and third parameters are enabled or disabled.

The second approach works while the first does not because the Where/Order By clause for one of the value sets always translates to null=’Y’ which cannot be equated and hence the parameter to which it is attached remains disabled.