Tuesday, November 13, 2012

Oracle Executables Explained - Part 3 - Oracle Concurrent Program

Concurrent Program

I did write this earlier on the month, but lost it during a computer crash and put a bit too much faith in the cloud. Looks like it was a cloudless day!

In terms of executables, this screen is used to define the concurrent program that the end user sees when they run the program. Some information comes from the second posting in relation to the eexecutables.



We have the program name, which is what the user sees. The application is the concurrent program's host application and relates to the application must suited to the request.

The executable links to the executable that was registered in the earlier step. Other information will default from the setup in the executable. The request section of the screen will determine if the request can be submittted by concurrent request screen or whether it is a standalone program. The NLS selection shows whether the program is language compliant.

The printing section relates to the style of printing that is related to the concurrent program. This is related to whether or not the program requires extra wide space (ie Landwide) or normal style (landscape, portrait). The number of lines

concurrent program parameters



Incompatible Programs
This contains programs that YOU DO NOT WANT TO RUN AGAINST YOUR PROGRAM. For example you may not want to run a program that could lock the same tables as you are accessing and end up in a deadlock situation or just trying to hit a table hard.



Oracle Executables Explained - Part 2 - the Oracle Executable

I have already spoken about the technical components of an executable such as the changes around the server and sql side. This entry is going to be more around the functional setup required for the process. How, though does Oracle see the program and allow the end user to make the most of it?

The first step is to register the program within the concurrent program executable definition screen which is in the Application developer responsibility.  This screen (as shown below) will allow for the executable to be visible within Oracle.



in the screen above the key fields are the Execution Method (which should match the form of the code on the server be it an oracle form, pl sql, package) , the execution file name (which should match the name of the file on the server) and the application (which should match the name of the application that the file/package etc is stored on). For example if your code was on the $GL_TOP directory on your server, the application would be General Ledger. The naming is critical as to whether or not the code will be found and executed!

The next part will be to register the actual concurrent program, complete with the parameters. This is the component which has the most visibility to the outside world in that it is what they will see when they run the file. However, it also contains additional information including the print style etc that is of little use to users but can potentially impact on the program. That whole application process will be the next post.




Oracle Executables Explained - Part 1, on the server

I have had a question been asked recently to explain to the layperson how oracle executables work.

The idea of Oracle customisations is simple. Place the customised file on the server and then hit the submit request and viola the process is executed! However, what exactly does this mean? A lot of apps users just see the magic of their customised process without a clear understanding of how it all goes together.

The first step is to determine what type of program is been sought to be customised as this will determine some of the treatment on the server side. This can take the form of a Report, Sql, Package, java or xml. These customisations can take parameters from the request submission screen and execute a program.

The first section is the creation of the customisation. If the customisation is a unix shell script, this is usually put in a $CUST_TOP/bin directory, where CUST_TOP is a certain directory as determined by an application setup within the Application developer (N:Application Developer --> Application --> Register).

The bin is to show that it should be a shell script or other executable. The executable then needs to be set to be executable through the chmod command. Oracle also requires the creation of a symbolic link through the command

ln -s $FND_TOP/bin/fndcpesr CUSTOM_PROGRAM_NAME

this command will make the unix shell script an executable that Oracle can handle. The shell script usually requires this additional work in relation to making it executable and usable with Oracle. 

Other customisations are as simple as placing them in the relevant directory depending on their type.

SQL scripts will be put in the $CUST_TOP/sql directory.
Packages can be installed into Oracle and executed as a concurrent program without having to be placed in the relevant directories and can be installed from a sql plus session, by executing the sql file.
A report on the other hand should go into the $CUST_TOP/reports/US directory.

The next step which will be explained is to setup the application within the Oracle Application itself.