A system administrator is involved in setting up an Oracle Applications installation, controlling access, and ensuring smooth ongoing operation. The tasks involved in these functions are described in the Oracle Applications System Administrator’s Documentation Set, in these three volumes:

  • Security
  • Configuration
  • Maintenance

This Maintenance volume describes maintenance tasks for an Oracle Applications installation, as well as tasks you might perform on a frequent basis. Managing Concurrent Processing and Concurrent Programs.
Monitoring an Applications System Using Oracle Applications Manager
Oracle Applications Manager allows you to monitor many components of your applications system, such as database status, system activity, forms sessions and processes, and applications usage.
In addition, the OAM console can provide information on system alerts, metrics, and logs that can help you diagnose potential problems. For example, configuration issues,overdue routine maintenance tasks, and invalid data can cause serious problems requiring either an automated response or manual intervention.

Oracle Workflow Manager

Oracle Workflow Manager is a component of Oracle Applications Manager that allows system administrators to manage Oracle Workflow for multiple Oracle Applications instances.
Using Oracle Workflow Manager, administrators can control Workflow system services, such as notification mailers, agent listeners, and other service components, background engines, purging obsolete Workflow data, and cleanup of the Workflow control queue.
Administrators can also monitor work item processing by viewing the distribution of all work items by status and drilling down to additional information. Additionally, they can monitor event message processing for local Business Event System agents by viewing the distribution of event messages by status as well as queue propagation schedules. With this ability to monitor work items and event messages, a system administrator can identify possible bottlenecks easily.

l_api_version   NUMBER := 1.0;
l_init_msg_list VARCHAR2(2) := FND_API.G_TRUE;
l_commit        VARCHAR2(2) := FND_API.G_FALSE;  
SELECT inventory_item_id,
        segment1,
        primary_uom_code
 FROM   mtl_system_items_b
 WHERE  segment1 = v_segment1;  -- INVENTORY ITEM CODE
 
EGO_ITEM_PUB.ASSIGN_ITEM_TO_ORG( 
P_API_VERSION       => l_api_version
, P_INIT_MSG_LIST     => l_INIT_MSG_LIST
, P_COMMIT            => l_COMMIT
, P_INVENTORY_ITEM_ID => itm.inventory_item_id --(item id from the above Query)
, P_ITEM_NUMBER       => itm.segment1          --(Item Code from the above Query)
, P_ORGANIZATION_ID   => v_organization_id     --(Organization Id for assingment)
, P_ORGANIZATION_CODE => NULL--v_organization_code
, P_PRIMARY_UOM_CODE  => itm.primary_uom_code  --(UOM from the above Query)
, X_RETURN_STATUS     => X_RETURN_STATUS
, X_MSG_COUNT         => X_MSG_COUNT
); 
 
  
Custom Library (custom.pll) allows to extend/customize Oracle Applications form(Oracle Form) without changing or modifying Oracle Applications code. Examples may include enforcing a new business rule, opening a form using zoom etc. Most of the things that we can do using custom.pll, we can achieve that using Forms Personalization. Since Custom.pll takes the full advantage of PL/SQL so it is having an edge over Forms Personalization for complex customizations.
CUSTOM.pll is used to add extensions to Oracle’s form Functionality. Some of the common scenarios where CUSTOM.pll can be used are:-
1. Enabling/Disabling the fields
2. Changing the List of Values in a LOV field at runtime
3. Defaulting values
4. Additional record level validations
5. Navigation to other screens
6. Enabling Special Menu

Where is this located?
Custom.pll is located in $AU_TOP/resource Directory.
How to add code to this?
Open this pll using the Form builder and make changes to the program units.

How to compile this PLL?
 Once you make changes you need to compile the pll. Use the F60gen to compile it
f60gen module=custom.pll userid=APPS/ output_file=$AU_TOP/resource/custom.plx module_type=library batch=no compile_all=special
While writing code inside custom.pll we should consider following things:
1. We should not run any SQL statement inside this, we can use record group.
2. We should not perform any DML operations, instead we should call database procedure and functions for the same.

For following Events call will go to CUSTOM Library:
 
WHEN–FORM–NAVIGATE
WHEN–NEW–FORM–INSTANCE
WHEN–NEW–BLOCK–INSTANCE
WHEN–NEW–RECORD–INSTANCE
WHEN–NEW–ITEM–INSTANCE
WHEN–VALIDATE–RECORD
SPECIALn (where n is a number between 1 and 45)
ZOOM
EXPORT
KEY–Fn (where n is a number between 1-8)

Custom Library contains Custom Package which is having two Functions and one procedure.
1] ZOOM_AVAILABLE:
This function allows you to specify if zooms exist for the current context. If zooms are available for this block, then return TRUE else return FALSE. This routine is called on a per-block basis within every Applications form from the WHEN-NEW-BLOCK-INSTANCE trigger. Therefore, any code that will enable Zoom must test the current form and block from which the call is being made. By default this routine must return FALSE.

Sample code1:

function zoom_available return Boolean is
form_name  varchar2(30) := name_in(‘system.current_form’);
block_name varchar2(30) := name_in(‘system.cursor_block’);
begin
if (form_name = ‘DEMXXEOR’ and block_name = ‘ORDERS’) then
return TRUE;
else
return FALSE;
end if;
end zoom_available;

Sample code2:

function zoom_available return Boolean is
form_name  varchar2(30) := name_in(‘system.current_form’);
block_name varchar2(30) := name_in(‘system.cursor_block’);
begin
if (form_name = ‘APXINWKB’ and block_name = ‘INV_SUM_FOLDER’)
then
return TRUE;
elsif (form_name = ‘APXINWKB’ and block_name = ‘LINE_SUM_FOLDER’)
then
return TRUE;
else
return FALSE;
end if;
end zoom_available;


2] STYLE:
This function returns a integer value. This function allows to override the execution style of Product specific events, but it doesn’t effect generic events like when-new-form-instance. Possible return values are:
1. custom.before
2. custom.after
3. custom.override
4. custom.standard

By default it returns custom.standard.

Sample code:
 
function custom.style(event_name varchar2) return integer is
begin
if event_name = ’MY_CUSTOM_EVENT’ then
return custom.override;
else
return custom.standard;
end if;
end style;

3] EVENT: 
This procedure allows you to execute your code at specific events including:

  –    ZOOM
  –    WHEN-NEW-FORM-INSTANCE
  –    WHEN-NEW-BLOCK-INSTANCE
  –    WHEN-NEW-RECORD-INSTANCE
  –    WHEN-NEW-ITEM-INSTANCE
  –    WHEN-VALIDATE-RECORD
By default this routine must perform ‘null;’

Sample code:
procedure event(event_name varchar2) is
form_name varchar2(30) := name_in(’system.current_form’);
block_name varchar2(30) := name_in(’system.cursor_block’);
begin
if (form_name = ‘XXBI’ and block_name = ‘xxcc’) Then
if(event_name = ‘WHEN-NEW-FORM-INSTNACE’)
–Write your code here
elsif(event_name = ‘WHEN-VALIDATE-RECORD’)THEN
–Write your code here
else
null
end if;
end if;
end;


How to make the changes get affected?

Once you make all the necessary changes, compile the pll and generate the PLX file. Since the CUSTOM library is loaded once for a given session, a user must log out of the application and sign-on again before any changes will become apparent.
Forms Personalization: an alternative of custom.pll
In older versions, prior to 11i, Custom.PLL was most prominently used for adding additional features in the seeded form but the latest version of Oracle EBS comes with the feature called as Forms Personalization which allows even an end user to alter the seeded forms functionality using an user interface called the Personalization form.
Advantages of Forms Personalization over Custom.PLL:

  • Forms personalization can be used by an user with limited PL/SQL knowledge. 
  • Changes take place immediately on reopening the form.
  • Anything which can be done using Custom.PLL can be done using Forms Personalization also.
  • Personalizations are stored in base tables related to Form Personalization.
  • CUSTOM.pll is a single file/entity, hence only one developer can make changes to CUSTOM.pll at any given point in time. This is not a restriction in Forms personalization.
  • Easy to disable/enable with click of a button.
  • Can be moved easily through FNDLOAD from one instance to other.
  • Can be restricted at site/responsibility/user level.
  • Personalization stores who columns with which we have the ability to track who created/modified it where as in CUSTOM.PLL we don’t have that ability.

Steps To Register Unix Shell Script As A Concurrent Program

We can register an Unix shell script in our oracle application through a concurrent program. Here are the steps.
Step 1:
Copy the .prog script in ASCII mode to the bin directory of your application top directory. For example, call the script XXSHELL.prog and place it under $XXCUST_TOP/bin
step 2:
Check the file permissions. Sometimes it is required to give full permission to the script.
step 3:
Make a symbolic link from your script to $FND_TOP/bin/fndcpesr For example, if the script is called XXSHELL.prog , then use this:
cd $XXCUST_TOP/bin
ln -s $FND_TOP/bin/fndcpesr XXSHELL
This link should be named the same as your script without the .prog extension. Put the link for your script in the same directory where the script is located.
step 4:
Register the concurrent program, using an execution method of ‘Host’. Use the name of your script without the .prog extension as the name of the executable.
For the example above: Use XXSHELL as executable name.
Note:
Your script will be passed at least 4 parameters, from $1 to $4.
$1 = orauser/pwd
$2 = userid(apps)
$3 = username,
$4 = request_id

Any other parameters you define will be passed in as $5 and higher. Make sure your script returns an exit status also.
fndcpesr is a standard utility available in $FND_TOP directory. It is mainly used by the application to parse the above four arguments to the shell scripts.

The following query will fetch the Parameter List and associated Value Sets of a Concurrent Program.

SELECT
        fcpl.user_concurrent_program_name “Concurrent Program Name”,
        fcp.concurrent_program_name “Short Name”,
        fdfcuv.column_seq_num “Column Seq Number”,
        fdfcuv.end_user_column_name “Parameter Name”,
        fdfcuv.form_left_prompt “Prompt”,
        fdfcuv.enabled_flag ” Enabled Flag”,
        fdfcuv.required_flag “Required Flag”,
        fdfcuv.display_flag “Display Flag”,
        fdfcuv.flex_value_set_id “Value Set Id”,
        ffvs.flex_value_set_name “Value Set Name”,
        flv.meaning “Default Type”,
        fdfcuv.DEFAULT_VALUE “Default Value”

FROM
        fnd_concurrent_programs fcp,
        fnd_concurrent_programs_tl fcpl,
        fnd_descr_flex_col_usage_vl fdfcuv,
        fnd_flex_value_sets ffvs,
        fnd_lookup_values flv

WHERE
        fcp.concurrent_program_id = fcpl.concurrent_program_id
        AND    fcpl.user_concurrent_program_name = :conc_prg_name
        AND    fdfcuv.descriptive_flexfield_name = ‘$SRS$.’
                 || fcp.concurrent_program_name
        AND    ffvs.flex_value_set_id = fdfcuv.flex_value_set_id
        AND    flv.lookup_type(+) = ‘FLEX_DEFAULT_TYPE’
        AND    flv.lookup_code(+) = fdfcuv.default_type
        AND    fcpl.LANGUAGE = USERENV (‘LANG’)
        AND    flv.LANGUAGE(+) = USERENV (‘LANG’)

ORDER BY fdfcuv.column_seq_num;