OAF FlexField中数据库与页面的前后台数据类型转换

OAF FlexField中数据库与页面的前后台数据类型转换

 

Oracle Application中有FlexField（弹性域）这个东西。在FlexField tables，数据存放于VARCHAR2类型的一列或多列中。不论是数字、日期、文本等，最终都会以VARCHAR2存放在table中。在OA Page中，这些VARCHAR2一般需要使用相对应的格式，比如日期、数字，以使用相应的验证机制，或者根据不同的地区转换成不同的格式。问题是，怎样在前后台中做数据类型转换呢？一个最简单的办法是使用OAF的FlexField Bean。但在一些情况下，使用FlexField Bean反而会不方便控制。甚或乎，明明跟随了OAF Developer Guide的方法，但总是用不了这个FlexField Bean。这时，只能手工地做这件事情了。

数据类型转换的基本原理很简单：把读写分离，或者说把前后台不同方向的数据流分开处理。

 

1. 传统情况

所谓传统情况，或者一般情况，就是数据库的列名是有实际意义的、明确的。比如，列名是EFFECTIVE_DATE，EO、VO中的属性名也会使用EffectiveDate。

我们会在VO中定义一个SQL语句。当进行操作时，OAF会把这个SQL语句封装，然后进行读写。比如：

[sql] 
SELECT   ExampleEO.example_id AS EXAMPLE_ID  
       , ExampleEO.effective_date AS EFFECTIVE_DATE  
       , ExampleEO.employee_name AS EMPLOYEE_NAME  
FROM   ExampleEO  
WHERE  ExampleEO.example_id > 10    
当查询example_id = 100的记录，OAF会封装成这样子：
[sql] 
SELECT *  
FROM   (SELECT   ExampleEO.example_id AS EXAMPLE_ID  
               , ExampleEO.effective_date AS EFFECTIVE_DATE  
               , ExampleEO.employee_name AS EMPLOYEE_NAME  
        FROM   ExampleEO  
        WHERE  ExampleEO.example_id > 10) QRSLT  
WHERE  QRSLT.EXAMPLE_ID = 100  

插入的时候也是类似的：
[sql] 
UPDATE (SELECT   ExampleEO.example_id AS EXAMPLE_ID  
               , ExampleEO.effective_date AS EFFECTIVE_DATE  
               , ExampleEO.employee_name AS EMPLOYEE_NAME  
        FROM   ExampleEO  
        WHERE  ExampleEO.example_id > 10) QRSLT  
SET      QRSLT.EFFECTIVE_DATE = <effective_date>          -- OK  
       , QRSLT.EMPLOYEE_NAME = <employee_name>            -- OK  
WHERE  QRSLT.EXAMPLE_ID = 100  

 

总的来说，是将VO中的SQL语句封装成表格，然后外面包裹相应的操作。

 

2. FlexField的问题

而在FlexField的情况，列名是没有实际意义，或者说不明确的。FlexField存放数据的列名一般是ORG_INFORMATION1、PER_INFORMATION5之类。在VO中，这些名字可能会被替换为实际的用途，比如说ORG_INFORMATION1可能是一个Effective Date，那么在VO中的属性就会被命名为EffectiveDate。这个的mapping是在VO properties中设置的。

为了简化列名，本文把ORG_INFORMATION1、PER_ATTRIBUTE1等统称为information1。于是，在一个FlexField表格，VO的语句会是这个样子：

[sql] 
SELECT   ExampleEO.example_id AS EXAMPLE_ID  
       , ExampleEO.information1 AS EFFECTIVE_DATE  
       , ExampleEO.information2 AS EMPLOYEE_NAME  
FROM   ExampleEO  
WHERE  ExampleEO.example_id > 10    
查询example_id = 100的记录，会生成以下的语句：
[sql] 
SELECT *  
FROM   (SELECT   ExampleEO.example_id AS EXAMPLE_ID  
               , ExampleEO.information1 AS EFFECTIVE_DATE       -- information1 is a VARCHAR2  
               , ExampleEO.information2 AS EMPLOYEE_NAME  
        FROM   ExampleEO  
        WHERE  ExampleEO.example_id > 10) QRSLT  
WHERE  QRSLT.EXAMPLE_ID = 100  

 

 

查询语句本身没有问题。但是在OA Page中，显示日期的item所属的类型一般会设成DATE，而上面的SQL语句查询结果的类型是VARCHAR2。于是，VO与PG上的的属性类型不管如何设置，都会在页面上方报错。此乃问题一。

 

当进行插入操作，OAF会生成以下的SQL语句：

[sql] 
UPDATE (SELECT   ExampleEO.example_id AS EXAMPLE_ID  
               , ExampleEO.information1 AS EFFECTIVE_DATE     -- VARCHAR2  
               , ExampleEO.information2 AS EMPLOYEE_NAME  
        FROM   ExampleEO  
        WHERE  ExampleEO.example_id > 10) QRSLT  
SET      QRSLT.EFFECTIVE_DATE = <effective_date>              -- Error  
       , QRSLT.EMPLOYEE_NAME  = <employee_name>               -- OK  
WHERE  QRSLT.EMPLOYEE_ID = 100  

 

 

在FlexField table中，information的类型是VARCHAR2，而effective_date的类型是DATE。类型的不匹配，就会引起错误，转到异常页。此乃问题二。

 

3. 从数据库到页面 (Table -> Page，从后台到前台）

为了解决这个问题，我们可以为每个在OA Page上非字符类型的属性，在VO中定义一个相应类型的transient属性。以transient属性作为中间媒介，在不同的地方调用转换函数，从而在前后台进行数据类型转换。

对于上面的例子，我们可以在VO中定义一个名为DispEffectiveDate的属性。这个属性数据类型设为DATE，Updatable设为always。由于这个属性没有映射到表格中的列，所以这也是一个Transient的属性。数据类型转换，则是在属性calculation的那一项，调用数据库的PL/SQL过程，进行从VARCHAR2到DATE的转换。最终，在VO的SQL中生成了以下的SQL语句（也可以使用Expert Mode进行编辑）：

[sql] 
SELECT   ExampleEO.example_id AS EXAMPLE_ID  
       , ExampleEO.information1 AS EFFECTIVE_DATE  
       , ExampleEO.information2 AS EMPLOYEE_NAME  
       , FND_DATE.CANONICAL_TO_DATE(ExampleEO.information1) AS DISP_EFFECTIVE_DATE     -- Invoking data type conversion procedure here  
FROM   ExampleEO  
WHERE  ExampleEO.example_id > 10    

 

其中，FND_DATE.CANONICAL_TO_DATE是Oracle自带的函数。这个函数把格式为'YYYY-MM-DD HH:MI:SS'的标准日期字符串（这种字符串也是Oracle FlexField使用字符串保存日期的标准格式），转换成Oracle数据库的Date类型。

而在OA Page上，显示的item中的View Attribute属性，只需要选择上述的DispEffectiveDate，则可以正常地显示出来了。有关日期的验证也可以如常使用。

 

小结：在VO的SQL中插入一个PL/SQL函数调用，把VARCHAR2类型的变量转换为DATE类型。在页面中则选择被转换后的VO属性。

 

4. 从页面保存到数据库（Page -> Table，从前台到后台）

把页面上的日期保存为标准日期字符串，方法也是类似的。唯一不同的地方是调用转换函数的地方。

在描述怎么转换之前，我们需要知道一点：在用户填写好表单，按提交按钮后，OAF首先会调用VORowImpl相应的setter方法，之后才会调用用户定义CO的ProcessFormRequest （PFR）函数。如果将数据类型转换函数放在AM或VOImpl中（这些转换函数使用setter来设置数据库中的值），在CO中用invokeMethod来调用它们，即使这些转换函数包含了异常的处理，假若用户如果再按多一次按钮，表单也会跳到成功的DialogPage（假设定义了DialogPage来提示成功）。

这个问题的原因是，OAF会在底层的某个地方调用ProcessFormData()函数。这个函数调用了一个名为setValue()的函数。在setValue()的函数中，首先会判定新值和旧值是否相等。如果相等，则会跳过所有的任务，直接返回。这样，写在VO或EO中的数据验证方法也不会被调用。这种新旧值相等的验证是写死在底层的代码中，开发者是无法设置的。

具体地说，假若业务上规定EffectiveDate的值不能在01-Jan-2000以前。当用户输入一个01-Jan-1999，第一次提交的时候，因为01-Jan-1999与null值不同，所以在setValue()会设置。而在设置的过程中，会进行验证，从而捕捉到异常。当用户马上按第二次提交，这时在VO中，DispEffectiveDate属性的值已是01-Jan-1999，和页面上的01-Jan-1999相同。所以setValue()不会再尝试设值，也不会做相应的验证，于是，非法的值就被保存了。

回到正题。刚才说到，OAF会先调用VORowImpl的setter方法。于是，数据类型转换可以写在VORowImpl方法中：

[java] 

public void setDispEffectiveDate(Date value)  

{  

    setEffectiveDate(dataTypeConversion(value));  

    setAttributeInternal(DISPEFFECTIVEDATE, value);  

}  

  

public void setEffectiveDate(String value)  

{  

    setAttributeInternal(EFFECTIVEDATE, value);  

}  

其中，dataTypeConversion()是一个自己写的函数，它的定义如下：

[java] 

private String dataTypeConversion(Date value)   

{  

    // convert data