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语句封装，然后进行读写。比如：

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会封装成这样子：

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

插入的时候也是类似的：

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的语句会是这个样子：

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的记录，会生成以下的语句：

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语句：

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进行编辑）：

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方法中：

public void setDispEffectiveDate(Date value)
{
    setEffectiveDate(dataTypeConversion(value));
    setAttributeInternal(DISPEFFECTIVEDATE, value);
}

public void setEffectiveDate(String value)
{
    setAttributeInternal(EFFECTIVEDATE, value);
}

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

private String dataTypeConversion(Date value) 
{
    // convert data type here

    return <return_value>;
}

通过上面的方法，在设置DispEffectiveDate的值的同时，相对应的EffectiveDate属性的值也会被设置。当多种类型需要转换，还可以利用多态，复用dataTypeConversion()函数。

这里还有一个小细节需要注意。setEffectiveDate()的调用必须放在setAttributeInternal()之前。原因是，当setEffectiveDate()抛出异常，程序不会执行下面那一句setAttributeInternal()。就是说，在VO中，DispEffectiveDate这个属性的值依然是null，没被设置。那么，当用户再次提交，setValue()就会再次设值，并且调用VORowImpl的setter函数了。

小结：在VORowImpl中，添加数据类型转换函数。然后在transient属性的setter中，先于setAttributeInternal()调用前，调用数据库相应列属性的setter，利用数据类型转换函数转换类型并设值。

5. 总结

在一般情况下，OAF都会生成漂亮的属性名和函数名，函数异常也会处理得很好。但是当需要手工处理FlexField时，这些事情就需要手工做。

如果说OAF生成的代码所使用的方法是读写共用一个SQL语句，那么我们手工实现转换的时候，就需要将读和写的处理分离。

在VO的SQL中调用一个PL/SQL函数进行转换，并把这个转换的返回值显示到页面上，此乃读法；在VORowImpl中添加Java转换函数，并在页面显示属性的setter中首先调用，此乃写法。

6. 补遗

a) 如果用户使用的不是EO based的VO，而是PL/SQL based，那么也可以在相应的PL/SQL package中，添加转换方法。

b) 关于程序异常处理，也是需要额外处理。在一般情况下，属性名在EO、VO中是统一的，而在FlexField中则不是如此。故此需要额外的处理。关于这个问题，会另外用文章说明。