everywhere: 3月 2012

2012年3月12日星期一

workflow administration 裡面的 download location 值不正確

## Oracle ERP路徑:

1. Navigation Path : Workflow Administrator Web (New) > Administration > Workflow Configuration
2. In Region of JInitiator, Download Location is : http://terp01.nbwde.com.cn:8001/OA_HTML/oajinit.exe

## 問題描述:

The workflow configuration page shows the JInitiator download location is:
http://terp01.nbwde.com.cn:8001/OA_HTML/oajinit.exe

這是不正確的

## 檢查過程:

Checking WF_RESOURCES shows:
WF_PLUGIN_DOWNLOAD - http://terp01.nbwde.com.cn:8001/OA_HTML/oajinit.exe

其實這台server的8001 port 並沒有服務

JInitiator can be downloaded from forms without problem as there is no reference to the wrong server in the context file or the forms configuration.

## 參考資料:

Cannot Configure Global Preferences Since Jinitiator Preferences Do Not Exist For WF 11i (Doc ID 220212.1)

The note explains :
WF_RESOURCES table is populated with JInitiator information from appsweb.cfg ($FORMS60_WEB_CONFIG_FILE).
If the values are incorrect, please manually update appsweb.cfg and/or WF_RESOURCES table with the correct values.

appsweb.cfg and wf_resources 的值應該要相同，如果不同，要手動修正，使之相同

##　檢查參數 appsweb.cfg:

The value of parameter sun_plugin_url in file $FORMS60_WEB_CONFIG_FILE is correct.
=> /appl/prodcomn/html/bin/appsweb_PROD_perpap1.cfg

=> sun_plugin_url=http://perpap.cmo.com.tw:80/OA_HTML/oajinit.exe

這是正確的

## 檢查XML file

vi $APPL_TOP/admin/*.xml

也是正確的

## 檢查 table wf_resources:

select substr(name,0,18) Name, substr(text,0,55) Value
from wf_resources
where name in
('WF_WEB_AGENT',
'WF_ADMIN_ROLE',
'WF_VERSION',
'WF_CLASSID',
'WF_PLUGIN_DOWNLOAD',
'WF_PLUGIN_VERSION');

發現wf_resources真的有terp01未被更改的值

## 解決方式:

1. 備份:

create table apps.wf_resources_20120305_bak as
select * from wf_resources;

2. 更正:

update applsys.wf_resources
set text = 'http://perpap.cmo.com.tw:80/pls/PROD'
where name = 'WF_WEB_AGENT';

update applsys.wf_resources
set text = 'http://perpap.cmo.com.tw:80/OA_HTML/oajinit.exe'
where name = 'WF_PLUGIN_DOWNLOAD';

commit;

## 解釋:

1. Function of JInitiator Download Location :
http://docs.oracle.com/cd/B25284_01/current/acrobat/115wfag.pdf
Page 40:
Oracle Workflow uses JInitiator to launch Oracle Applications forms linked to notifications.

That's to say this url will be used when end user access form function via workflow notification.

只有當user收到的wf notification如果有link到form需要開啟的話，才會引用到這個參數。

2. The workflow administrator role, LDAP, local system, and JInitiator information is saved to the Oracle Workflow resources table.

Jinitiator資訊儲存在wf_resources table中。

3. The answer to your question is to manually update wf_resources against the incorrect parameter value

解決方式是update wf_resources 的值成為正確的值。

2012年3月8日星期四

Table MRP.MRP_RELIEF_INTERFACE too large

metalink參考:

Max_Extents Reached For Table MRP.MRP_RELIEF_INTERFACE [ID 214726.1]

		Modified 31-OCT-2002 Type PROBLEM Status PUBLISHED


fact: Materials Requirement Planning 11.5

symptom: Max_Extents reached for table MRP.MRP_RELIEF_INTERFACE

symptom: Not using MRP Planning in 11i

symptom: Not using Forecasts, MDS, MPS, or MRP

symptom: Planning Manager is not running

symptom: Rows are continually added to MRP_RELIEF_INTERFACE

cause: The functions that cleanse the table are not being run.



fix:

The table can be safely truncated to save space.
This will have to be a regular DBA responsibility since we cannot keep the 
table from being updated.
OR
 1. Upgrade your code to 11.5.7 or higher
 2. Profile MRP: Planning Manager First time should be present
 3. Profile MRP:Interface Table History Days = 0
 4. Run the Planning Manager regularly
THEN
 This table will automatically be cleansed when these conditions are met.

Related

Products

More Applications > Value Chain Planning > Supply Chain Planning > Oracle Materials Requirement Planning

另外可以參考:

Article-ID:         Note 148706.1

Alias:              SOL:OSS3001

Circulation:        PUBLISHED (LIMITED)

Folder:             EBS.Mfg.MRPPlanning

Topic:              MPS_MPS: Master Production Schedule

Title:              Table MRP_RELIEF_INTERFACE Is Growing Very Large

Document-Type:      PROBLEM

Impact:             MEDIUM

Skill-Level:        NOVICE

Updated-Date:       20-AUG-2003 19:27:10

References:

Authors:            LERIKSON.US

Attachments:        NONE

Content-Type:       TEXT/X-HTML

Products:           574/MPS (10.7);

Platforms:          0;

@ This article has been replicated from the Primus repository

·                fact: Materials Requirement Planning

·

·                fact: MRP_RELIEF_INTERFACE

·

·                symptom: Table is growing very large

·

·                symptom: MPS is not being used

·

·                cause: MPS relief entries are created every time a PO or discrete Job is

·                created.

·                Since the MPS is not being used, and the profile option, MRP: Consume MPS is

·                set to NO, The MPS relief entries are never getting purged from the

·                MRP_RELIEF_INTERFACE table.

·                Bug 1487243.

·

·

fix:

There are two ways to clean up the records in the MRP_RELIEF_INTERFACE.

1.  If using the MDS Relief [or MPS Relief] but it is turned off for some

reason, then turn it on using the profile MRP: Consume MDS [or MRP: Consume MPS]

.  This ensures that the Planning Manager, in its next run, would process all

these records. The daily cleanup worker of the Planning Manager would then

clear up these records, thereby cleaning up MRP_RELIEF_INTERFACE.

If profile options Consume MDS/MPS are changed,  then restart the Planning

Manager to activate the new profile option setting.

2)  If not using the MDS Relief [or MPS Relief],  then manually delete these

rows from the MRP_RELIEF_INTERFACE using the following SQL:

Delete from MRP_RELIEF_INTERFACE where relief_type = 1;

Delete from MRP_RELIEF_INTERFACE where relief_type = 2;

2012年3月7日星期三

Discoverer資料多,欄位多,匯出到Excel變慢

Discoverer Plus 10.1.2.3 Excel Export On Wide Worksheet With 40 Columns Takes More Than One Hour To Export [ID 1293559.1]

		Modified 09-FEB-2011 Type PROBLEM Status MODERATED

In this Document
  Symptoms
  Cause
  Solution
  References

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

Applies to:

Oracle Discoverer - Version: 10.1.2.3 and later [Release: 10.1.2 and later ]
Information in this document applies to any platform.

Symptoms

When using Discoverer Plus 10.1.2.55.26 with Cumulative Patch (CP) 7, Excel export of a worksheet
with many columns is taking over one hour to complete.

This crosstab worksheet includes 40 columns and over 11,000 records.

If the worksheet is exported from Desktop, it completes in a few minutes.
It is only when exporting to Excel from Discoverer Plus, that it takes over an hour.

If the worksheet is exported to CSV, it only takes a few minutes.

Cause

Workbook design not well suited for Discoverer Excel export.

Discoverer Plus/Viewer worksheets are intended for high level views of data that can fit within
a standard web page.
Any time, you start to exceed 13 - 15 columns in width, you may notice performance degradation in
rendering pages and especially when exporting to Excel.

When a workbook is exported to Excel, Discoverer needs to format each cell in the Excel spread sheet
and when the workbook has thousands of rows or many columns, it takes that much longer to format
each cell.

Solution

Ideally, the worksheet should be redesigned to limit the number of columns to no more than 12 - 15.
If this is not possible, the following workarounds may be used to export the worksheet without experiencing a performance impact.

Use Discoverer Plus to Export wide workbook to CSV format and then open resultant .CSV file in Excel.
When Excel export is desired, run workbook in Discoverer Desktop and then export to Excel.

Discoverer Desktop involves a single network protocol (SQL*Net) and a connection between the Desktop (PC)
and the database (client server architecture).
Any activity (running workbooks or exporting) is usually faster in a client/server environment than in a web server environment.
You may also be able to achieve a performance gain by applying Discoverer Cumulative Patch 8. This patch introduced a new pref.txt file setting which may improve performance of Discoverer exports to Excel.

Patch 9694503, CUMULATIVE PATCH 8 : MLR ON TOP OF 10.1.2.3 FOR BUG 9112482 + NEW BUG FIXES

After applying patch as described, please make a back-up copy of the pref.txt file and then add the following setting to the original file under the "Application" heading:

ExcelExportWithMacros=0

Save changes and run "applypreferences.sh" file.

References

PATCH:9694503 - CUMULATIVE PATCH 8 : MLR ON TOP OF 10.1.2.3 FOR BUG 9112482 + NEW BUG FIXES