The Triora Group

A short time ago, I was working on an upgrade and ran into a situation where this was needed. According to the patch readme, I needed to submit a concurrent request after applying a specific patch. So, to do this graphically, I needed to disable the maintenance mode and start up the application. Then I needed to login to the system, execute a specified responsibility, and then execute a concurrent request. Of course, it does not end there, because you have to wait until the request finishes before shutting down the system and re-enabling the maintenance mode. But, what are our other alternatives?

After reading this article, you should be able to submit concurrent requests via the command line, avoiding the need to log in to the applications at all. First, let me point you to the Metalink notes that I use as reference material. Knowing these notes always helps because they will present options that are beyond the scope of my description, as well as, hopefully, being updated should Oracle change the submission methodology. The first note, “How to Submit a Concurrent Request Using CONCSUB Syntax” is number 457519.1, while the second note, “Using the CONCSUB Utility”, is number 9611.1. Now that housekeeping homage has been paid, let’s get to the good stuff…

The utility we are using is named CONCSUB and is located in the $FND_TOP/bin directory. The actual name is upper case, which is noteworthy if you are working in a case sensitive environment such as Unix/Linux. The nice thing here is that sourcing your applmgr account should set the correct path to this utility. Take a quick look at your application environment file, <DBSID>_<HOST>.env, which is located in the $APPL_TOP directory. My file has the following entry:

PATH=”/u01/apps/oracle/testappl/fnd/11.5.0/bin:/u01/apps/oracle/testappl/ad/11.5.0/bin:/opt/java6/bin:${unzippath}:$forpath”

export PATH

What does this get us? First, the path is going to be managed by the APPLSYS_ux.env template via AutoConfig, so our applmgr user should always know where the utility is located. Secondly, we will not need to code the full path to the utility into the script. Now, before I get hammered, let me say that I have a tendency to use full paths in my scripts anyway, but you do have the option.

So, now we know we are going to use the CONCSUB utility for submitting the concurrent request. Let’s take a look at the syntax we are going to use. The following is an example from one of my recent upgrade scripts:

CONCSUB apps/<apps passwd> INV “Inventory_GL” SYSADMIN WAIT=N CONCURRENT INV INCIAR PROGRAM_NAME=’”Create Intercompany AR Invoices”‘ ‘”Test Client”‘ NULL

CONCSUB => name of the utility we are using for submission

apps/<apps passwd> => name of the apps account along with its password

INV => responsibility’s application short name

“Inventory_GL” => responsibility’s name

SYSADMIN => application login name

WAIT=Y => optional flag governing waiting (I’ll discuss later)

CONCURRENT => marker separating program from OS parameters

INV => program application short name

INCIAR => program short name

PROGRAM_NAME=’”Create Intercompany AR Invoices”‘ => user concurrent program name enclosed in double quotes and wrapped in single ticks

‘”Test Client”‘ => parameter 1 for program

NULL => parameter 2 for program

Cool… But, where do I get all of this info? I generally start with the name of the concurrent request, from the user’s perspective. In this case we want to run the “Create Intercompany AR Invoices” concurrent request. I can now log in to the system and navigate to the Concurrent => Program => Define screen and look up this report. This single screen will tell you most of what you will need. Here you will see the following values by looking in the associated fields:

Program => Create Intercompany AR Invoices

Short Name => INCIAR

Application => Inventory

This screen confirms that we have the program name, as searched for, in the “Program” field. We can also see the “Short Name” here. The next field on the form gives us the application name for the program, so here we are using the Inventory module of INV. If you don’t know how to look this up, take the “Application” value and plug it into the “Application” field on the Application => Register form. This will return the specified application’s short name. In our case we see INV.

At this point all we need to find out for the script above is parameter values, if any, we need to pass. To find this out we’ll need to navigate to the responsibility you will be running this report under. In our case above we used the Inventory_GL responsibility. After selecting that responsibility navigate to where that menu is able to launch a concurrent request. I don’t have a specific path for you here since many menus have different paths. But, in case you are trying to follow along with me, this menu had a “Requests” form listed on the opening screen. Selecting this menu object I was able to use the “Submit a New Request…” button located in the lower left corner of the form. Next I select the “Single Request” option which launches the standard concurrent request screen. Typing in the user program name I want to run got me the following screen:

Ahhhh, two parameters to deal with. For this first parameter, we can see we have a list of values to choose from, since we see that little eliptical box at the end of the field. Clicking it will give you the values permitted for this parameter. In my case I got the Test Client value. This value contains a space so you’ll need to enclose it in double quotes and then wrap that in single quotes. The next field did not contain a list of values for me to choose from, nor was a value supplied by the patch readme. Therefore, I left this value empty. However, since there is a field here I just passed it the NULL value just to be safe.

There are some additional parameters you will want to read and potentially use, as discussed in the MetaLink notes I referenced above. The bulk are the flags used for setting up when to run the report as well as if it should be a recurring request. You can also pass the interval between executions if it is a recurring request. That being said, I do want to cover two flags that I think are important. The first flag is the WAIT flag. This flag can be passed a “Y” or “N” for yes or no. This flag will tell the command whether to wait for the request to complete running or pass control back to the command line thus ending the script. As you would expect a “WAIT=Y” will wait for the report to run while a “WAIT=N” will hand control back over to the script and will run in the background. Personally, I like to use the “WAIT=Y” option so that I know how long the request takes to complete. This helps me plan my timings for upgrades. The other option I find interesting is the “IMPLICIT” option. I’m not going to go into great detail on this one as you can read more about it via the MetaLink notes above (hint hint hint…). In fact, I hate to throw out a teaser but maybe I’ll write next month’s article on use of this flag. Nice…. (for me any way…).

You should now know the MetaLink notes to look at; have a good example and depiction of CONCSUB usage as well as how to find the information needed for execution. Have I missed anything? Barb? Rob? John? Triora DBAs? I’d much rather ask now before getting hammered by our other bright folks for being a yutz…. Well, enjoy the little tip and let me know if you need any clarifications on this.

If you enjoyed this post, make sure you subscribe to my RSS feed!