Hiding Concurrent Requests In Oracle EBS SRS Window A Comprehensive Guide
In Oracle E-Business Suite (EBS), concurrent requests are a fundamental part of how background processes and reports are executed. When a user submits a request, such as running a report or performing a data update, it is processed as a concurrent request. These requests are visible in the Submit Request window (SRS), allowing users and administrators to monitor their progress. However, there are situations where you might want to hide specific concurrent requests from the SRS window. This article delves into the reasons for hiding concurrent requests, the methods to achieve this in Oracle EBS, and best practices to follow.
There are several scenarios where hiding concurrent requests can be beneficial. Understanding these reasons can help you determine if this approach is suitable for your needs.
- Background Processes: Some concurrent requests are part of automated background processes, such as data synchronization or system maintenance tasks. These processes run periodically and do not require user intervention or monitoring. Displaying these requests in the SRS window can clutter the interface and make it harder for users to find relevant requests.
- Security: In certain cases, you might want to hide requests that contain sensitive information or perform critical system operations. By hiding these requests, you can prevent unauthorized users from monitoring their progress or potentially interfering with them. This is particularly important in regulated industries where data privacy and security are paramount.
- User Experience: When users submit multiple requests, the SRS window can become crowded, making it difficult to track the progress of specific requests. Hiding less important or routine requests can improve the user experience by simplifying the interface and focusing attention on the most relevant tasks.
- Custom Applications: If you have developed custom applications within Oracle EBS, you might have specific concurrent requests that are only relevant to the application's internal operations. Hiding these requests can prevent confusion and ensure that users only see the requests that are relevant to their roles and responsibilities.
There are several methods to hide concurrent requests in Oracle EBS. Each method has its own advantages and limitations, so it's essential to choose the approach that best fits your requirements.
Using FND_REQUEST.SUBMIT_REQUEST with the Display Parameter
The FND_REQUEST.SUBMIT_REQUEST
API is the primary way to submit concurrent requests in Oracle EBS. This API includes a parameter that allows you to control whether the request is displayed in the SRS window.
- The
display
Parameter: Thedisplay
parameter is a Boolean value that determines whether the request is displayed in the SRS window. By default, this parameter is set toTRUE
, meaning that the request will be visible. To hide the request, you need to set this parameter toFALSE
.
Example
Consider the following PL/SQL code snippet that demonstrates how to submit a concurrent request using FND_REQUEST.SUBMIT_REQUEST
and hide it from the SRS window:
DECLARE
l_request_id NUMBER;
BEGIN
l_request_id := FND_REQUEST.SUBMIT_REQUEST(
application => 'SQLGL',
program => 'GLLEZL',
description => 'Journal Import',
start_time => SYSDATE,
sub_request => FALSE,
argument1 => '101',
argument2 => 'ACTUAL',
argument3 => '01-JAN-2024',
argument4 => '31-JAN-2024',
argument5 => 'USD',
argument6 => 'Y',
argument7 => NULL,
argument8 => NULL,
argument9 => NULL,
argument10 => NULL,
argument11 => NULL,
argument12 => NULL,
argument13 => NULL,
argument14 => NULL,
argument15 => NULL,
argument16 => NULL,
argument17 => NULL,
argument18 => NULL,
argument19 => NULL,
argument20 => NULL,
display => FALSE -- Hide the request from SRS window
);
IF l_request_id IS NOT NULL THEN
COMMIT;
DBMS_OUTPUT.PUT_LINE('Request submitted with ID: ' || l_request_id);
ELSE
DBMS_OUTPUT.PUT_LINE('Failed to submit request.');
END IF;
END;
/
In this example, the display
parameter is set to FALSE
, which will prevent the Journal Import request from being displayed in the SRS window. The request will still be submitted and processed in the background, but users will not be able to see it in the SRS window.
Creating a Custom Concurrent Program
Another approach to hiding concurrent requests is to create a custom concurrent program specifically designed for background processes. This involves defining a new concurrent program and associating it with an executable that performs the desired task.
Steps to Create a Custom Concurrent Program
- Define the Executable: Create an executable that will run the background process. This can be a PL/SQL stored procedure, a host script, or any other type of executable supported by Oracle EBS.
- Define the Concurrent Program: Define a new concurrent program in Oracle EBS and associate it with the executable created in the previous step. This involves specifying the program's name, description, application, and other relevant details.
- Set the Run Alone Flag: When defining the concurrent program, set the
Run Alone
flag toYes
. This flag indicates that the program should run as a standalone process and not be displayed in the SRS window. - Submit the Request: Submit the concurrent request using
FND_REQUEST.SUBMIT_REQUEST
, specifying the name of the custom concurrent program.
Example
Let's say you want to create a custom concurrent program to perform a nightly data cleanup task. Here's how you can do it:
-
Create a PL/SQL Stored Procedure: Create a stored procedure that performs the data cleanup task. For example:
CREATE OR REPLACE PROCEDURE xx_data_cleanup_proc IS BEGIN -- Your data cleanup logic here DELETE FROM xx_temp_data WHERE creation_date < SYSDATE - 30; COMMIT; END; /
-
Define the Executable: Define an executable in Oracle EBS that calls the stored procedure. Navigate to Concurrent > Program > Executable and create a new executable with the following details:
- Executable:
XX_DATA_CLEANUP_EXEC
- Short Name:
XX_DATA_CLEANUP_EXEC
- Application: Your custom application
- Execution Method:
PL/SQL Stored Procedure
- Execution File Name:
xx_data_cleanup_proc
- Executable:
-
Define the Concurrent Program: Define a new concurrent program in Oracle EBS. Navigate to Concurrent > Program > Define and create a new concurrent program with the following details:
- Program:
XX_DATA_CLEANUP_PROG
- Short Name:
XX_DATA_CLEANUP_PROG
- Application: Your custom application
- Executable:
XX_DATA_CLEANUP_EXEC
- Run Alone:
Yes
- Program:
-
Submit the Request: Submit the concurrent request using
FND_REQUEST.SUBMIT_REQUEST
, specifying the name of the custom concurrent program:DECLARE l_request_id NUMBER; BEGIN l_request_id := FND_REQUEST.SUBMIT_REQUEST( application => 'Your custom application', program => 'XX_DATA_CLEANUP_PROG', description => 'Nightly Data Cleanup', start_time => SYSDATE, sub_request => FALSE, display => FALSE -- This parameter is optional when Run Alone is Yes ); IF l_request_id IS NOT NULL THEN COMMIT; DBMS_OUTPUT.PUT_LINE('Request submitted with ID: ' || l_request_id); ELSE DBMS_OUTPUT.PUT_LINE('Failed to submit request.'); END IF; END; /
By setting the
Run Alone
flag toYes
, the Nightly Data Cleanup request will not be displayed in the SRS window. This approach is ideal for background processes that do not require user monitoring.
Using Custom Forms or Interfaces
In some cases, you might want to submit concurrent requests from a custom form or interface within Oracle EBS. This allows you to control the user experience and prevent requests from being displayed in the SRS window.
Steps to Use Custom Forms or Interfaces
- Create a Custom Form: Develop a custom form or interface using Oracle Forms or Oracle Application Framework (OAF). This form should include the necessary fields and buttons to submit the concurrent request.
- Implement the Submission Logic: In the form's code, use
FND_REQUEST.SUBMIT_REQUEST
to submit the concurrent request. Set thedisplay
parameter toFALSE
to hide the request from the SRS window. - Handle Feedback: Provide feedback to the user about the request's submission status, such as a confirmation message or an error message if the submission fails.
Example
Let's say you want to create a custom form to submit a report without displaying the request in the SRS window. Here's how you can do it:
-
Create a Custom Form: Create a new form in Oracle Forms with the necessary fields, such as report name, start date, and end date. Add a button to submit the report.
-
Implement the Submission Logic: In the button's
WHEN-BUTTON-PRESSED
trigger, add the following code:DECLARE l_request_id NUMBER; BEGIN l_request_id := FND_REQUEST.SUBMIT_REQUEST( application => 'SQLGL', program => 'GLLEZL', description => :REPORT_NAME, start_time => SYSDATE, sub_request => FALSE, argument1 => :START_DATE, argument2 => :END_DATE, display => FALSE -- Hide the request from SRS window ); IF l_request_id IS NOT NULL THEN COMMIT; MESSAGE('Report submitted successfully.'); MESSAGE(''); ELSE MESSAGE('Failed to submit report.'); MESSAGE(''); END IF; END;
In this example, the
display
parameter is set toFALSE
, which will prevent the report request from being displayed in the SRS window. The form provides feedback to the user through messages, ensuring they are aware of the request's status.
While hiding concurrent requests can be beneficial in certain situations, it's essential to follow best practices to ensure that the system remains manageable and transparent.
- Document Hidden Requests: It's crucial to document any concurrent requests that are hidden from the SRS window. This documentation should include the purpose of the request, the reason for hiding it, and any relevant details about its execution. This will help administrators and developers understand the system's behavior and troubleshoot any issues that may arise.
- Provide Alternative Monitoring: If you are hiding concurrent requests, consider providing alternative ways to monitor their progress. This could involve creating custom dashboards, reports, or alerts that provide insights into the status of these requests. This ensures that you can still track the execution of important processes without cluttering the SRS window.
- Use Consistent Naming Conventions: When creating custom concurrent programs or executables, use consistent naming conventions. This will make it easier to identify and manage these objects in the future. For example, you could use a prefix or suffix to indicate that a program is designed for background processing.
- Consider Security Implications: Be mindful of the security implications of hiding concurrent requests. Ensure that only authorized users have access to the underlying processes and data. Implement appropriate security measures to prevent unauthorized access or modification.
- Regularly Review Hidden Requests: Periodically review the list of hidden concurrent requests to ensure that they are still necessary and functioning correctly. This will help you identify any requests that are no longer needed or that may be causing issues.
- Inform Users: If you are hiding requests that users might expect to see, inform them about the change and provide alternative ways to track their requests. This will prevent confusion and ensure that users have the information they need.
Hiding concurrent requests in Oracle EBS can be a useful technique for improving user experience, enhancing security, and managing background processes. By using the FND_REQUEST.SUBMIT_REQUEST
API with the display
parameter, creating custom concurrent programs, or developing custom forms, you can control which requests are displayed in the SRS window. However, it's essential to follow best practices to ensure that the system remains manageable, transparent, and secure. By carefully considering the reasons for hiding requests and implementing appropriate monitoring and documentation, you can effectively use this technique to optimize your Oracle EBS environment.
By understanding these methods and best practices, you can effectively manage the visibility of concurrent requests in your Oracle EBS environment, ensuring a streamlined and secure system.