Miscellaneous Technology

There are many standards in Oracle Apps Development, some of which are very well known, for example never create tables in APPS Schema. Another common set of standards are to register your custom objects against custom schema and much more. These standards have been around for over a decade. Here in this article I will discuss some additional development standards.

Do you have more to add? Then add those in the comments!

Debugging
All custom code we write should leverage FND Logging technique using fnd_log.string in PL/SQL and writeDiagnostics in Java. You must not re-invent the wheel for debugging custom code, as a great framework for debug logging comes out of the box in eBusiness Suite.


Create a custom $JAVA_TOP, lets say $XXJAVA_TOP
In order to do so :-
a.  Create a directory on both DB Tier and Mid Tier
b.  Change the environment files on those tiers so that custom CLASSPATH will include the relevant directory. All our custom java objects or 3rd party libraries will be stored in this place.
All java and OA Framework related customizations can be stored here. Third party library jar files can be stored here, instead of storing them underneath $JAVA_TOP directory. In a very very very

rare case, if you customize the standard object, then such approach avoids the need to modify contents within JAVA_TOP. You should ensure that $XX_JAVA_TOP appears before $JAVA_TOP in the CLASSPATH.


No hardcoding
Everyone knows this, yet I see developers indulging into hard codings. You must implement a Zero hard coding approach when writing custom programs. Defaults to hard coded values must be inherited from concurrent program parameter defaults or from profile options or from some lookup tables or descriptive flexfields. Appropriate functionality amongst these must be used as appropriate in the context.


Database Triggers
Database triggers must not be used in Oracle Applications and instead business events must be used. In case there is a strong need to create DB Triggers, then use database Triggers as a stub for invoking business events. However even before using DB Triggers to raise events, check if the specific product has any hooks. For example POR_CUSTOM_PKG in iProcurement and HRMS has its own Hooks. All said and done, some of the core tables in eBusiness Suite like PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_F and MTL_SYSTEM_ITEMS_B are delivered out of the box with almost 10 triggers each :)


Commits
Do not do commits within the APIs that you develop. Do not do commits within the PL/SQL called from Workflows.


CUSTOM.pll
If you are on 11.5.10, then use Forms Personalization where possible.


SPECIAL Triggers
Do not use SPECIAL Triggers for custom usage. These triggers are reserved by Oracle for their product development team. Instead use MENU1..MENU15 for creating new Toolbar menus. These Menu's are given by Oracle for the purpose of extensibility.


GLOBAL Variables
If you ever create global variables in Forms Personalization or CUSTOM.pll or Custom Forms, then ensure that these global variables begin with name XX. Image that a developer write custom login in Forms Personalization to create a global variable named CUSTOMER_ID in Receivables.  Surely such custom variable names can overlap with standard global variable names. Such issues are extremely difficult to debug. Therefore avoid such issues by proper naming conventions. Also you must ensure that you clear the global variables after their usage.


Third Party Interfaces
Avoid building point to point interfaces with a third party product. Instead use SOA if you have a SOA Backbone. SOA may be a 3 letter word, but can cost 7digit license fee. If your client does not have SOA Backbone, then consider using XML Gateway to send and receive messages. Of course XML Gateway is free. Indeed there is a downside of using messaging approach, which is that there is dependency on the third party developers to dequeue and process the message. With point to point approach, example JDBC based concurrent program, an eBusiness Suite developer can do operations on both EBS and third party systems simultaneously, and one can argue that it works like a charm too.


Calling Web Services
If you are lucky enough to be on R12, then you can subscribe a WSDL to the business event. Therfore a business event can seamlessly raise a web service. Web Service parameters can be defined as Subscription parameters. In fact R12.1.1 goes a step further that provides wizard in Business Event Subscription page, to dynamically generate UI to define parameters within the WSDL.


DB Sequence
A common mistake is to create DB sequences directly in APPS schema. As per standards DB Sequences must be created in the same schema where custom tables are created.


Global Data Segments
Do not consume the Global Data Segments like there is no tomorrow. There are limited numbers of attributes for DFF in tables. Try to design flexfields that are context sensitive. Having said so, be very careful in selecting the context, as there is only possible context field per DFF. Indeed a double edged sword, but at least context based Descriptive Flexfields allows re-usability of attribute columns and does not show unwanted segments for each transactions.


Apply your Customized workflow in Upgrade mode
Do not upload your workflow in FORCE mode unless you have good reasons to do so. Of course this does not matter when developing purely custom workflows.


Descriptive Flexfields
Avoid creation of descriptive flexfields in HRMS unless utterly strong business need to have those fields available at Person or Assignment record level. Instead consider using EIT or SIT as applicable.


Bind Variables
Usage of Dynamic SQL must have bind variables. Hard coding literal values in where clauses this is a very common error on developer’s part when building dynamic SQL, causing performance overheads. It is a fact that even experienced developers sometimes ignore this rule, until the DBAs begin reporting high CPU usage by certain processes that rely heavily on dynamic SQL and run for mass volume of data.


Materialized Views - The slow poison
Creation of Full Refresh Materialized views must be avoided in Oracle Apps at all costs, unless the Materialized views are incremental in nature. Refresh times for large materialized views are a like a slow poison to Oracle eBusiness suite. They are not holy grails for OLTP systems.


OA Framework Deployments
When Oracle delivers their code, they do not provide java files in $JAVA_TOP. However for our custom code we need to decide if we will deploy java files on file system or will leave them within the source control itself. Whatever may be the approach followed, we should be consistent with that approach. Otherwise we may end up with a mixture of right version and wrong versions of source code java files in $JAVA_TOP.


Packaging OA Framework Code
All package names in java will begin with xx.


New attributes added to View Objects during extension
Ensure that the new attributes that you add to view object during extension begin with xx. It then becomes very easy for any other developer to identify the custom columns. Some VO's are developed by Oracle in expert mode that are not too upgrade safe. Therfore identification of the custom attributes is very important.


Master environment for personalizations
When developers do extensions to OA Framework, this often involves some personalizations. Ideally these personalizations will be imported and exported from one instance to another.But by doing so, developer’s personalizations might replace the Functional persons personalizations. It is difficult to avoid these issues with multiple people do personalizations in multiple environments. But awareness is required as we do not have a single Master environment where all the personalizations are held.


FNDLOAD
This should be used where possible, keeping in mind that FNDLOAD does not perform deletes, with the exception for Menus [can be run in replace mode] and Forms Personalizations that are dropped and uploaded from file.

Anil Passi

Add comment