Tuesday, May 24, 2016

Lessons Learned from Migrating to the 6.5.1 NoetixViews in an Oracle Applications 12.2 Environment

I received a copy of the 6.5.1 NoetixViews back in late March of this year. We needed to be on a version of the NoetixViews which will be certified with 12.2.5.

Right now we have completed our 2nd round of UAT and various things are still popping up.

Is there a big lesson learned from this migration?

We have lots of customizations (close to 200) with a lot of custom objects referenced. What I noticed is that my custom scripts (xu2 and xu5) that referenced custom objects needed to be properly referenced in the template tables (where applicable).

My convention up until the 6.5.1 NoetixViews with 12.2.5 Oracle Apps was to create a synonym in APPS and reference the object in n_view_table_templates through this synonym.  With 6.5.1, I just confirmed that the custom schema source was properly registered as an Oracle Application and then referenced the table directly from its schema.

This was my greatest pain point.

The different objects that are now associated with an Oracle Apps table (even a custom table owned by a registered schema) have ancillary objects as part of the edition based redefinition construct which is implemented with Oracle Applications 12.2.

Specifically, each table will have an edition based redefintion view owned in its schema and an APPS owned synonym.

Once the views are instantiated in the 12.2 EBS environment, they will then point at the edition based redefinition view associated with the table. This is true of both standard Oracle Apps tables and custom tables in registered Oracle Applications schemas.

With these new objects, the NVA will expect the Noetix admin database account to have grant select with grant option for all of the custom objects referenced in n_view_templates that are associated with the custom tables.


Last year I performed a 6.0.1 to 6.4.1 NoetixViews migration and this year I performed a 6.4.1 to a 6.5.1 NoetixView migration.  Because we are also upgrading Oracle Apps from 12.1.3 to 12.2.5 in this migration, personally, this was more work (and more risk).

2 comments:

  1. Thanks Patrick for sharing your experience! There are 2 points which captured my attention.

    1.APPS synonym usage - I do agree it's a good idea to leverage APPS synonym directly in the custom views, as you don't need to worry about the grants. One of the main reasons we wanted our customers to use the tables directly is to enable flexibility in security beyond the EBS. If based on the APPS synonym or view may conflict with Noetix security setup leading to inconsistent data results. Another flipside also is that it opens up APPS views to be used, which Oracle might change from release to release and customer may not have control over the data results because of such changes.

    Being said that, we could come up with best practices for such requirements in custom views...as the customer is responsible for the customizations and he/she should be fully aware of performance, granularity, security etc aspects.


    2. Upgrade risks - From the upgrade (EBS 12.1.3 -> 12.2.5) point of view, our utmost priority is that views are upgrade protected and reports do not have to be changed regardless of edition based redefinition change.

    It would be good to know the challenges other than the custom views related(remapping APPS synonyms to tables); We are already working on several features to help streamline the upgrade process, and your feedback would be quite helpful for the same.

    Thanks,
    Sharas Vitalapuram
    Magnitude Software

    ReplyDelete
    Replies
    1. Hi Sharas,

      Yes, with 12.2 Oracle Apps, many things which were well established require re-evaluating (apps owned synonyms being referenced in the template tables being one of them).

      I like the idea of providing developers with best practices for custom views (to steer them in the direction which Magnitude is going).

      On another note, the 6.5.1 NoetixViews worked fairly well in helping us with the 12.1.3 to 12.2.5 migration. Specifically, they adapted enough to the 12.2 coding standard to not make the migration a headache.

      I did have a number of support tickets (which Mohan and Anand mostly handled ...and did well).

      I will contact you.

      Regards,

      Patrick

      Delete