Launch workflow from PLSQL.

This procedure can be used to launch workflow from PLSQL.

PROCEDURE start_training_wf(p_po_id IN INTEGER) IS

    l_itemtype VARCHAR2(30) := 'XXXXPTR';

    l_itemkey  VARCHAR2(300) := 'TRAINING-' || p_po_id;

    CURSOR c_get IS

      SELECT *

      FROM   po_headers

      WHERE  po_id = p_po_id;

    p_get c_get%ROWTYPE;

  BEGIN

    OPEN c_get;

    FETCH c_get

      INTO p_get;

    CLOSE c_get;

    wf_engine.createprocess(l_itemtype, l_itemkey, 'MAIN_TRAINING_PROCESS');

 

    wf_engine.setitemuserkey(itemtype => l_itemtype

                            ,itemkey  => l_itemkey

                            ,userkey  => 'USERKEY: ' || l_itemkey);

    wf_engine.setitemowner(itemtype => l_itemtype

                          ,itemkey  => l_itemkey

                          ,owner    => 'SYSADMIN');

 

    wf_engine.setitemattrnumber(itemtype => l_itemtype

                               ,itemkey  => l_itemkey

                               ,aname    => 'PO_ID'

                               ,avalue   => p_po_id);

    wf_engine.setitemattrtext(itemtype => l_itemtype

                             ,itemkey  => l_itemkey

                             ,aname    => 'SEND_TO_EMAIL'

                             ,avalue   => p_get.send_email_to);

    wf_engine.setitemattrtext(itemtype => l_itemtype

                             ,itemkey  => l_itemkey

                             ,aname    => 'PO_DESCRIPTION'

                             ,avalue   => p_get.po_description);

    wf_engine.startprocess(l_itemtype, l_itemkey);

 

  END start_training_wf;

Checking Devices on a network

To find all connected devices on a network try arp -a from windows and arp -e in unix.

Workflow Language Setting

SELECT
    L.NLS_LANGUAGE ||'_'|| L.NLS_TERRITORY ||'.'||NLS_CODESET NLS_LANG_CODE,
    L.NLS_CODESET NLS_CODESET,
    L.LANGUAGE_CODE CODE,
    LTL.DESCRIPTION DISPLAY_NAME,
    L.NLS_LANGUAGE NLS_LANGUAGE,
    L.NLS_TERRITORY NLS_TERRITORY,
    L.NLS_CODESET NLS_CODESET,
    DECODE(INSTALLED_FLAG, 'B', 'Y', 'I', 'Y', 'N') INSTALLED_FLAG
  FROM
    FND_LANGUAGES L,
    FND_LANGUAGES_TL LTL
  WHERE
    LTL.LANGUAGE_CODE = L.LANGUAGE_CODE
    and DECODE(INSTALLED_FLAG, 'B', 'Y', 'I', 'Y', 'N') = 'Y';
1. Define NLS_LANG Environment Variable on your PC, following below navigation:
For Windows
Start / Settings / Control Panel / System / Advanced / Environment Variables
Define new "System Variable" NLS_LANG and assign it the value from NLS_LANG_CODE in he first step.
Save
NB : the above assumes language AMERICAN is installed in the database. It could be replaced by any other installed language, for instance FRENCH_FRANCE.WE8MSWIN1252 if French has been installed.

2. Re-start the PC as needed.

3. Try again database connection from the Workflow Builder.

OAF bouncing for changes

To bounce the apps to show changes for OAF you will have to do the following:

R12:

1)adapcctl.sh stop

2)adoacorectl.sh stop

3)adoacorectl.sh start

4)adapcctl.sh start

R11

1)adapcctl.sh stop

2)adapcctl.sh start

All these scripts are in $ADMIN_SCRIPTS_HOME

or $COMMON_TOP/admin/scripts

R12 on IE10

Just Starting to useIE10 on Windows 8 and it is throwing up some interesting items for R12.1.3. Looks like compatability views are the only way to get it to work properly.

Without the compatability view everything is undefined. Beware when Microsoft releases IE10 on windows 7. We kow it will not be released for XP so a few people should be OK.

Chrome kind of works where you use an extension to change the user agent for the browser to another one.

Oracle Support Notes 1395050.1 for fusion apps and 285218.1 for eBusiness will show the recommended browsers.

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.