1 Reply Latest reply on May 3, 2020 11:20 AM by Andy Haack

    Questions about Customizations in R12.2


      Consultants upgraded our 12.1.3 instance to R12.2.9 and I have some questions. FYI I am well versed in R12.2, editioning, EBR, adop, online patching, etc. However... I am much less skilled in EBS customizations, how development occurs, and I know nothing about how patches are made.


      1) When I did my own R12.2 upgrade years ago, I fully registered any custom schema (starting with XX), and they got editioned, and I don't recall any problems. However, our consultants here handled custom objects differently - they dropped all editionable objects out of the custom schema and then recreated them in the apps schema. Of course the readiness scripts then give a "pass" with flying colors and the upgrade went smooth.


      However, now we need to give the apps password out to our developers, and I just feel like our R12.2.9 EBS is no longer "clean" - "genuine" APPS objects are mixed up with custom code. Can't custom code be kept "housed" in its native schema, as long as it is editioned properly?


      2) I am learning that just because a schema starts with XX doesn't mean it is a "true" customization. Our consultants treated all schemas starting with XX equally - and did the above across the board. (I probably would have too). But I have since learned that most of our customizations are for reporting outside of EBS, and/or are staging tables / interfaces to other systems. We may have a maximum of 3 custom schema that are interwoven with EBS. 


      So I found Note 1916149.1 and went back to and classified our XX Schema. Many of them are so "standalone" they might as well be running in SQL Server on a separate database - so I those are a 1.2 - in which was they do NOT need to be editioned and we just need to fix any code that refers to EBS base tables (e.g. INV, GL) to use the apps prefix.  But what if 99.9% of the code inside an XX schema has nothing to do with APPS, but there is 1 single read-only to an EBS table? Is that a 1.2, 1.3, or somewhere inbetween, and does it need to be editioned? It looks like the readiness scripts flagged these schemas as having a "dependency on apps" and therefore needing to be editioned. I am confused about what *EXACTLY* is a "dependency on APPS objects"...


      3) Our instance and organization is pretty small. To avoid having developers create a patch to modify any custom code (like Oracle wants), I am having them copy any custom files to BOTH fs1 and fs2. This works for the filesystem. For database objects – can I just tell them to switch to the patch edition in sqlplus and do whatever they did in the run (default) edition?  Or.. how difficult is it to *actually* create an adop patch -- like Oracle recommends? What is involved? From our end, it would be awesome to be able to apply patches using adop like we do Oracle. Then again, this is probably overkill - as we rarely patch once we go live.

        • 1. Re: Questions about Customizations in R12.2
          Andy Haack

          Hello 4129264,

          I think most questions were answered already in the other trail Ownership and access to custom objects and integrations in R12.2


          Regarding the deployment question 3): We also use the approach to always copy all custom objects on filesystem level to both fs1 and fs2 for blitz report installation and upgrades.

          For editioned database code objects such as views, packages etc., we always deploy into the run edition and check before deployment that there is no patch cycle active (to avoid having the newly deployed code wiped out at cutover).

          Our custom table data is not editioned (we also removed editioning# views and synonyms to them) so that we don't have any issues there.