OAF - Difference between jdevW.exe, jdev.exe and jdeveloper.exe

When we unzip Jdev 10g with OA extension, it creates three folders viz.
1. jdevbin : Contains necessary executables
2. jdevdoc : Contains documentation inlcuding OAF developer's guide
3. jdevhome : Folder where you can keep your project related files

There are three types for executables available:
1. jdeveloper.exe : When we open "jdevbin" folder, we find this executable and other subfolders.
2. jdev.exe : When we open "jdevbin\jdev\bin", we find this executable
3. jdevW.exe : When we open "jdevbin\jdev\bin", we find this executable

Now, if we are working in Windows, you can use either of these three(Reference: "Oracle JDeveloper (10.1.3.3.0) Installation Guide"). There is no difference at all. Difference between "jdevW.exe", "jdeveloper.exe" and "jdev.exe" is that, "jdev.exe" will display console window for internal diagnostic information.

Generally, when we refer to any standard documentation of OAF, they usually refer to use "jdevW.exe", but we can also use "jdeveloper.exe" also. Both are same.

OAF - autoCustomizationCriteria, "Developer Mode Error: Stale Data" error

When we run search page which is based upon auto customization criteria search method, we might get below error:

This error is caused by setting values for properties viz. View Instance and View Attribute(BC4J) for items inside CustomSimpleSearchPanel. Please see below item "SearchEmpName" and "SearchEmpNo":

Please remove these two values from both items and run your page. It should work fine.

Query to connect Party, Sales Order/line and csi_batch_txn_lines & csi_txn_errors table

SELECT hp.party_number p_num
      ,ooh.order_number ord
      ,ooh.flow_status_code o_stat
      ,ool.line_number || '.' || ool.shipment_number ||
       decode(ool.option_number
             ,NULL
             ,NULL
             ,'.') || ool.option_number line_no
      ,ool.ordered_item item
      ,ctl.batch_id
      ,ctl.order_line_id
      ,ctl.processed_flag
      ,cte.error_text
FROM   hz_parties           hp
      ,hz_cust_accounts     hca
      ,oe_order_headers_all ooh
      ,oe_order_lines_all   ool
      ,csi_batch_txn_lines  ctl
      ,csi_txn_errors       cte
WHERE  hp.party_id = hca.party_id
AND    hca.cust_account_id = ooh.sold_to_org_id
AND    ooh.header_id = ool.header_id
AND    ool.line_id = ctl.order_line_id(+)
AND    ctl.order_line_id = cte.source_id(+)
AND    hp.party_number IN ('123')
ORDER  BY hp.party_id DESC
         ,ooh.order_number DESC
         ,ool.line_number
         ,ool.shipment_number
         ,NVL(ool.option_number
             ,0);

Note: Please do not join csi_batch_txn_lines.order_header_id(or order_line_id) with csi_txn_errors.source_header_ref%(or source_line_ref%) column as there are certain errors in csi_txn_lines table which only populates source_id and not any of the source_header_ref% or souce_line_ref% fields. So, its best to join csi_batch_txn_lines.order_line_id with csi_txn_errors.souce_id.

Install Base - CSI_BATCH_TXN_LINES and CSI_TXN_ERRORS out of sync

Sales Order lines workflow has 'FULFILL_LINE' activity which help interface sales order lines to install base. This process inserts records into CSI_BATCH_TXN_LINES table with processed_flag as '0'. Concurrent Program "IB TRANSACTION LINES IMPORT" picks up record from this table and then invoke worker program "IB TRANSACTION LINES IMPORT Worker". Whenever an error is encountered, processed_flag gets updated to '4' in CSI_BATCH_TXN_LINES table and a new record gets inserted into CSI_TXN_ERRORS table.

Now, when we rectify the error and then resubmit error record by navigating to responsibility 'Oracle Install Base Admin', Transaction Errors Processing form, after successful processing of the struck record, it deletes record from CSI_TXN_ERRORS table and does not do anything(update/delete) to corresponding record/s in CSI_BATCH_TXN_LINES table. So, when technical consultants view CSI_BATCH_TXN_LINES table and see that processed_flag = '4' exists, they think that this is error record which is not true as record have already been processed as explained above. This is a standard Oracle Bug which is still under Enhancement Request.