The audience for this note is someone with developer level knowledge.
The following tables can hold Sale In In creating Sales Order, temporary tables (aka Work File/Workfile/WF) such as F42UI01, F42UI11 and F42UI12 that can be used to hold data temporarily before it gets committed to Sales Order and Sales Detail files. For this example, workfile stands for physical tables whereas cache stands for memory or data structure.
The following tables can hold Sales Order Header and Detail as temporary repository:
The reason is to optimize performance and data integrity. For example, if a huge volume of data has to be handled, writing a temporary file can be more cost effective than making use of cache as physical memory which has its own limitation. The benefit of writing cache is by avoiding round trip to database server (because workfiles are sitting in database whereas cache is to be written to physical memory in logic server itself) from logic server but case study shows that the performance gain is not noticible.
This calculation assumes the keys and indices to a certain table is left unchanged. If keys or indices are changed, the cache should still work, however the following calculation will be off. Approximately 193K will be used by the cache that is non-data related. Plus, the size of memory will be equivalent to the size of data in a certain table. In Unicode and 2 bytes Asian language, it requires two bytes per character. That is why, the usage of memory in Unicode environment will be higher than single byte environment.
For example (based on E1 application release 9.1),
: Note that the size of data can be retrieved by checking F42UI01.h, F42UI11.h and F42UI12.h
Possible parameters:
Values for parameter:
It is important to know that how EnterpriseOne application makes use of MBF (Master Business Function) in the routine of Sales Order Process. This MBF can be called by multiple applications, hence a number of application can have different implementation on Cache and Workfile.
| Business Function | Purpose | Parameter | Target | Source | Default |
|---|---|---|---|---|---|
| F4211FSBeginDoc | This function validate Sales Order Header information and stores validated result into F42UI01 and F42UI02 | cCMUpdateWriteToWF | F42UI01, F42UI02 | 2 | |
| F4211FSEditLinePreProcess | This function validate part of data before Edit Line gets called and store it into F42UI12 | cUseCacheOrWF_EV01 | F42UI12 | 2 | |
| F4211FSEditLine | This function validate Sales Order Detail Information and stores it into F42UI11 | cCMWriteToWFFlag | F42UI11 | 2 | |
| F4211FSEndDoc | Commits transaction data stored in F42UI01, F42UI02, F42UI11 and F42UI12 | cCMUseWorkFiles |
F4201, F4211 |
F42UI01, F42UI02, F42UI11, F42UI12 | 2 |
Index used:
| File | Description | Index for Cache | Index for Workfile |
|---|---|---|---|
| F42UI01 | SO Header Cache File (MBF) | nKeyID = 1 ctid, jobs) nKeyID = 2 (ctid, peid, tcid, an8, mcu, crcd, shan) |
ID_F42UI01_COMPUTERID__JOB_NO ctid, jobs, doco, dcto, kcoo |
| F42UI02 | F42UI01 Header Cache Extension | Only Cache: ctid, jobs |
Not physical file |
| F42UI11 | SO Detail Cache File (MBF) | ctid, jobs, lnix, doco, dcto, kcoo, lnid | same with cache |
| F42UI12 | Sales Order Detail Cache 2 (MBF) | same with F42UI12 | same with cache F42UI12 |
Example of code in B4200310.c:
Example of code in B4200311.c:
Yes the data from these work file tables (F42UI01, F42UI11 and F42UI12) can be purged.
In general, these files are made up of columns:
Each user per application has unique key for above members the value populated in work file will be transaction specific.
In deleting data from these tables the best option will be :
Do not change any parameters as it will cause memory error across system and you may experience slower performance.
If there is any change in Table Structure, the table needs to be generated through EnterpriseOne OMW tools. Usually this has to be described in Special Instruction of baseline ESU that has been installed. By generating table which synchronize table specification in your Database (Update metadata in your DB), this action is MANDATORY.
In the log, there is cache written in F42UI002 but we cannot find this table. Is this a valid table ID? If so where can we find it?
Currently whether to write WORKFILE or CACHE is to be inherited by calling routine (F4211FSBeginDoc and F4211FSEditLine). In creating sales order through UBE (R47011 - EDI Inbound Purchase Order Edit/Create) which writes a physical table F40UI74 whereas in creating sales order through P4210/P42101 (Sales Order Entry) it writes workfile F40UI74. This is to guarantee the best performance by storing flag (cPriceHistoryCacheFlag ) in datamap of shared memory area (DATAMAPCDIST). For this example, parameter in datamap is same with cCMWriteToWFFlag (2 - write cache, 1 - write workfile) and B4504590 - SetPricingHistoryCacheFlag has it's implementation.
In case you need to write the table F40UI74 through interactive SOE P4210, possibly,
(event rule) In calling 'F4211 Begin Doc' and 'F4211 Edit Line' set cCMWriteToWFFlag '1' in P4210
(business function) Or assign '1' for dsSetPricingHistoryCacheFlag.cPriceHistoryCacheFlag in B4200311 before it calls SetPricingHistoryCacheFlag
CAUTION: DO NOT CHANGE existing configuration because which affects performance significantly.
Refer to <Document 1374201.1> E1: 42: B4504590 - Pricing Datamap Function and Cache and Workfile.
List of Workfiles in EnterpriseOne Distribution and Manufacturing can be found at <Document 1376252.1> E1: 40: Workfiles in Distribution and Manufacturing. Note that whether to use cache or workfile is unique feature of sales order processing and this does not applies to other routine. For example, R42565 (Print Invoice) makes use of Work File (F42565) but there is no way to make use of this as cache.
Inc case the size of table F42UI01, F42UI11 and F42UI12 grow check batch applications you are running and check whether it leaves any data in these tables. From DBA (Database Administrator), truncate these tables regular basis (or all workfiles) to prevent unnecessary growth of table usage.
Disclaimer: Oracle will not be responsible for the changes made to standard programs due to this implementation and Oracle will not maintain any of these custom changes or be responsible for any problems arising from these changes.