Five Oracle developer best practices

WORCESTER, Mass. -- For the Oracle developer, customizing Oracle E-Business Suite applications can be a very risky venture, especially if that Oracle developer fails to follow some simple and straightforward best practices, experts say.

Oracle developers attending the New England Oracle Applications Users Group (NEOAUG) conference Monday got a quick refresher on some of those best practices from Sridhar Bogelli, the founder and chief executive officer of Apps Associates, a Southborough, Mass.-based application development consultancy.

Bogelli, a former Oracle employee whose background includes 13 years of working with Oracle applications as a developer, DBA, functional consultant and project manager, told session attendees that while some of his best practices may seem simple, they are often overlooked. He added that remembering to follow these guidelines will go a long way towards ensuring that developers -- both experienced and beginner -- don't go damaging their companies' production boxes.

Change the default Apps password from 'Apps'

Changing the default password from "Apps" may seem like a no-brainer to some, but it's something that many developers forget to do, Bogelli said. Such a failure can easily lead to security breaches, he added.

"I've seen a lot of people keep [the default password] and in this age of wireless connectivity, people can really drive up to your parking lot and guess your DNS names and then get into your system," he said. "If your DBA has not changed that password, ask him to change it now."

Work with a Query-only User in Prod

Bogelli said it's always a good idea for developers to have a "Query-only" password so that they can access production servers without putting mission-critical applications at risk.

"It's beneficial because if you're operating on the Apps [all-purpose] password, it's so much more pressure because you have to be very accurate," he said.

Demand a dedicated development instance

Developers can avoid potential problems with production applications by asking their DBAs to provide them with a dedicated development instance.

"I've seen places where the development instance is so different from the production instance, but all development is happening in the production box," he said. "That's a scary [proposition] because it's very prone to disaster."

Maintain version control

Maintaining version control for all custom objects in the production database, or implementing version control software, is important because it gives developers and their teams the chance to access earlier versions of custom objects when necessary, Bogelli explained.

Version control is often maintained through the database itself, but this method is inefficient when it comes to accessing earlier versions, he said.

Once implemented, Bogelli suggests that developers enter all tables, scripts, packages, procedures and rules into their version control systems.

Create all custom objects in the custom schema

Making sure to create all custom objects in the custom schema can really help save time over the long haul, Bogelli said.

To illustrate his point, Bogelli talked about one of his friends who is employed by a large company in Boston -- a company that recently had to charge a team of workers with the task of organizing more than 1,600 custom objects.

"If all of these custom objects were created in the custom schema, it could have been so much easier to maintain and they wouldn't have had to spend all the time on this effort," Bogelli said. "Create them in a custom schema. Don't just drop them into the apps schema itself."