Concurrent Program
Concurrent Program
Concurrent Program
The printer styles have to be configured to execute a shell script instead of sending the output to a physical
printer.
The shell script then emails the concurrent program output to the intended recipient.
Step 2: Define Printer Style: Click on the Style button in the Printer Types form (as seen in the previous screenshot).
Create a new style and save it.
Step 3: Define Printer Driver: Click on Driver button in the Printer Types form. Specify Driver method as command.
Specify the following in the arguments section: $XXCUST_TOP/bin/EMAIL.sh $PROFILES$.CONC_REQUEST_ID
30
Step 4: Mapping: Map the Printer Style and Printer Driver to the Printer Type.
Step 5: Install the Printer and map the Printer Type : Create a new printer and map the Printer Type created in the
previous step.
Step 6: Attach the defined printer to the concurrent program: Navigation: Concurrent > Program > Define .Specify
printer in Output section
Step 7: Running the Concurrent Program: Before clicking on the Submit button in the SRS window, specify non-zero
value of no. of copies by clicking on the Options button.
This will invoke Printer.
Step 8: The sample shell script (email_conc_prog_output.sh) that is executed after the completion of the above steps
is attached with the article.
Steps for Method 2
This feature is available in the new button Delivery Opts as seen in the screenshot below.
On clicking the Delivery Opts Button, a new form will pop up which will allow users to specificemail addresses of the
sender, recipient and carbon copy recipient (multiple emails can be specified separated by commas), subject of the
The Email tab (as seen in the screenshot above) utilizes SMTP to communicate to a mail hostwhich in turn sends the
email to the recipients. The hostname and port of the mail host is configured via the profile values:
FND: SMTP Host and FND: SMTP Port
1. Ensure your users understand that there is no bursting capability here. The ENTIRE report
that is produced will be delivered to ALL addresses specified in the form. i.e. you may not want
to send a range of invoices to 3 different email addresses at different companies
2. Ensure your users understand that they will still need to pick a printer in the Upon
Completion form. Choosing a printer in the Delivery Options form is not enough. You could
always default the printer for the report if applicable.
3. Understand that this is currently version 1 of this functionality. It does have some issues and
inconsistencies. Ive documented these in the previous posts that go through the specific
functionality.
Here at STR Software we have been working on some exciting enhancements to
ourAventX product that ties directly in with this Delivery Options form as well as bursting control
files that will expose a lot of really great functionality. Training is scheduled for our internal staff
next week. I will post more information on this in the next couple weeks.
Posted by Elangovan Ragavan at 11:02 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
Functionality
This tab allows users to transfer the Concurrent Request output to a remote host either
using FTP or SFTP. The user is able to specify the following:
Server Where the data is to be transferred.
Port Port on which the FTP/SFTP server is listening. Not a required field, will default to
the correct port.
User User logon on the server in question.
Pwd Password for user on the server.
Remote Dir Directory on remote server to place concurrent program output.
Secure Checkbox to denote SFTP vs FTP.
There is no additional configuration screen or options.
Regarding the name of the transferred file, I have found that the resulting filename is the same
as what is generated by the Concurrent Manager. For example:
When transfering BI Publisher data, the name of the file is
<PROGRAM_SHORTNAME>_<REQUEST_ID>.PDF
When transferring Oracle Report data, the name of the file is o<REQUESTID>.out
I also came across some interesting things regarding status when I accidently fat fingered the
User field. In most cases when entering incorrect data, the Concurrent Program would
complete successfully, with no indication in the Concurrent Program log that there was a
problem! For example, if the password is wrong, the request completes normally and the log
has the following information:
+------------- 2) DELIVER -------------+
CONC-DELIV-FTP (SERVER=wolfmanr12)
Beginning post-processing of request 5873740 on node WOLFMANR12 at 01-SEP-2010
11:07:37.
Post-processing of request 5873740 completed at 01-SEP-2010 11:07:37.
+--------------------------------------+
Based on this, I quickly tested the other combinations and came up with the following:
Test
FTP
SFTP
Incorrect
Server
Incorrect Port
Incorrect
Username
Incorrect
Password
Incorrect
Directory
In the 2 cases above where SFTP threw an error, the error in the log was:
+------------- 2) DELIVER -------------+
CONC-DELIV-FTP (SERVER=asdfasdf)
Beginning post-processing of request 5873744 on node WOLFMANR12 at 01-SEP-2010
11:13:22.
Post-processing of request 5873744 failed at 01-SEP-2010 11:13:22 with the error message:
One or more post-processing actions failed. Consult the OPP service log for details.
+--------------------------------------+
The OPP log did have the actual exception thrown in these 2 cases.
Pros and Cons
The biggest Pro here is for those companies who have FTP programs out there that are being
called to deliver concurrent program data to remote hosts such as banks, logistics companies,
retail sites, other vendors, etc They could potentially remove the need for managing a
customization and utilize this new form.
Other than having no way to name the file on the remote machine, the biggest Con here is what
I described above regarding status. Basically, you do not want to make a typo. If you do, there is
little to no information available to tell you that there was a problem!
This tab allows for the delivery of the report in question via fax. Users are able to specify:
Fax Server The IPP server to use that has fax capabilities.
Username Some IPP servers require authentication, this field allows for the passing of
a username.
Password Use this field to specify the password for the username entered in the
previous field.
Fax Number Where to actually send the Fax!
Configuration
The fax functionality implemented via this tab utilizes IPP to communicate with a fax modem.
Essentially you are setting up a printer that communicates with a fax modem. Oracle
recommends the following setup:
CUPS Common UNIX Printing System to manage the IPP communication.
efax This is a piece of software that will communicate with a fax modem to send
documents.
FAX4CUPS - This is a piece of software that bridges the gap between CUPS and efax.
FAX4CUPS exists on the system as a printer.
Fax Modem Similar to the modem you used to dial into AOL, Prodigy and
CompuServe, but is specialized for faxing.
Once the above hardware and software are working, Oracle EBS needs to be configured so that
it knows what Fax Servers are available. This is done in the same way that the IPP Print
tab was setup with one addition. In the screenshot below you must check the box to enable the
IPP Printer for Fax.
Follow this navigation path to access this form: System Administration Responsibility -> Delivery
Options. Detailed information about each configuration item can be found in Part 2 of this series.
Functionality
In the end, once you have all of the software and hardware components working, the flow from
Oracle EBS is as follows:
User submits document, a concurrent request is run.
For each Fax Number that the User Specifies:
a. The Output Post Processor communicates via IPP to CUPS and says that it has a job for the
FAX4CUPS printer. If this communication is successful the Concurrent Request completes
successfully.
b. CUPS gives the FAX4CUPS printer the document to send and the fax number.
c. FAX4CUPS communicates with efax and tells it to send the document to the fax number.
d. efax sends the proper commands to the fax modem
e. The fax modem connects to the fax number and sends the document.
As you can see in (a) above, once the Output Post Processor hands off the job to CUPS
successfully, the rest of the process is assumed successful. This status indicator does not
account for the actual status of the fax transmission which could be subject to a host of issues
such as fax busy signals, invalid/wrong fax numbers, no dial tone, transmissions getting cut
short etc
Note that there is no bursting functionality associated with this form. What you set for your
report parameters is what is going to be sent to the fax numbers in the list.
Pros and Cons
To me, the most important thing to consider for the pros and cons of this functionality hinges on
2 factors:
1. Volume of documents that need to be delivered.
2. How critical the documents are to the business.
For instance, if you need to deliver a low volume of one off documents and can manage
exceptions manually, then this solution gives you a great way for your users to take control and
stop walking to the fax machine.
However, if you need to deliver a high volume of documents and need an audit trail of what has
actually happened with those documents then you may need a different solution that enables:
1. The ability to burst.
Its important to note that this form only applies to one off transmissions to single fax numbers.
That means that if you choose a range of invoices across multiple customers and you choose to
use this functionality to fax the data, ALL of that data is going to the fax numbers specified
(meaning customers will see each others invoices!). In the past I have blogged about BI
Publishers bursting functionality that can aid in enabling this functionality.
2. The ability to determine the true status of the fax.
A fax can fail to be transmitted for a lot of reasons. The line could be busy, a person could
answer the call instead of a fax machine, the connection could drop halfway through
transmission, the number could be plain wrong, no dial tone or just no answer at all. Ideally you
want a solution where your USERS can manage these exceptions instead of calling up a
system administrator. The only way that users will be able to manage these issues is if they
have visibility into the status of the documents and a way to correct the problem.
3. A queuing mechanism.
If a fax does fail for some reason, it would be nice if that fax could be retried a few minutes later
automatically instead of having to send the fax again manually. Fax modems will attempt to
send the document, but if it fails, its not going to try it again on its own. Software would have to
manage any subsequent attempts.
4. The ability to use network or internet based fax servers.
Lets face it, fax modem technology is old. There are much better options out there that provide
better reliability, the ability to pump more faxes out of more lines and the ability to hook into your
modern infrastructure (Fax Over IP, Digital vs Analog lines, Multiple Lines, etc).
5. The ability to add more meta-data to the fax envelope.
Information such as To Name, To Company, From Name, Document Number, Cover Page
Remarks, etc become extremely helpful in the identification of documents when an issue
arises and for the professional presentation of the fax in the recipients hands.
So in the end, it all depends on your needs. If youre looking for a solution that enables users to
send a couple of faxes a day this functionality should suit. If youre looking for a solution to
handle some serious volume with mechanisms to handle the issues mentioned above, you
might be wise to check out some alternative implementations.
So there you have it, the Fax Tab in all its glory. Next up the FTP tab.
Posted by Elangovan Ragavan at 10:42 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
This tab allows for the delivery of the report in question via email. Users are able to specify:
From The sender of the email. By default this field is populated with the email address
specified for a user in the fnd_user table. This default can be overwritten by the user.
Subject The subject for the email. By default this field is populated with the string
Instance Name : Concurrent Program Name : Username where
Instance Name is pulled from the query: select instance_name from v$instance
Concurrent Program Name is the program that is being run
Username is the user name running the report.
This value can be overwritten by the user.
To Email address of the recipient. Multiple addresses can be specified by separating
them with a comma.
CC Email address for the carbon copy recipient. Multiple addresses can be specified
by separating them with a comma.
Configuration
The Email tab utilizes SMTP to communicate to a mail host that in turns sends the email to the
recipients. The hostname and port of the mail host is configured via the profile values:
FND: SMTP Host
FND: SMTP Port
Based on the package fnd_delivery, it appears that SMTP username and password should be
able to be set, however it is currently unknown if this is fully implemented. It does not appear
that these functions are invoked.
Functionality
For each recipient row (To/CC), a new email is sent to the defined recipients. The behavior of
the delivered email is as following:
1. If the report being delivered is TEXT based, then the email message body contains the report
contents.
2. If the report being delivered is NON-TEXT, then the email message body is blank and
attachment containing the report contents is delivered. The attachment name is derived from the
Concurrent Program Short Name and Request ID. For example:
POXPRPOP_12345676_1.PDF
It is important to note that there is NO bursting functionality associated with this form. What you
define for your concurrent request parameters to generate output is what is going to be sent to
the end recipients.
Pros and Cons
Overall this appears to be some great new functionality, the immediate/obvious pro that I see is
that the ability to send reports as email is now available. Additionally, the ability to specify a from
email address allows the sender to receive any bounce backs that may happen based on a
botched email address.
Some issues that I see with this new functionality are:
1. Format of the email depending on the report output type, the email will be delivered with the
report as an attachment or as part of the email message body. In most cases I would think that
the message body should be somewhat configurable, i.e. a way to say Hello xyz, here is the
report that I promised you or at the very least have some hardcoded information about the
sender and contents of the email.
2. Attachment names. The names of the attachments that get delivered with the email are not
the most user friendly as it is derived from internal Oracle information (Request ID, Program
Name).
3. User experience/process. Because the Upon Completion form where a user would typically
specify a printer is still in play, a user must ensure that if they only want to email the report that
the printer is set to noprint or something similar. For example, if I want to email the Active
Users report to my System Administrator, I have to do the following.
a. Submit a New Request, choose the Active Users report.
b. Pop the Delivery Options form and fill in the appropriate email parameters.
c. Pop the Upon Completion form and change the printer/style combination such that the report
is not actually printed out.
d. Hit submit to process the request.
Overall, likely not a huge issue, but (c) is just another step a user has to take to prevent errant
print-outs of data when they really just want to email the report.
Next up. the Fax tab. Additionally, would love to have your feedback regarding your thoughts
about the functionality.
Posted by Elangovan Ragavan at 10:39 2 comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
Oracle EBS R12.1.3 Submit Request Delivery Options Button IPP Print
Today, its the IPP Print tab. This tab allows users to select any number of IPP printers to print
the results of the concurrent request once the data is generated.
To setup a printer:
1. Install CUPS
2. Setup your printers within CUPS
3. Setup your printers defined via CUPS in EBS using the above form with the following options:
Delivery Name User friendly name for users to select on the Delivery form.
Delivery Type You only have one choice, IPP Printer
Description User friendly description for later identification
Host Name Your CUPS server
Port The port that CUPS is listening on
Printer Name The name of the printer as defined in CUPS
User Name For use with Authentication
Password For use with Authentication
Sides Allows to choose either single side printing or duplex IF your printer supports
the option.
Authentication Whether or not to authenticate with the CUPS server
Encryption Whether or not to use SSL to communicate with the CUPS server
Use Full URL Whether or not to send the full URL for the HTTP request header to the
CUPS server. This may or may not need to be turned on depending on how CUPS is configured
Use Chunked Body Whether or not to use chunked transfer encoding for the IPP
message to CUPS. This may or may not need to be turned on depending on how CUPS is
configured
Support Fax Allows use of this printer for fax jobs. We will discuss this in a later post
Once you have setup all of your printers, your users will be able to select them and print their
reports!
Pros and Cons
Like anything, there are pros and cons to all new functionality. Getting the cons out of the way
first, this is what I see:
1. Standard printing is still executed upon completion of the concurrent request. For years,
users have been using the Upon Completion form to specify a style and printers to print the
concurrent request output.
This functionality has not been changed or removed, if a user specifies a printer using the new
Delivery Opts form and there is a printer defined for the report itself, the concurrent request will
print to both as shown in the log below below.
+------------- 1) PRINT -------------+
Printing output file.
Request ID : 5871047
Number of copies : 1
Printer : marketing
++
+- 2) DELIVER -+
CONC-DELIV-IPP-PRINTER (PRINTER=/printers/marketing)
Beginning post-processing of request 5871047 on node WOLFMANR12 at 12-AUG-2010
06:00:31.
Post-processing of request 5871047 completed at 12-AUG-2010 06:00:43.
++
Finished executing request completion options.
The fact that it does this opens up the following cons:
2. User Re-training If organizations want to use this functionality, users will need to be
retrained to specify printers here vs. in the Upon Completion form.
3. System Configuration All of the print drivers, styles and types that currently define printers
are no longer needed for this functionality, all of the printers will need to be setup using the new
printer definition form shown above. This also has an impact on concurrent program definitions
as default styles and printers can be setup on a report basis. If this is not changed and duplicate
copies of the information is not desired, users will need to change the print options upon
submission. Finally, users have specific printers assigned to them via the profile value Printer.
This profile value does not translate to this new form.
4. The power of EBS Print Drivers and Styles EBS print drivers and styles allow for some fairly
complex processing and configuration including paper size selection, initialization strings, tray
selection and running custom programs. This new functionality does not take any of this into
account.
As far as the pros go, the only thing I was able to come up with is
1. In conjunction with the rest of the functionality the new Delivery Opts form brings (Email, Fax,
FTP), it makes sense to have a user specify all of the delivery information in one place.
Id love to hear any comments on this new print functionality. What do people think, will you use
it?
Posted by Elangovan Ragavan at 10:35 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
We installed the 12.1 RUP3 patches last week and there are some changes to note. The most
interesting to me was the hook to the BI Publisher Delivery Manager on the Submit Request
screen. Take a look at the picture below, youll see a new button called Delivery Opts.
When pressed, the Delivery Opts button will pop a new form that allows you to specify delivery
addresses for IPP Printers, Email, Fax and FTP destinations.
I thought Id use the next couple of posts to go through the functionality, stay tuned.
List of Concurrent Programs that are not in any Request Set Query
FROM apps.alr_alerts a
WHERE a.application_id = r.argument1
AND a.alert_id = r.argument2
AND language = 'US')
END
concurrent_program_name,
DECODE (c.class_type,
'P', 'Periodic',
'S', 'On Specific Days',
'X', 'Advanced',
c.class_type)
schedule_type,
CASE
WHEN c.class_type = 'P'
THEN
'Repeat every '
|| SUBSTR (c.class_info, 1, INSTR (c.class_info, ':') - 1)
|| DECODE (SUBSTR (c.class_info,
INSTR (c.class_info, ':', 1, 1) + 1,
1
),
'N',
' minutes',
'M',
' months',
'H',
' hours',
'D',
' days'
)
|| DECODE (SUBSTR (c.class_info,
INSTR (c.class_info, ':', 1, 2) + 1,
1
),
'S',
' from the start of the prior run',
'C',
' from the completion of the prior run'
)
WHEN c.class_type = 'S'
THEN
NVL2 (dates.dates, 'Dates: ' || dates.dates || '. ', NULL)
|| DECODE (SUBSTR (c.class_info, 32, 1),
'1',
'Last day of month '
)
|| DECODE (SIGN (TO_NUMBER (SUBSTR (c.class_info, 33))),
'1',
'Days of week: '
|| DECODE (SUBSTR (c.class_info, 33, 1), '1', 'Su ')
|| DECODE (SUBSTR (c.class_info, 34, 1), '1', 'Mo ')
fr.responsibility_key,
fr.data_group_id,
fr.request_group_id,
fr.application_id,
fa.application_short_name,
fcq.concurrent_queue_id,
fcq.concurrent_queue_name,
fcq.min_processes,
fcq.target_processes,
fcq.target_node,
fcq.sleep_seconds,
fcq.control_code,
fcq.diagnostic_level,
fcpr.*
FROM fnd_application fa,
fnd_concurrent_programs fcp,
fnd_conc_processor_programs fcpp,
fnd_responsibility fr,
fnd_concurrent_queues fcq,
fnd_concurrent_processes fcpr
WHERE fcq.processor_application_id = fcpp.processor_application_id
AND fcq.concurrent_processor_id = fcpp.concurrent_processor_id
AND fcpp.concurrent_program_id = fcp.concurrent_program_id
AND fcpp.program_application_id = fcp.application_id
AND fcp.application_id = fa.application_id
AND fcp.concurrent_program_name =
NVL ('&EnterProgramShortName', 'INXDSD')
AND fr.application_id = 401
AND fr.data_group_id = fcq.data_group_id
AND fcq.manager_type = '3'
AND fcpr.concurrent_queue_id = fcq.concurrent_queue_id
AND fcpr.queue_application_id = fcq.application_id
-- AND fcpr.process_status_code = 'A'
AND fcpr.instance_number = USERENV ('instance')
ORDER BY DBMS_RANDOM.random;
Posted by Elangovan Ragavan at 13:41 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
THURSDAY, 3 JULY 2014
------------------------------------------------------------------------------- Query to find Parameters and Value Sets associated with a Concurrent
Program
-----------------------------------------------------------------------------SELECT fcpl.user_concurrent_program_name "Concurrent Program Name",
fcp.concurrent_program_name
"Program Short Name",
fdfcuv.column_seq_num
"Column Seq #",
fdfcuv.end_user_column_name
"Parameter Name",
fdfcuv.form_left_prompt
"Prompt Name",
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 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')
AND fdfcuv.enabled_flag
= 'Y'
AND fcpl.user_concurrent_program_name = 'XX AR Conversion Program' -<change it>
ORDER BY fdfcuv.column_seq_num;
Posted by Elangovan Ragavan at 17:12 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
WEDNESDAY, 2 JULY 2014
c.date1 start_date,
c.date2 end_date,
c.class_info
FROM fnd_concurrent_requests r,
fnd_conc_release_classes c,
fnd_concurrent_programs_tl p,
fnd_user s,
(WITH date_schedules
AS (SELECT release_class_id,
RANK () OVER (PARTITION BY release_class_id ORDER BY s)
a,
s
FROM (SELECT c.class_info,
l,
c.release_class_id,
DECODE (SUBSTR (c.class_info, l, 1),
'1',
TO_CHAR (l)
)
s
FROM (SELECT LEVEL l
FROM DUAL
CONNECT BY LEVEL <= 31),
fnd_conc_release_classes c
WHERE c.class_type = 'S'
AND INSTR (SUBSTR (c.class_info, 1, 31), '1') > 0)
WHERE s IS NOT NULL)
SELECT release_class_id,
SUBSTR (MAX (SYS_CONNECT_BY_PATH (s, ' ')), 2) dates
FROM date_schedules
START WITH a = 1
CONNECT BY NOCYCLE PRIOR a = a - 1
GROUP BY release_class_id) dates
WHERE r.phase_code = 'P'
AND c.application_id = r.release_class_app_id
AND c.release_class_id = r.release_class_id
AND NVL (c.date2, SYSDATE + 1) > SYSDATE
AND c.class_type IS NOT NULL
AND p.concurrent_program_id = r.concurrent_program_id
AND p.language = 'US'
AND dates.release_class_id(+) = r.release_class_id
AND r.requested_by = s.user_id
ORDER BY conc_prog, on_hold, next_run;
THURSDAY, 29 MAY 2014
LOOKUP_COD
E
C
I
P
MEANING
Complete
d
Inactive
Pending
Running
LOOKUP_COD
E
R
I
Z
D
U
E
M
C
H
W
B
P
Q
S
X
T
A
G
MEANING
Normal
Normal
Waiting
Cancelled
Disabled
Error
No
Manager
Normal
On Hold
Paused
Resuming
Scheduled
Standby
Suspended
Terminated
Terminating
Waiting
Warning
Normally a concurrent request proceeds through three, possibly four, life cycle
stages or phases,
Phase Code
Pending
Running
Request is running
Completed
Inactive
Within each phase, a request's condition or status may change. Below appears
a listing of each phase and the various states that a concurrent request can go
through.
Status
Normal
Description
Request is waiting for the next available manager.
Standby
Scheduled
Waiting
Normal
Paused
RUNNING
Resuming
Terminating
Normal
Error
Warning
COMPLETED
Cancelled
Terminated
Disabled
, 'Other')
execution_method_code
, COUNT (*) ct
FROM applsys.fnd_executables fe
, applsys.fnd_executables_tl fet
WHERE fe.executable_id = fet.executable_id
GROUP BY fe.execution_method_code
, DECODE (fe.execution_method_code
, 'A', 'Spawned'
, 'B', 'Request Set Stage Function'
, 'E', 'Perl Concurrent Program'
, 'H', 'Host'
, 'I', 'PL/SQL Stored Procedure'
, 'J', 'Java Stored Procedure'
, 'K', 'Java Concurrent Program'
, 'L', 'SQL*Loader'
, 'M', 'Multi Language Function'
, 'P', 'Oracle Reports'
, 'Q', 'SQL*Plus'
, 'S', 'Immediate'
, 'Other')
ORDER BY 3 DESC;
Posted by Elangovan Ragavan at 13:44 2 comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
, 'Other') execution_method_code
, fet.user_executable_name
, fet.description executable_description
, fe.execution_file_name
FROM applsys.fnd_concurrent_programs fcp
, applsys.fnd_concurrent_programs_tl fcpt
, applsys.fnd_application_tl fat
, applsys.fnd_executables fe
, applsys.fnd_executables_tl fet
WHERE fcp.concurrent_program_id = fcpt.concurrent_program_id
AND fcp.application_id = fat.application_id
AND fcp.executable_id = fe.executable_id(+)
AND NVL (fe.executable_id, 0) = fet.executable_id
AND fcpt.user_concurrent_program_name LIKE '%Requisi%Import%'
-- AND fat.application_name = 'General Ledger'
AND 1 = 1;
Posted by Elangovan Ragavan at 13:42 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
TUESDAY, 10 DECEMBER 2013
Query in the front-end to see whether your Concurrent program is created or not.
Usually we Attach Concurrent program to the request group in the front-end, but this can be
done from database tier too.
Below is the program to Attach Concurrent program to the request group from back-end.
BEGIN
FND_PROGRAM.add_to_group('XXMZ_ERPSCHOOLS_EMPLOYEE' -- program_short_name
, 'XXMZ Custom' -- application
, 'xxmz Request Group' -- Report Group Name
, 'XXMZ'); -- Report Group Application
COMMIT;
END;
Query in the front-end to see whether your Concurrent program is Attached to Request Group or
not.
4) Submitting Concurrent Program from Back-end
====================================================
We first need to initialize oracle applications session using
fnd_global.apps_initialize(user_id,responsibility_id,application_responsibility_id) and then run
fnd_request.submit_request
DECLARE
l_request_id NUMBER(30);
begin
FND_GLOBAL.APPS_INITIALIZE (user_id => 1318, resp_id => 59966, resp_appl_id =>
20064);
l_request_id:= FND_REQUEST.SUBMIT_REQUEST ('XXMZ' --Application Short name,
'VENDOR_FORM'-- Concurrent Program Short Name );
DBMS_OUTPUT.PUT_LINE(l_request_id);
commit;
end;
*****************************************************
To get the resp_id and resp_appl_id use the below queries.
--SELECT APPLICATION_ID, RESPONSIBILITY_ID
FROM FND_RESPONSIBILITY_TL
WHERE RESPONSIBILITY_NAME='xxmz Custom'
--SELECT USER_ID FROM FND_USER WHERE USER_NAME='OPERATIONS'
*****************************************************
Once the concurrent program is submitted from back-end, status of the concurrent program can
be checked using below query.
SELECT * FROM FND_CONCURRENT_REQUESTS WHERE REQUEST_ID=2766602
Posted by Elangovan Ragavan at 19:18 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
FRIDAY, 15 NOVEMBER 2013
SQL to get the request sets that can execute the required concurrent program
SELECT frs.user_request_set_name "Request Set Name", frs.start_date_active
"Request set Start Date",
frs.end_date_active "Request set End Date", frsf.stage_name,
frsf.user_stage_name, frsp.SEQUENCE "Stage Request Sequence",
fcp.user_concurrent_program_name "Concurrent Program"
FROM fnd_request_sets_vl frs, fnd_req_set_stages_form_v frsf,
fnd_request_set_programs frsp, fnd_concurrent_programs_tl fcp
WHERE frs.request_set_id = frsf.request_set_id
AND frsf.request_set_stage_id = frsp.request_set_stage_id
AND frsp.concurrent_program_id = fcp.concurrent_program_id
AND fcp.user_concurrent_program_name = ':Concurrent_prog_name'
WHERE
B.USER_ID = A.REQUESTED_BY
AND A.REQUEST_ID = C.REQUEST_ID
AND A.REQUESTED_START_DATE > SYSDATE
AND A.HOLD_FLAG = 'N'
AND A.STATUS_CODE IN ('Q', 'I')
AND B.USER_NAME LIKE '%'
AND A.DESCRIPTION LIKE '%'
ORDER BY A.REQUEST_ID
Posted by Elangovan Ragavan at 20:10 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
TUESDAY, 17 JULY 2012
SELECT *
FROM apps.FND_CONC_REQ_SUMMARY_V
WHERE
phase_code = 'P'
AND status_code IN ('I', 'Q')
AND (NVL (request_type, 'X') != 'S')
AND requested_start_date >= SYSDATE
ORDER BY program_short_name DESC;
PHASE_CODE status P stands for Pending
STATUS_CODE status I stands for Normal & status Q stands of Standby
Request_type != 'S' condition is to disallow Request Set Stage programs
Posted by Elangovan Ragavan at 12:23 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
AND
AND
AND
MON-YYYY')
AND
fcr.phase_code = 'C'
fcr.status_code = 'E'
fcr.actual_completion_date > to_date('&Enter_Date','DDfcp.user_concurrent_program_name NOT IN
('Request Set Stage', 'Report Set')
ORDER BY 1
Posted by Elangovan Ragavan at 12:21 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
MONDAY, 16 JULY 2012
WHERE concurrent_program_id =
(SELECT CONCURRENT_PROGRAM_ID
FROM fnd_concurrent_programs_tl
WHERE upper(USER_CONCURRENT_PROGRAM_NAME) =
upper( '&Enter_Prog_name')));
Query 2:
Provide the Request Set name to the following query.
It lists all concurrent programs of this Request Set.
SELECT USER_CONCURRENT_PROGRAM_NAME
FROM fnd_concurrent_programs_tl
WHERE CONCURRENT_PROGRAM_ID IN
(SELECT concurrent_program_id
FROM FND_REQUEST_SET_PROGRAMS
WHERE request_set_id =
(SELECT request_set_id
FROM FND_REQUEST_SETS_TL
WHERE upper(user_request_set_name) =
upper('&Request_Set_Name')));
Posted by Elangovan Ragavan at 20:30 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: concurrent program
TUESDAY, 17 APRIL 2012
concurrent_program
/* Formatted on 2012/03/21 15:23 (Formatter Plus v4.8.8) */
SELECT r.ROWID row_id, r.request_id, r.phase_code, r.status_code,
DECODE (r.status_code,
'A', ' Waiting A',
'B', 'Resuming B',
'C', 'Normal C',
'D', 'Cancelled D',
'E', 'Error E',
'F', 'Scheduled F',
'G', 'Warning G',
'H', 'On Hold H',
'I', 'Normal I',
'M', 'No Manager M',
'Q', 'Standby Q',
'R', 'Normal R',
'S', 'Suspended S',
'T', 'Terminating T',
'U', 'Disabled U',
'W', 'Paused W',
'X', 'Terminated X',
'Z', 'Waiting Z'
) status_code_name,
r.priority_request_id, r.priority, r.request_date, r.requested_by,
r.requested_start_date, r.hold_flag, r.has_sub_request,
r.is_sub_request, r.update_protected, r.queue_method_code,
r.responsibility_application_id, r.responsibility_id,
r.save_output_flag, r.last_update_date, r.last_updated_by,
r.last_update_login, r.printer, r.print_style, r.parent_request_id,
r.controlling_manager, r.actual_start_date, r.actual_completion_date,
r.completion_text, r.argument_text, r.implicit_code, r.request_type,
r.program_application_id, r.concurrent_program_id,
pb.concurrent_program_name program_short_name,
pb.execution_method_code, pb.enabled_flag enabled,
DECODE (r.description,
NULL, pt.user_concurrent_program_name,
r.description || ' (' || pt.user_concurrent_program_name || ')'
) program,
pb.printer_name fcp_printer, pb.output_print_style fcp_print_style,
pb.required_style fcp_required_style, u.user_name requestor,
s.user_printer_style_name user_print_style, r.description description,
pt.user_concurrent_program_name user_concurrent_program_name
FROM fnd_concurrent_programs_tl pt,
fnd_concurrent_programs pb,
fnd_user u,
fnd_printer_styles_tl s,
fnd_concurrent_requests r
WHERE pb.application_id = r.program_application_id
AND pb.concurrent_program_id = r.concurrent_program_id