Do's

What WhyStart-Up

1 So that all the deliverables follow the same conding standards

2

3

6 This is to ensure that we deliver the code as per design docs.

9

10

11 All the deliverables should be under proper version control As in any project this is needed

Generic 12

13 To understand any Impacts in other modules/ areas

14 To ensure that no particular situation is missed out

15 Keep future requirements in consideration To reduce impact on future business requirements

16

17 Consider Multi Org criteria while Developing customisations Can be used by different operating units

18 Do not consider invasive customization

Coding standards docs to be prepared and finalized immediately after the startup of the project

Follow Customisation Standards from Oracle Application Developer Guide for any customisation

These standards are prescribed by Oracle to ensure that your customisations are compatible with Oracle Applications and does not alter any standard functionality and also works successfully

Coding standard doc need to signed off from client before actual coding starts

Need to bring client into confidence about the quality procedures practised

Do cost/benefit analysis of all the options for customization before going ahead with anyone.

As any gap may have a no of solutions, so have a look at different options from development/maintenance/User usability effort perspective.

The design docs needs to be freezed and signed off by client before starting the development.Any further modifications should be taken through Change control.

Any Change during the development should be properly reflected in the design Docs.

This is required from maintenace perspective to have consistency across development deliverables.

Test environment should be setup with all relevant data before actual startup of the project.

Many a times we deliver incorrect code as the code could not be tested properly due to lack of test data

If the developer is not sure from which form/table/application he should pick the information asked in design doc he should contact the client/func user to show him the navigation path/screenshot from where he can see the info

As a technical expert/developer he should not ask the client from which table he would get the info and at the same time it is not expected a technical consultant to know the functionality of the module. So he can follow this approach to get to know the screen and in turn query that screen to get the base table/view.

Explore Standard Functionality before deciding on any customization

Many a times Customizations are asked for, since the users are not aware of complete Functionality within Oracle Applications across modules. Each Customisation request needs to be validated against standard functionality. We need to see whether same objective can be achieved through profiles, configurations or setups

All Customization requirements should be priotized based on whether they are nice to have or must have.

Check the Entire cycle from start to finishin case of any major process customization.

Check all the different scenarios that may be impacted by the customization. E.g. for changing anything related to the invoicing process you should consider all the types of invoice.

Plan cross team coordination where customisation is dependent on other teams' work

No of times a customisation involves cross team involvement like one team is working on building interface using integration tool like WebMethods and fetching required data where other team works on customisation part to enhance Oracle Applications Functionality using data fetched by WebMethods like tool. In this scenario it becomes imperative to have close coordination among teams so that any change in one team's design is communicated to other team well in advance and other team can factor in its impact and modify their design in time. Also for installation and migration activities this is very very important

Any invasive customization should be avoided. It is better to have business process change in that case.

19

20

21 To reduce back end updates

User should be able to appreciate the issue from the error log.

31

Create a Custom Oracle Id to register new custom objects

It improves performance

Interfaces

22

23

24

All codes should have proper exception handling and reporting

25

Consider performance/maintenance issues before start of the development

In many cases the customizations are not effective as due consideration to performance has not been given during design.

Use Custom Applications to register forms, functions, executables, concurrent programs, report sets, responsibilites, menus

Oracle Application Patches change standard AOL objects a no of times. In order to preserve your customisations it is imperative to use Custom Applications so that any patch does not affect your AOL setups for Customisations

Errors should be handled in such a way that it can be rectified from the front end

Put userfriendly message in the error log. E.g. instead of putting inventory item id or organization id in the error log , put the part no, organization name which can be easily understood.

Even if the solution requires more effort, still always go for using the standard API for updating standard apps table. E.g. rather than updating hold information in the order table directly, it is better to populate the information from order table to order interface table and then agian updating the order table by running the the order import api in an update mode after changing the hold information there..

Updating of the standard apps table may corrupt the data as there may be different front end validations that will not be taken care of. Standard API will take care of the same.

Requirement for insertion of data in apps tables in absence of APIs should be handled carefully by using a custom intermediary table to store the custom data and by doing the required validation there.

The custom data should be stored separately in a custom table. The data in apps tables should be updated only after ensuring that the original data in apps tables can be retrieved back easily. Any possible validation should be done at the custom table.

Oracle Apps Customization standard for easy code maintenance/preventing any accidental change of Standard apps objects.

Create index in cases where many queries will be able to use the same and the table is not frequently updated/inserted. Choss the right type of index based on the data diversity.

Always use Oracle APIs when creating/updating any record in APPS base tables.

Inerting data directly into base tables is not supported by oracle and also, APIs are already designed to do all validations. Custom programs might not do it completely due to process mapping / design oversight

Always use a staging table when pulling in data from external source to an APPS open interface

If data is inserted directly into the APPS open interface table, the APPS Open interface will validate the data in the open inteface table while trying to import it, but it won't give you any "customized" error msgs. It might become a major activity to figure out these errors. It is better to have staging table and do all possible validations there by a custom code before the code inserts the data into APPS open inetrface table. Also, any other validation as per the specific project requirement can be taken care of at that stage.

All custom codes should have proper exception handling. At the same time, every exception should be captured and written into a log, preferably along with some key data being processed at that time.

Proper message segregation should be done between the log out put and the error log while putting comments in the concurrent program.

All custom concurrent programs should write important activities and key data into logs

While figuring out the cause of an exception or an unexpected output, it is a great help if there is a trail of activity created by the code.

Use AUTHID current_user clause in the custom package declaration.

This eliminates the requirement of creation of synonyms and giving grants to standard apps objects to the custom schema as per the requirement of the custom package.

Forms

26

New Form Customisation - Modular Approach

27

Standard Forms Customisation

28

29 Always do a server-side compilation of forms/plls Executable should be compatible with server-end version

30As advised by Oracle

32To avoid upgrade overwrite

33Oracle Apps Customization standard for easy code maintenance

34Code must be maintainable

35Code must be maintainable

36Code must be Readable

37 Template form is the starting point for building a form Use reusable and shared objects

38

Coding for better performance

39 Code should be platform independent As advised by Oracle40 Keep number of procedures in a package < 25 Coding standard41 Specify field names along with their block name Coding standard42 Use object id: U_id := find_item ('block.item'); Coding standard43 Use FND_MESSAGE to display any message Coding standard

44Use raise form_trigger_failure to stop processing on the client Coding standard

45Coding standard

46Coding standard

47

Coding standard

48Coding standard

While creating a new custom form, it is advisable to create a new Libaray to store all common custom programs, triggers etc so that same code can be called a no of times in different form triggers and also code remains easily maintainable. Even it this code is in form level triggers it will not work as expected.

It is not advisable to customise any standard oracle applications form. Instead one should try to achieve the same by either excluding certain functions available to responsibility or by changing the custom.pll

Always try to use custom.pll/ Apps personalization for forms code customization

1) It allows extension of Oracle Applications without modification of Oracle Applications code2) It that allows you to take full advantage of all of the capabilities of the Developer 2000 suite of products and integrate your code directly with Oracle Applications3) In basic terms, the CUSTOM library lets you change properties, functionality and operation of a form as if you were actually changing the source code of the form.

In Custom PLL Use FNDSQF library for function security, flex fields and message procedures

Do not use standard OA prefix like "INV_" in custom database objects

Create a Custom Directory Structure to register custom source codes

Write Code in discrete packaged procedures, known as HandlersFollow naming conventions for objects, package and procedures

Use proper indentation in your codePut comments in your code wherever possible

Always evaluate the requirement of a folder form or a canvas based form at the begining of the development.

In many cases, the requirement of folder form is established towards the end of development cycle, based on the no of columns requirement. This requires almost a redevelopment of the form.

Create base table blocks on viewsUse data base stored procedure when extensive SQL is requiredCode all non-SQL logic on the client side wherever possible.

Use app_exception.raise_exception to stop processing on the Server

Replace EXIT_FORM to do_key('EXIT_FORM') after copying 'Y' to :GLOBAL.APPCORE_EXIT_FLAG

Use APP_ITEM_PROPERTY.SET_PROPERTY, APP_ITEM_PROPERTY.GET_PROPERTY, APP_ITEM_PROPERTY.SET_VISUAL_ATTRIBUTE to get Oracle Applications behavior.

Use FND_FUNCTION.EXECUTION instead of OPEN_FORM for security purpose

49 Use do_key('COMMIT') in place of COMMIT Coding standard50 Use do_key('CLEAR_FORM') in place of CLEAR_FORM Coding standard

51

Coding standard

52Use AK flow pages to create custom self service web pages

53

54

Use of Folders in Form Customisation

55

Query Only Forms

56

57Plan the usage of any Descriptive Flexfields

Keep a single register of all the DFF attributes used.

58

Alrets has been provided by Oracle to write triggers on tables.

59Be cautious about using too many alerts

Workflows

60

Workflow Customisation Approach

Reports

61

62

Use do_key('edit_field') in place of EDIT_FIELD/EDIT_TEXTITEM, so that calendar is raised if the current item is a date.

Easy to maintain during upgrade, less technical skill is required, look & feel is same as Oracle Apps

If some additional functionality is needed on a seeded form, doing it thru the use of CUSTOM.pll is preferred, rather than copying the form & then modifying & registering the copy.

Lower maintenance & higher consistency. In addition, the form thus "modified" thru the use of CUSTOM.pll calls is very much supported by Oracle.

Sometimes it is not possible to fit all fields in a form in single screen or form canvas, it is advisable to use folder option. This option gives easy navigation to user.

Oracle Applications allows to define a function with parameter QUERY_ONLY = Yes. This Function allows read only access of form to user. Developer do not need to change form in any way to achieve this functionality

If additional columns (on top of what APPS already provides) are needed to store certain business data, use DFFs

DFFs have been provided to "customize" your tables to certain extent. Not all tables in the APPS db have this feature, but most of the critical ones do. There are limitations but most business requirements can be met. It is supported by Oracle.

No. of DFFs on any Oracle Applications Table are limited. Hence Developer needs to use them very conservatively.

To avoid usage of same DFF attribute for different purpose in different enhancements.

If there is a need to use database triggers (one inventory txn record kicking off notifications, for example), use Oracle alerts.

Every alert slows down the system. Do not use alert on transaction tables which will cause the alert trigger to fire frequently.

For any workflow customisation, developer should copy standard process with some other relevant name and customise it. One should never change standard process as it removes any fallback on standard functionality in case customisation does not work. Also original file needs to be kept as separate object in version control tool

Use this example istead of truncating a date column in where clause of sql query.Example WHERE creation_date between to_date('10-JAN-1950') and (to_date('10-JAN-1950') + .99999)

Increases the performance of the query if any index exists for the column creation_date

Use fnd_profile or fnd_global utility to get various values required in concurrent program instead of hard coding. Prefer using a non displayable parameter for any hardcoded value used by the program and set the the value as default to the parameter. You can also use lookups to define various values

You can chage the parameter default value in future without changing the program code

63

Using fnd_global.conc_request_id will return null value

64Lower maintenance & higher consistency.

65Linking logic between the sequences can be established

66User inputs will be less

67 Ensure Page protection for records To prevent data inconsistency in reports68 Ensure proper anchoring of frames & fields This will prevent unintended data overlaps69 Define correct print styles while registering reports This will prevent unintended data loss in O/P & wrapup of data

70

71

72To avoid incorrect totals/subtotals

73 For ftping reports to database server, use binary mode Otherwise the rdf gets corruprted

Delivering the Components74 The structure and components in design docs,installation docs neThis is necessary so that all the deliverables follow the same standard

75

76

To ensure that the code is tested with expected data.

77 Should have IQA/EQA before actual delivery of the code. To delivery code first time right.

Reusability78 For conversion projects, the team should prepare a mapping doc.This will remove the re-work on the same. E.g. from 10.7 to 11i upgrad

Obtaining the Concurrent Request Id from within Reports Define a user parameter called P_CONC_REQUEST_ID. The parameter is be called as P_CONC_REQUEST_ID. In the After Paramete form trigger in the report, have the following code srw.user_exit('FND SRWINIT'); This user exit will populate p_conc_request_id with concurrent request id. In the After Report trigger, have the following code: srw.user_exit('FND SRWEXIT');

While registering a new concurrent program / report, use existing, seeded, value sets where possible.

Use Request Sets to execute series of related sequential requests

Use Shared Parameters for parameter values that should repeat in requests in a report set

Use attachment files (e.g. tif file) for Faxmail type reports' header & trailer pages

Reusablity of the same attachment file for multiple similar reports from same business/module, less coding in the rdf file

While making enhancements to an existing report with non-English characters (German, Japanese etc), make sure that you have the font installed in your PC

Otherwise all non-english data will become corrupt upon savoing the report.

For all summary columns ensure that reset level is correct by thorough testing

Detailed Documentation for Installation & Migration of Customisations

Each Customisation is unique in terms of functionality it affects, components it involves and migration requirements. In order to reduce dependancy on availability of instances or migration tools and to reduce risk of losing any setups, configurations we need to document each installation and migration step. We also need to maintain a traceability matrix for each customisation in terms of which components it involves, which APPL_TOP they need to be and so on

The functional doc should have the test cases component filled up while the developer has to ensure that he fill up the test results before delivery of the code

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory / Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Mandatory

Optional

Optional

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Don'ts

What Why1 To ensure on-time & first time right delivery

2 So that code is delivered on time

3

4

5 Do not ever Drop any standard database object The entire system may become corrupt

6

7 To keep standard functionality unchanged

8 Changing standard forms NOT recommended by Oracle

9 Oracle Apps works across multiple platforms

10 Not recommended by Oracle.

11

12

13 Deletion of objects in customised workflows

14

15 Easy to maintain and OA standard

16 Do not change the specification of the CUSTOM package As advised by Oracle

Prevent commiting to client without requirement analysis & exhaustive feasibility study

Do cost/benefit analysis of all the options for customization before going ahead with anyone.

As any gap may have a no of solutions, so have a look at different options from development/maintenance effort perspective.

Design docs once freezed should not be changed to incorporate last minute changes.

Do not try to direclty insert/update records in Oracle Applications Tables

Many times oracle provides Interface tables to import data from external sources into Oracle Applications. The benefit of using Interfac e Tables are that before this data gets imported into Oracle Applications Table, it goes through validation by standard Import Programs and hence ensure data integrity.

Do not change seeded Oracle Application Packages unless advised by Oracle Support

Changing any seeded Oracle Apps Package can alter standard functionality. It is also a high maintainence customisation since when any patch is applied, DBA team needs to revert Oracle Apps Package to its Original State before Customisation and after patch is applied, Developer again needs to make required changes

For customizations using standard import APIs, do not commit directly including features that are not supported by that standard import process

Cannot modify standard APIs to include such features - try to work out an optimum solution

Prevent using custom API's to load data into OA production tables, use Oracle's standard Open interface routines

Do not add or remove fields in any standard form as a part of customization -- try using CUSTOM.pll & DFFs instead

In forms/reports customization we should not write any code which are Microsoft based. E.g OLE/ACTIVEX/MOUSE-MOVE,WINDOW-CLOSED etc

As a part of Customization, custom objects should not be created in Apps or other standard Application schemas. Shouls create custom objects in custom schemas and create public synonyms for these objects

Avoid coding of database triggers on Standard tables of Apps as far as possible

Not recommended by Apps. See if you can use the CUSTOM.pll instead

Do not change seeded workflow where Oracle does not recommend customisation. This is evident in customisation access level on each workflow objects

Workflow is an integral part of Oracle Applications Functionality and affects multiple modules. In many cases, functionality is so integrated with other modules that any customisation will severly affect standard Oracle Applications Functionality and hence Oracle does not recommend any customisation on them

Whenever any customised workflow is being modified and some objects are getting deleted, user must first connect to database before doing so. Otherwise there is discrepancy between workflow definition and workflow database tables and this does not allow new definition to be saved successfully

While writing custom functions for workflows, don’t do any commit in your code.

W/f engine writes selective pieces of control data & flags into W/f tables while executing a W/f function. Your commit in the same session MIGHT commit some data into w/f tables which W/f engine had no intention to commit !!! This can cause severe status problems in that W/f - in fact it might simply get into an invalid status & error out.

Do not use SQL in the CUSTOM library, (call server side packages instead, or use a record group to issue the SQL for you)

17 because CUSTOM is attached to APPCORE

18 Limitation

19 Do not create triggers on ALR_ALERT To avoid recursive loops

20 Do not insert rows into FND_DUALs To keep standard functionality unchanged

21Do not create index on the interface table unless really required. It will have heavy performance impact.

Do not create triggers on standard transaction tables It will have heavy performance impact.

Due to heavy customization the performance may be heavily impacted.

Do not attach the APPCORE library to the CUSTOM library For example, function APP_ITEM_PROPERTY is not available within the CUSTOM library. You should use Oracle Forms SET_ITEM_PROPERTY instead

Do not use CALL_FORM or OPEN_FORM within the CUSTOM library, useFND_FUNCTION package instead

Do not go for many customizations in the same process cycle unless really required.

Avoid creation of alert on transaction tables unless really needed.

Many a times the requirement for alert or database trigger can be eliminated by having scheduled jobs, which are much prefereable option to the the triggers.

Prefer database triggers to the creation of alerts in cases, where the operation can be more selective by use of triggers. e.g. there is no option to specify 'WHEN' Criteria in an alert which is possible through a database trigger.

Mandatory

Mandatory

Optional

Optional

Mandatory

Optional

Optional

Mandatory

Mandatory

Mandatory

Optional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory / Optional

Mandatory

Mandatory

Mandatory

Mandatory