Functionality Changes to Value Sets Introduced in 11i.ATG_PF.H Rollup 4

January 15th, 2007 |   Send this article to a friend!

The latest Oracle Applications Technology rollup patch released in November 2006 introduces a multitude of fixes and enhancements to core ATG modules (FND, OAM, OWF, FWK, JTT, JTA, TXK, XDO, ECX, EC, AK, ALR, and UMX).  The most notable, according to Metalink note 365228.1, are the enhancements to document attachments, Personalizations, and Workflow.

ATG Rollup 4

 

However, I discovered that after the application of Rollup 4 that the behavior of some of my custom value sets had changed.  Any table-validated value sets that make any form field references, such as :BLOCK.FIELD, were no longer functional.  This was quite a painful discovery for me as I had many value sets that were dependent upon this functionality.

According to several posts on Metalink, other clients had discovered this issue as well but on dates just prior to the release of 11i.ATG_PF.H Rollup 4.  So this may have been caused by a one-off patch that was introduced earlier but later included in the Rollup 4 package.

The ability to use :BLOCK.FIELD references in table-validated value sets was removed by Oracle development because this feature isn’t consistent with the future direction of Oracle applications.  Rumor has it that in the somewhat near future the application will be entirely HTML based and will be gradually introduced as Oracle works towards its full release of Fusion products.  While their intentions to remove

this functionality were good (I guess), this doesn’t help people like me who have already delivered solutions using this functionality and now have to come up with another approach.

But thankfully there’s a work-around.  Although :BLOCK.FIELD references cannot be used, the use of :$FLEX$.SEGMENT is still available.  So instead of referring directly to the form field value, you can create another hidden flexfield segment that has a default type of “Field”.  Then you can specify a default value of :BLOCK.FIELD.  Once you’ve created the segment you can alter your value set criteria to refer to the :$FLEX$.SEGMENT which will have the :BLOCK.FIELD value defaulted.

Although it’s not as easy as making direct references to the form field itself, I’ve been able to successfully implement this work-around.  The downside of course is that you’re using up more of those valuable descriptive flexfield segments.  But it’s either that or the Oracle recommended approach….which is to refrain from using field references entirely.


Mr. Thompson is a Senior Oracle Applications Consultant with Lexerd Group Consulting. Visit www.LexerdGroup.com to find out more about our firm.

Interested in hosting your own blog? Lexerd Group’s Internet Services division provides specialized blog hosting services that utilizes the Wordpress blogging platform. Visit http://www.lexerdgroup.com/blog-yourself/ for more details.

Entry Filed under: General, Technical

2 Comments Add your own

  • 1. Donna Armstrong  |  October 15th, 2007 at 6:33 pm

    Bryan,

    Is there any way to get around the issue of different forms using different block names for the same table? Can I use the same hidden DFF approach to copy a field into a DFF using only the field name without the block name?

    I have a DFF on po_lines. . .on one form the block is po_lines. On another it is lines_folder. . .

    any ideas?

    Thanks,

    Donna

  • 2. Vagelis Fotias  |  November 26th, 2008 at 3:40 am

    Bryan
    Is there any document that i can write down the setup steps of Forms Personilization?

    Thanks
    Vagelis

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed  |  Send To a Friend


Most Recent Posts