Как не испортить Oracle E-Business Suite: пять лучших советов для разработчиков

Посетители конференции «New England Oracle Applications Group (NEOAUG)» 12 июня 2006 получили небольшой быстрый инструктаж по некоторым наилучшим методикам от основателя и генерального директора компании Apps Associates, Soughtborough, Mass. Sridhar Bogelli, занимающегося консультированием по развитию базовых приложений.

Bogelli, работающий на фирму Oracle, 13 лет разрабатывал пакеты приложений этой компании, выполнял функцию администратора базы данных, функционального консультанта и менеджера проектов. Он рассказал посетителям конференции, что из-за кажущейся простоты некоторых его лучших методик, им часто недостаточно уделяют внимания. Он добавил, что, если внимательно использовать эти методики, разработчики (и опытный и новичок) не нанесут вреда производственно важным программам их компаний:

Изменение пароля по умолчанию

Изменение пароля по умолчанию может показаться для кого-то само собой разумеющейся привычной процедурой, но многие попросту забывают это сделать. Такой просчет может легко поставить всю безопасность под угрозу.

Много людей оставляют пароль по умолчанию и сейчас, в наш век беспроводных соединений. Но ведь злоумышленники могут добраться до места стоянки ваших автомобилей, подобрать пароли DNS и затем войти в систему. Если ваш администратор базы данных не изменил прежний пароль, то попросите, чтобы он сделал это немедленно.

Работа с ограниченными правами (Query-only User in Prod)

Всегда большим плюсом для разработчиков будет наличие пароля с ограниченными правами, - только для запросов "Query-only ". Для того, чтобы разработчик смог получить доступ к бизнес данным, не подвергая риску работе приложений, предназначенных для решения критически важных задач

Выделенное пространство для разработки

Разработчики могут избежать потенциальных проблем, связанных с приложениями, если их администраторы баз данных предоставят им выделенный экземпляр разработки (development instance).

Есть компании, где экземпляр разработки(development instance) сильно отличается от экземпляра используемого в бизнесе (production instance), но все происходит посредством программ, реально управляющих производственными процессами. - Это - очень рискованно, велика вероятность катастрофы.

Поддержание контроля версии

Осуществление поддержки контроля версии для всех доработанных объектов(custom objects) в экземпляре используемого в бизнесе (production instance), или применение такого программного обеспечения (CCR: Configuration, Change and Release management//ERPNEWS/), является важным аспектом, потому что это дает разработчикам и их рабочим командам возможность при необходимости получить доступ к более ранним версиям разрабатываемого приложения.

Контроль версии часто поддерживается непосредственно через базу данных, но при использовании более ранних версий этот метод неэффективен.

Bogelli предлагает разработчикам ввести все таблицы, сценарии, пакеты, процедуры и правила в свои системы контроля версий.

Создайте проект разработки

Создание всех доработанных объектов (custom objects) внутри схемы проекта разработки (custom schema) может значительно сэкономить время.

Чтобы проиллюстрировать это на конкретном примере, Bogelli рассказал о своем друге, работающем на одну крупную компанию в Бостоне. Этой компании недавно пришлось поставить перед своей командой специалистов задачу разработки больше чем 1600 новых объектов.

“Им было бы намного проще создать все эти объекты внутри схемы проекта разработки, тогда они не потратили бы на это столько времени", - сказал Bogelli. "Просто создайте их внутри схемы. Только советую не внедрять их непосредственно в саму схему приложений(apps schema itself)".

Марк Брунелли,
редактор новостей “Search Oracle”
13 июня 2006


Использована терминология:
cfin.ru/itm/standards/manual_oracleaim.shtml
oracle.com/global/ru/oramag/september2005/russia_disc_adv1.html
Все замечания по терминам и вопросы принимаются на адрес 12news@inbox.ru


12NEWS©

© Галактика, 2006
© Издание 12NEWS (ИП Маринин А.Л.), 2006