Danilo Vizzarro » Oracle EBS

SCRIPT: Backup an Oracle Table with PHP

Danilo Vizzarro — Fri, 11 Dec 2009 04:00:05 +0000

The following code will query some data from the Oracle Database and will export them on a CSV file.
The webserver where this script is executed should have the OCI8 library installed.
The execution of this script can be also scheduled to have a periodic backup of a certain table.

The script below will extract from the system the forms used by each Oracle EBS user.

$ORACLE_USERNAME = 'RAC_ACCNT'; $ORACLE_PASSWORD = 'PASSWORD'; $ORACLE_SID = 'SID';


$ORACLE_CONNECT = OCILogon($ORACLE_USERNAME, $ORACLE_PASSWORD, $ORACLE_SID);
$time = date("H_i");

$day = date("d");

$month = strtoupper(date("m"));

$year = date("Y");

$today = $year . "-" . $month . "-" . $day;
// FND_LOGINS

$query_table_to_backup = "

SELECT DISTINCT

D.USER_NAME,

E.RESPONSIBILITY_NAME,

TO_CHAR(A.START_TIME,'DD-MON-YYYY HH24:MI:SS'),

TO_CHAR(A.END_TIME,'DD-MON-YYYY HH24:MI:SS'),

G.USER_FORM_NAME,

TO_CHAR(F.START_TIME,'DD-MON-YYYY HH24:MI:SS') FORM_START_TIME,

TO_CHAR(F.END_TIME,'DD-MON-YYYY HH24:MI:SS') FORM_END_TIME,

F.START_TIME FORM_START_TIME_ORDER

FROM

FND_LOGIN_RESPONSIBILITIES A,

FND_RESPONSIBILITY B,

FND_LOGINS C,

FND_USER D,

FND_RESPONSIBILITY_TL E,

FND_LOGIN_RESP_FORMS F,

FND_FORM_TL G

WHERE

A.RESPONSIBILITY_ID = B.RESPONSIBILITY_ID

AND A.RESPONSIBILITY_ID = E.RESPONSIBILITY_ID

AND B.RESPONSIBILITY_ID = E.RESPONSIBILITY_ID

AND A.LOGIN_RESP_ID = F.LOGIN_RESP_ID

AND C.LOGIN_ID = A.LOGIN_ID

AND A.LOGIN_ID = F.LOGIN_ID

AND C.LOGIN_ID = F.LOGIN_ID

AND C.USER_ID = D.USER_ID

AND G.FORM_ID = F.FORM_ID

AND E.LANGUAGE = 'US'

AND G.LANGUAGE = 'US'

AND B.APPLICATION_ID = G.APPLICATION_ID

AND A.START_TIME > SYSDATE - 30

ORDER BY FORM_START_TIME_ORDER DESC

";
$output_file = "output/" . $ORACLE_SID . "_FND_LOGINS_BACKUP_" . $today . "_" . $time . ".csv";

$output_name = $ORACLE_SID . "_FND_LOGINS_BACKUP_" . $today . "_" . $time . ".csv";

$fh = fopen($output_file, 'w') or die("can't open file");
$ORACLE_STATIC = OCIParse($ORACLE_CONNECT, $query_table_to_backup);

OCIExecute($ORACLE_STATIC, OCI_DEFAULT);
while ($PRINT_RECORD = oci_fetch_array ($ORACLE_STATIC, OCI_BOTH))

{

	$stringData = $PRINT_RECORD[0] . ";" . $PRINT_RECORD[1] . ";" . $PRINT_RECORD[2] . ";" . $PRINT_RECORD[3] . ";" . $PRINT_RECORD[4] . ";" . $PRINT_RECORD[5] . ";" . $PRINT_RECORD[6] . ";" . $PRINT_RECORD[7] . ";" . $PRINT_RECORD[8] . ";" . $PRINT_RECORD[9] . ";" . $PRINT_RECORD[10] . ";" . $PRINT_RECORD[11] . ";" . $PRINT_RECORD[12] . ";" . $PRINT_RECORD[13] . ";" . $PRINT_RECORD[14] . ";" . $PRINT_RECORD[15] . ";" . $PRINT_RECORD[16] . ";" . $PRINT_RECORD[17] . ";" . $PRINT_RECORD[18] . ";" . $PRINT_RECORD[19] . "\n";

fwrite($fh, $stringData);

}

fclose($fh);

SCRIPT: Send an Email with PL/SQL

Danilo Vizzarro — Fri, 04 Dec 2009 04:00:05 +0000

Sometimes it’s needed to send an email using PL/SQL. This can be done with few lines of code pasted below. The variables $server.address, $domain, $sender_email, $recipient_email should be replaced with the relevant information.
DECLARE l_retVal INTEGER; v_connection UTL_SMTP.connection; BEGIN v_connection := UTL_SMTP.open_connection('$server.address'); UTL_SMTP.helo(v_connection, '$domain'); UTL_SMTP.mail(v_connection, '$sender_email'); UTL_SMTP.rcpt(v_connection, '$recipient_email'); UTL_SMTP.open_data(v_connection); UTL_SMTP.write_data(v_connection, 'From: $sender_email' || UTL_TCP.crlf); UTL_SMTP.write_data(v_connection, 'To: $recipient_email' || UTL_TCP.crlf); UTL_SMTP.write_data(v_connection, 'The Subject!' || UTL_TCP.crlf); UTL_SMTP.write_data(v_connection, 'The Content!' || UTL_TCP.crlf); UTL_SMTP.close_data(v_connection); UTL_SMTP.quit(v_connection); EXCEPTION WHEN OTHERS THEN null; END;

Did it work for you?

Troubleshooting: The Function Is Not Available Under The Responsibility

Danilo Vizzarro — Fri, 27 Nov 2009 04:00:40 +0000

The error ‘The Function Is Not Available Under The Responsibility’ appears rarely after the menu of a responsibility is updated. The problem resolution is quite straight forward.

Action Plan (1)
1) Manually run the ‘Compile Security’ concurrent program, set the parameter to YES.

In case the problem is not solved, then this is another solution.

Action Plan (1)
1) Manually run the ‘Compile Security’ concurrent program, set the parameter to YES.
2) Shut down Middle Tier (Apache)
3) Delete the contents of $OA_HTML/_pages directory
4) Restart Middle tier
5) Test the menu item

HOW-TO: Change the Timeout Parameters in the EBS

Danilo Vizzarro — Mon, 20 Jul 2009 08:00:05 +0000

The Timeout Parameters, can be easily changed through the profile option setup. I would recommend to change the default values against the corporate needs and policies.

The 3 profile options that control the timeout times are:
- ICX:Session Timeout – determines how many minutes a form session can be inactive before the session is disabled. This mean that if the user is not performing any action on a certain form for the set number of minutes, he will need to log in again.

- ICX: Limit time – determines the maximum time for a connection (in hours). A user activity cannot be longer then this time.

- ICX: Limit connect – determines the maximum number of connection a user can request in each session.

To change these profile options you can open the System Profile Values Form in this way:
System Administrator -> Profile -> System

HOW-TO: Setup the Self Service Password Request Workflow

Danilo Vizzarro — Fri, 22 May 2009 12:30:59 +0000

How often a password reset is required? How long does it take to find time to reset the password manually? Implementing the Self Service Password Reset can save a lot of manual workload and can be done in few easy steps. The workflow, before the to reset the password, will ask the user to confirm by email the new password request. This prevents any other user, to reset passwords without authorization.

Here the setup to be done in the TESTING ENVIRONMENTS ONLY.

1. Execute the following queries that will change all the email addresses from the po_vendor_sites_all table
SQL> update wf_notifications set status = ‘CLOSED’, mail_status=’SENT’,end_date=SYSDATE where status != ‘CLOSED’;

SQL> update po_vendor_sites_all set email_address=’test@company.com’,remittance_email=’test@company.com’;

2. Make sure the Override Address is cleared.

System Administrator -> Workflow -> Oracle Application Manager -> Workflow Manager -> Service Components -> Workflow Notification Mailer -> View Details -> Set Override Address
Click ‘Clear Override Address’

In the TESTING ENVIRONMENTS this should be done only after the STEP 1. Otherwise the PO created for testing purposes will be really sent to the suppliers.

3. After it’s possible enable the link ‘Forgot your password?’ in the login page setting the profile option ‘Local Login Mask’ at site level to value ‘40′.

System Administrator -> Profile -> System

It’s important to make sure that the user accounts in the system have a valid email address set. In other case the risk is that the password can be sent to the wrong user.

In case something is wrong with the email setting, it’s possible to check the Workflow Notification Mailer setting
System Administrator -> Workflow -> Oracle Application Manager -> Workflow Manager -> Service Components -> Workflow Notification Mailer -> Edit

In PROD it’s enough to execute step 2 and step 3. Never execute step 1 in PROD.

Was it easy? :D

HOW-TO: Transfer an Oracle Form Personalization to a Different Environment

Danilo Vizzarro — Fri, 08 May 2009 04:00:30 +0000

After 2 weeks of holiday…
I finally wrote the script FormPersonalizationTransfer.sh that automate the transfer of one or more form personalization from an environment to another. This script will take in input the function names associated to each form personalization, will download the *.ldt files and will create the installation script to be executed on the server where the personalization should be installed.
The parameters that the script requires in input are:
- RFC NUMBER: is the Request For Change ID to be written in the installation script (can be blank)
- RFC TITLE: is the Request For Change Title to be written in the installation script (can be blank)
- RFC DEVELOPER: is the person in charge of the form personalization (can be blank)
- FILE VERSION: is the version of the installation script (can be blank)
- APPS PASSWORD: is required to download the for personalization
- FUNCTION NAMES: are required to identify the form personalization to be downloaded

The script should be executed by an OS user with enough privileges.
If you like it don’t forget to leave your comment :P

Form Personalization: Restrict the Responsibilities LoV without Disabling the End-Date Field on the form FNDSCAUS

Danilo Vizzarro — Fri, 03 Apr 2009 04:00:51 +0000

Purpose
The Purpose of this Form Personalization is to restrict the list of responsibilities that a user can assign using the ‘Users’ function that access the form FNDSCAUS.

Description
The implementation of this Form Personalization is divided in 3 steps:
1. Restrict the List of Values of the Responsibilities.
2. Restrict the Direct Responsibility List.
3. Restrict the Usernames List.

Form Personalization Function Definition
Responsibility: System Administrator
Navigate: Application -> Function
Define a new function that is a copy of the existing ‘Users’ Function (FND_FNDSCAUS). This new function will be called XX_FND_FNDSCAUS:

Once the function is created, it should be added to one of the existing responsibility.

Form Personalization – Main Screen
The standard form FNDSCAUS before the Form Personalization looks like this:

The form FNDSCAUS after the Form Personalization wont show any change.

The standard List of Values (LoV) before the Form Personalization looks like this:

The List of Values (LoV) after the Form Personalization will show less responsibilities.

Restrict the List of Values of the Responsibilities
Before to start with the Form Personalization, the following profile options should be set to the user making the Form Personalization:
o ‘FND: Diagnostics’ set to ‘Yes’
o ‘Hide Diagnostics menu entry’ set to ‘No’
o ‘Utilities:Diagnostics’ set to ‘Yes’

From the horizontal menu select: Help -> Diagnostics -> Custom Code -> Personalize

In order to restrict the list of responsibilities to be showed in the LoV, we will need to tune the query that generate that LoV modifying the conditions specified in the WHERE clause.

Argument:
SELECT R.RESPONSIBILITY_NAME, A.APPLICATION_NAME, R.RESPONSIBILITY_ID, R.APPLICATION_ID FROM FND_APPLICATION_VL A, FND_RESPONSIBILITY_VL R WHERE ( R.APPLICATION_ID = A.APPLICATION_ID AND (R.VERSION = '4' OR R.VERSION = 'W' OR R.VERSION= 'M' OR R.VERSION = 'H') AND (R.END_DATE IS NULL OR (TRUNC(SYSDATE) BETWEEN R.START_DATE AND R.END_DATE)) ) AND (R.RESPONSIBILITY_NAME LIKE '%GB') ORDER BY RESPONSIBILITY_NAME

To customize the list of responsibilities in the LoV, the WHERE clause that should be modified is
AND (R.RESPONSIBILITY_NAME LIKE '%GB')

Restrict the Direct Responsibility List
To prevent a user from removing the END_DATE of responsibilities already assigned to a user account, it would be needed to modify the list of the responsibilities showed after an username is queried.

Value:
(responsibility_id, responsibility_application_id) in (select responsibility_id, application_id from fnd_responsibility where (version = '4' or version = 'W' or version = 'M' or version = 'H') ) and (responsibility_id != 50304 and responsibility_id != 20419 and responsibility_id != 20420 and responsibility_id != 20872 and responsibility_id != 25623 and responsibility_id != 50237 and responsibility_id != 50278 and responsibility_id != 50303 and responsibility_id != 50573 and responsibility_id != 51788 and responsibility_id != 51808 and responsibility_id != 51809 and responsibility_id != 51810 and responsibility_id != 51811 and responsibility_id != 51828)

Restrict the Usernames List
To prevent a user from resetting the password of an admin user account (like SYSADMIN) it would be needed to modify the list of usernames to be queried.

Value:
user_name not in ('ANONYMOUS', 'AUTOINSTALL', 'INITIAL SETUP', 'FEEDER SYSTEM', 'CONCURRENT MANAGER', 'STANDALONE BATCH PROCESS', 'SYSADMIN', 'MOBILEADM', 'ASGADM', 'BOL-OPS', 'BOL-SETUP', 'IBEGUEST')

If it helps leave your comment or feedback! Thank you!

SCRIPT: Function that Can be Acceded by a User

Danilo Vizzarro — Fri, 27 Mar 2009 04:00:14 +0000

Sometimes it’s needed to check what a user can do in the system.
The script functions_x_user.sql can be customized to know which function a user can access.

If you find it useful don’t forget to leave your comment!

Form Personalization: Restrict the Profile Options LoV on the form FNDPOMPV

Danilo Vizzarro — Fri, 20 Mar 2009 04:00:23 +0000

Purpose
The Purpose of this Form Personalization is to limit the access to the profile option settings restricting the LoV of the profile options displayed.

Description
The implementation of this Form Personalization is divided in 2 steps:
1. Restrict the Profile Options List of Values.
2. Hide and Disable the un-needed fields.

Form Personalization Definition
Responsibility: System Administrator
Navigate: Application -> Function
Define a new function that is a copy of the existing ‘Profile System Values Function (FND_FNDPOMPV). This new function will be called XX_FND_FNDSCAUS_MDM:

Once the function is created, it should be added to one of the existing responsibility.

Form Personalization – Main Screen
The standard form FNDPOMPV before the Form Personalization looks like this:

The form FNDPOMPV after the Form Personalization will look like this:

Restrict the Profile Options List of Values
Before to start with the Form Personalization, the following profile options should be set to the user making the Form Personalization:
o ‘FND: Diagnostics’ set to ‘Yes’
o ‘Hide Diagnostics menu entry’ set to ‘No’
o ‘Utilities:Diagnostics’ set to ‘Yes’

From the horizontal menu select: Help -> Diagnostics -> Custom Code -> Personalize

This step needs to be done to avoid querying profile options related the site level.

Value (to be customized)::
START_DATE_ACTIVE <= SYSDATE and NVL(END_DATE_ACTIVE,SYSDATE) >= SYSDATE and ( SITE_ENABLED_FLAG = 'Y' or APP_ENABLED_FLAG = 'Y' or RESP_ENABLED_FLAG = 'Y' or USER_ENABLED_FLAG = 'Y' or SERVER_ENABLED_FLAG = 'Y' or SERVERRESP_ENABLED_FLAG = 'Y' or ORG_ENABLED_FLAG = 'Y') and (USER_PROFILE_OPTION_NAME = 'HZ: Generate Party Number' or USER_PROFILE_OPTION_NAME = 'HZ: Generate Party Site Number' or USER_PROFILE_OPTION_NAME = 'HZ: Maintain Location History' or USER_PROFILE_OPTION_NAME = 'HZ: Allow Update to Standardized Address')

Hide the un-needed fields
After the restriction of the Profile Option LoV, it’s possible to disable the other fields that will not be needed.

If it helps leave your comment or feedback! Thank you!

Troubleshooting: Self-Service Password Sent as Notification and not by Email

Danilo Vizzarro — Fri, 13 Mar 2009 04:00:48 +0000

In case there is a misconfiguration of the system, it can happen that when a user tries to reset his password clicking the link ‘Forgot your password?’ the password request approval is sent as a notification and not as email. Obviously if a user doesn’t remember is password cannot access the notifications.
This problem affects any user also if they have set in the Preferences as Notification Emai Style ‘HTML mail’

Below the problem resolution.

Action Plan
a. Perform Pre Health checks
b. Stop Workflow Mailer and Agent Listener service
c. Change the “WF: Workflow Mailer Framework Web Agent” [WF_MAIL_WEB_AGENT] profile option to be http://mail.server.address:port
d. Rebuild mailer queue with:
@$FND_TOP/patch/115/sql/wfntfqup.sql APPS APPLSYS
e. Start Workflow Mailer and Agent Listener service.
f. Perform post Health checks

Don’t forget to leave your comment ;)