Цфт программа банка инструкция по применению

Время на прочтение
7 мин

Количество просмотров 11K

Финансовые компании находятся в поисках лучших решений, которые оптимизируют внутренние процессы разработки, разовьют IT-инфраструктуру в соответствии с требованиями бизнеса и позволят им выводить на рынок лучшие конкурентные продукты. Так, два года назад мы ступили на путь перевода разработки ЦФТ-банк на платформу CFT Platform IDE. Среди коллег по цеху ходят слухи, что это процесс невероятной сложности, ввиду чего не решаются приступить к делу. На своем примере мы докажем, что это вполне подъемный процесс и для вашей команды.

Процесс разработки ПО в НРД в большинстве случаев характерен наличием нескольких команд разработчиков, которые лавируют между проектами, занимаясь разными модулями одной или даже разных систем. В работе у нас постоянно большое количество доработок и приходится держать несколько dev и test-контуров с разными версиями системы. Таким образом, всегда есть необходимость доступа к централизованному хранилищу кода с поддержкой версионности, обеспечением автоматической сборки и установки. Для системы ЦФТ-Банк на протяжении многих лет таких возможностей не было.

Это порождало лишние затраты на подготовку сборок, merge-изменений и т.д. Часто возникали случаи порчи программного кода, т.к. следить за правильностью версиии той или иной программной компоненты могли только сами разработчики в полностью ручном режиме. Однако поменять подход к разработке для системы ЦФТ-Банк было невозможно ввиду существования безальтернативной среды разработки для этой системы, по своему интерфейсу и возможностям отставшей от жизни лет на 15.

Решение наших проблем было предложено ЦФТ с выводом на рынок в 2018 г. новой платформы разработки для своих систем, которая называется CFT Platform IDE (она же Admin 2.0, или сокращённо A2).

Ключевые отличия новой платформы разработки

Внешне разработчик получает среду, реализованную на основе Eclipse Platform, которая гораздо симпатичнее архаичного Администратора словаря данных.

Для сравнения редактирование кода в старой среде (Администратор словаря данных):

Редактирование кода в Admin 2.0:

Но основным преимуществом новой платформы разработки для нас явилась возможность хранения программного кода системы, а также экранных форм, описаний типов и прочего в виде множества текстовых файлов. Именно это позволяет выгружать код в систему контроля версий (в нашем случае Git) со всеми её возможностями, которых нам так недоставало ранее при разработке для ЦФТ-Банк.

Таким образом, разработчикам ЦФТ-Банк стала доступна возможность комфортно отслеживать историю изменений каждого объекта, включая не только время редакции, но и сравнение старой и новой версий через встроенный компонент либо с помощью любого внешнего средства типа Araxis Merge. Тому, кто не знаком с ЦФТ-Банк, это покажется удивительным, но ранее о таком приходилось только мечтать, храня историю изменений лишь в виде комментариев в коде.

Приятными бонусом послужила возможность синтаксической проверки кода без соединения с БД, а также удобная навигация (переходы в вызываемые процедуры по щелчку в месте вызова), быстрый контекстный поиск по проекту.

Отмечу, что новый админ оказался в хорошем смысле более привередлив к синтаксическим конструкциям в коде. Среди наших локальных доработок были выявлены очень странные выражения, например, что-то наподобие:

• ::MAIN_DOCUM вместо ::[MAIN_DOCUM],
• select md(md%id: rSelf) in ::[MAIN_DOCUM] all where md.[IN_FOLDER]=this bulk, причём в откомпилированном коде PL/SQL слова bulk нет, что с ним, что без него компилируется одинаково,
• Pragma macro(’Ошибка!’) вместо Pragma error(’Ошибка!’).

Непонятно, как Администратор словаря «переваривал» подобное без ошибок. Причём, если первые 2 примера представляют собой безобидный мусор, то последнее — явная ошибка, которая приведёт к некорректной работе программы.

И ещё одной особенностью Admin 2.0 является, благодаря интеграции с Git, функционал получения списка изменений на основе сравнения 2-х веток.

Это позволяет выполнять развёртывание этих изменений в целевую БД. Затем изменения из БД можно выгрузить по тому же списку элементов, используя старый Администратор проектов, в mdb-файл, если их необходимо передать для установки в БД, куда разработчик не имеет прямого доступа. Однако более интересным вариантом является подготовка и развёртывание изменений в новом формате. Он представляет из себя zip-архив, внутри которого находятся текстовые файлы с кодом, а также некоторая метаинформация. Побочным эффектом является возможность просмотреть и даже изменить код в передаваемой поставке без установки в какую-то БД, что в случае с mdb-форматом было невозможно. Но самое основное – сохранение в этот новый формат из Git-репозитория и развёртывание в БД Admin 2.0 предусматривает делать и в безинтерфейсном режиме, что позволяет настроить автосборку и автоустановку, т.е. наконец говорить о CI/СD в применении к доработкам ЦФТ-Банк. Правда, данную тему я планирую подробно раскрыть уже в следующей статье.

Особенности перехода на новую платформу

Материальный вопрос

Первое, с чем пришлось столкнуться — получение лицензий на рабочие места. На каждое рабочее место разработчика требуется отдельная лицензия, которая привязана сразу и к железу ПК, и к учётной записи пользователя. Если у вас в компании тоже несколько изолированных сетей, где есть сервера с ЦФТ-Банк, и ведётся разработка на них, то на одного разработчика потребуется купить несколько лицензий Admin 2.0. Стоимость одной лицензии на момент написания статьи составляет 125 у.е./мес., или около 8 тыс. руб. по внутреннему курсу. За первоначальную покупку на данный момент деньги не взимаются. Лицензии распространяются в виде файлов, а не смарт-ключей, что позволяет без проблем развернуть среду даже на виртуальной станции.

До покупки можно договориться о предоставлении тестовых лицензий. В нашем случае были получены 6 лицензий со сроком действия — 4 месяца на бесплатной основе. Условия обсуждаются с персональным менеджером индивидуально.

Настройка рабочих мест и БД

Серверную часть IDE можно устанавливать и в рабочее время, но правильней будет, если в момент установки не будут открыты на редактирование программные объекты ЦФТ, т.к. основное в обновлении — это новый механизм соответствующих блокировок.

Клиентская часть — это, по сути, Eclipse с расширениями CFT Platform IDE, устанавливается без прав администратора ПК. Только заранее должна быть установлена JRE не ниже 8-й версии. Доступ к обновлениям IDE на сайте ЦФТ теперь открытый, без авторизации. Можно настроить обновления непосредственно через сайт, либо из локальной сети. Например, из сетевой папки или с использованием менджера репозиториев вроде Nexus. Мы выбрали вариант сетевой папки как самый простой в настройке, не требующий доступа в Интернет со всех рабочих мест, надёжный, что важно при настройке тяжелых обновлений, и гибкий ввиду возможности выкладывать обновления по своему расписанию.

Выгрузка кода локального приложения

Для создания проекта, с которым будет работать Admin 2.0, нам нужно выгрузить из БД в папку с набором текстовых файлов описание объектов, являющихся нашими локальными доработками, а также, условно говоря, ссылки на объекты, от которых наши доработки зависят.

Отмечу, что при большом объёме локального приложения среда разработки начинает тормозить, поэтому в такой ситуации необходимо будет деление исходников на актив и архив. К счастью, в лимит мы вписались при немалом объёме локала. Однако стоит учесть объём оперативной памяти рабочих станций. Согласно документации требуется не менее 16Гб, хотя некоторое время части наших разработчиков удавалось работать и на 8Гб памяти, надо было лишь отрегулировать объём памяти java-приложения в файле eclipse.ini.

Что касается выгрузки — процедура несложная, т.к. все необходимые скрипты, такие как для подсчёта объёма приложения, для получения списка объектов и другие входят в комплект поставки.

Адаптация кода

Адаптация заключалась в дополнении того, что не собрал скрип, например, прогрузились не все ссылки на таблицы в чистом Oracle, некоторые ТБП со сложным подчинением — в единичных случаях не подгрузились типы ссылок или массивы. Также надо было слегка подчистить код (см. примеры выше). Но самое главное — подстроить код под новые особенности:

• все простые представления были автоматически преобразованы в pl/plus (т.к. работу с простыми представлениями Admin 2.0 не поддерживает). При этом нередко это происходило с ошибками, которые надо было устранять (например, т.к. вызов интерфейсных пакетов напрямую теперь не поддерживается пришлось переделать вызовы в стиле pl/sql (типа Z$MAIN_DOCUM…) на pl/plus (типа::[MAIN_DOCUM]…));
• в Admin 2.0 была исключена поддержка inline-вставок pl/sql кода — конструкции в фигурных скобках {}, и лишь недавно эту поддержку вернули;
• Admin 2.0 не поддерживает выражение between в sql запросах, которое использовалось у нас в нескольких представлениях (что странно, т.к. это стандартная конструкция, в том числе для чистого pl/sql);
• проявившиеся ошибки в «мёртвых» кусках кода. У нас было несколько процедур, где часть кода отсекалась посредством return, либо if false, или же макросом IF_DEF. Оптимизатор или макрокомпилятор отсекали код, который уже не анализировался на наличие ошибок. Некоторые такие куски стали невалидными, т.к. изменились вызываемые процедуры и используемые ТБП, просто компилятор их не видел. Admin 2.0 стал «обращать внимание» и на эти куски.

Результат

Серьёзных проблем при адаптации не было. Нам посчастливилось «познакомиться поближе» со своим кодом. В процессе мы выявили недочёты в IDE и даже в технологическом ядре (в компиляторе), которые сейчас ЦФТ уже исправил.

Большую помощь нам оказали специалисты ЦФТ, которые оперативно реагировали на возникшие проблемы, а в случае замедления процесса внедрения с нашей стороны всячески нас стимулировали и поддерживали интерес. После всех этих подготовительных действий мы запросто настроили интеграцию Eclipse с Git и выгрузили в него код текущей версии.
Нам потребовалось создать регламент ведения разработок, т.к. разработчикам ЦФТ-Банк пришлось привыкать работать совершенно в ином стиле: правильно маркировать коммиты, работать в нужной версии и пр. Сама методика работы стала соответствовать общим стандартам разработки в IT-компании.

Несмотря на первоначальное снижение скорости разработки, Admin 2.0 был сразу встречен в нашем коллективе с большим энтузиазмом. За 1-2 месяца активной работы все привыкли к новой среде, а эффективность возросла.

Сегодня Admin 2.0 до сих пор находится на стадии активных доработок, но это гораздо менее сырой продукт, чем 2 года назад. Например, только недавно появилась поддержка работы с группами доступа, пока работающая с ошибками. Также развёртывание в безинтерфейсном режиме может завершаться с ошибками при наличии в коде макросов. Большинство недочетов, которые мы фиксируем, ЦФТ устраняет в пределах месяца. За эти 2 года мы использовали отличную возможность повлиять на развитие Admin 2.0. Сегодня компании, которые задумали подобный переход, смогут пройти этот путь ощутимо быстрее.

Предпосылки принятия банком решения о централизации клиентских данных могут быть самыми разными, например:

• Централизация бизнеса банка

• Последствия процессов M&A

• Сложный IT-ландшафт банка

В первом случае — актуальном для крупных многофилиальных банков, необходимо обеспечить доступ к клиентским досье всех централизуемых подразделений. Это позволит сохранить качество обслуживания клиентов банка и обеспечить актуальную и полную информацию о клиенте в любой момент времени и в любом офисе банка.

Кредитные организации, в организационной структуре которых произошли значительные изменения, например, в силу слияния или поглощения одного банка другим, также сталкиваются с необходимостью объединения клиентских данных, а конечным результатом изменения банка, прошедшего процедуру реорганизации, должна стать единая и правильно организованная система клиентских досье.

Не стоит забывать и о том, что в различных информационных системах (АБС, CRM, биллинговых системах, системах ERP) банков годами накапливались сведения о клиентах банка: для разных подразделений, с различной версионностью, спорной актуальностью, дублирующие друг друга. Разобраться с этим и навести порядок без централизации клиентских данных почти невозможно.

В любом случае задача по централизации клиентских данных и управлению ими представляет собой целый комплекс технически сложных задач:

• поддержка полноты и актуальности клиентских данных во всех информационных системах банка;

• организация упорядоченного хранения документов клиента, оригиналы которых часто предоставляются в разные филиалы банка и в результате сканируются и хранятся на локальных серверах;

• организация быстрого доступа к клиентским досье из любой точки банка;

• проблема дублирования клиентов;

• историчность данных и документов;

• организация эффективных процессов по управлению клиентскими данными.

Для решения всего комплекса задач по эффективному управлению данными о клиентах и контрагентах банка предназначена система «ЦФТ-Клиенты».

Как централизовать хранение досье

Решение «ЦФТ-Клиенты» разработано специально для обеспечения потребностей кредитных организаций, и в нем учтены все специфические требования бизнеса банка в части ведения информации о клиентах. Решение интегрируется с информационными системами других разработчиков, может использоваться банком как функциональный модуль в составе «ЦФТ-Банк» или как отдельно установленная компонента. В любом случае хранение больших массивов информации (документов, скан-копий) осуществляется в отдельном от АБС репозитории, что позволяет оптимизировать производительность комплекса.

Выполняя функции хранилища информации, система «ЦФТ-Клиенты» является инструментом для ведения истории по каждому клиенту

Какими же функциональными возможностями наполнена система «ЦФТ-Клиенты»? Во-первых, это — централизованное ведение досье клиента. Сотрудник банка вносит в систему (или редактирует) клиентские данные, при этом автоматически осуществляется контроль достаточности клиентских данных. Во всех точках обслуживания банка документы клиента на бумажном носителе сканируются, проходят процедуры распознавания, классификации и поступают в единую централизованную базу, доступную сотрудникам во всех офисах банка. Работа с анкетой клиента доступна для сотрудников различных подразделений банка — кредитного отдела, отдела ПОД/ФТ, внутреннего контроля и др. Все это позволяет оптимизировать бизнес-процессы банка, связанные с обработкой и использованием клиентской базы.

Хранение документов в системе «ЦФТ-Клиенты» организовано в разрезе продуктов банка, таким образом, решение позволяет формировать пакет клиентских документов (досье) по любому договору и (или) финансовому продукту банка. Также в системе реализован контроль актуальности документов, представленных в досье.

В соответствии с потребностями банка в системе можно настроить маршруты обработки документов любой сложности, определить роли пользователей на каждом этапе обработки документов, рассылки e-mail-уведомлений ответственным сотрудникам при изменении статуса заявки. Принцип «контролирующих рук» обеспечивает выполнение различных операций с досье клиента (редактирование, добавление или удаление документов и т.д.) только по разрешению назначенных ответственных лиц.

Особого внимания заслуживают многоуровневые процессы «дедупликации» клиентских анкет или, проще говоря, механизмы поддержания целостности и уникальности досье клиента в системе. В целях контроля появления задублированных анкет клиентов решение «ЦФТ-Клиенты» оперирует гибкими настройками поиска потенциальных дублей и готовыми алгоритмами определения основного досье и слияния данных по клиенту с учетом актуальности и ссылочной целостности данных. Проверки на наличие дублей в системе осуществляются как на этапе заведения или редактирования клиентских досье, так и в любой момент времени по необходимости или расписанию.

При выделении централизованного хранилища следует также помнить о поддержке актуальности клиентских данных в других системах банка. Поскольку информация по клиенту используется в различных системах банка (фронт-офисная система, АБС, ДБО и т.д.), в системе «ЦФТ-Клиенты» реализован механизм репликации клиентов Publisher-subscriber в виде xml-файлов. Это касается ввода и (или) изменения реквизитов клиентов, добавления документов, точнее их электронных образов, нормативно-справочной информации. Впрочем, механизмы репликации, разработанные в решении «ЦФТ-Клиенты», универсальны и могут быть использованы банком для любых задач, связанных с необходимостью синхронизации данных между системами-абонентами. Еще один вариант поддержки актуальности данных в системах — по внешнему запросу — также поддерживается решением.

Выполняя функции хранилища информации, система «ЦФТ-Клиенты» является инструментом для ведения истории по каждому клиенту. Так, в системе хранятся все изменения значений реквизитов клиента, поддерживается версионность документов досье.

Система оповещения сигнализирует о том, что срок действия того или иного документа подходит к истечению и необходимо запросить новый документ у клиента.

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

Таким образом, решение «ЦФТ-Клиенты» позволяет эффективно решить вопросы по централизованному хранению и нормализации клиентских данных, что является основой для дальнейшего конфигурирования централизованного бэк-офиса банка.

Реклама

Финансовые компании находятся в поисках лучших решений, которые оптимизируют внутренние процессы разработки, разовьют IT-инфраструктуру в соответствии с требованиями бизнеса и позволят им выводить на рынок лучшие конкурентные продукты. Так, два года назад мы ступили на путь перевода разработки ЦФТ-банк на платформу CFT Platform IDE. Среди коллег по цеху ходят слухи, что это процесс невероятной сложности, ввиду чего не решаются приступить к делу. На своем примере мы докажем, что это вполне подъемный процесс и для вашей команды.

Процесс разработки ПО в НРД в большинстве случаев характерен наличием нескольких команд разработчиков, которые лавируют между проектами, занимаясь разными модулями одной или даже разных систем. В работе у нас постоянно большое количество доработок и приходится держать несколько dev и test-контуров с разными версиями системы. Таким образом, всегда есть необходимость доступа к централизованному хранилищу кода с поддержкой версионности, обеспечением автоматической сборки и установки. Для системы ЦФТ-Банк на протяжении многих лет таких возможностей не было.

Это порождало лишние затраты на подготовку сборок, merge-изменений и т.д. Часто возникали случаи порчи программного кода, т.к. следить за правильностью версиии той или иной программной компоненты могли только сами разработчики в полностью ручном режиме. Однако поменять подход к разработке для системы ЦФТ-Банк было невозможно ввиду существования безальтернативной среды разработки для этой системы, по своему интерфейсу и возможностям отставшей от жизни лет на 15.

Решение наших проблем было предложено ЦФТ с выводом на рынок в 2018 г. новой платформы разработки для своих систем, которая называется CFT Platform IDE (она же Admin 2.0, или сокращённо A2).

Ключевые отличия новой платформы разработки

Внешне разработчик получает среду, реализованную на основе Eclipse Platform, которая гораздо симпатичнее архаичного Администратора словаря данных.

Для сравнения редактирование кода в старой среде (Администратор словаря данных):

Редактирование кода в Admin 2.0:

Но основным преимуществом новой платформы разработки для нас явилась возможность хранения программного кода системы, а также экранных форм, описаний типов и прочего в виде множества текстовых файлов. Именно это позволяет выгружать код в систему контроля версий (в нашем случае Git) со всеми её возможностями, которых нам так недоставало ранее при разработке для ЦФТ-Банк.

Таким образом, разработчикам ЦФТ-Банк стала доступна возможность комфортно отслеживать историю изменений каждого объекта, включая не только время редакции, но и сравнение старой и новой версий через встроенный компонент либо с помощью любого внешнего средства типа Araxis Merge. Тому, кто не знаком с ЦФТ-Банк, это покажется удивительным, но ранее о таком приходилось только мечтать, храня историю изменений лишь в виде комментариев в коде.

Приятными бонусом послужила возможность синтаксической проверки кода без соединения с БД, а также удобная навигация (переходы в вызываемые процедуры по щелчку в месте вызова), быстрый контекстный поиск по проекту.

Отмечу, что новый админ оказался в хорошем смысле более привередлив к синтаксическим конструкциям в коде. Среди наших локальных доработок были выявлены очень странные выражения, например, что-то наподобие:

• ::MAIN_DOCUM вместо ::[MAIN_DOCUM],
• select md(md%id: rSelf) in ::[MAIN_DOCUM] all where md.[IN_FOLDER]=this bulk, причём в откомпилированном коде PL/SQL слова bulk нет, что с ним, что без него компилируется одинаково,
• Pragma macro(’Ошибка!’) вместо Pragma error(’Ошибка!’).

Непонятно, как Администратор словаря «переваривал» подобное без ошибок. Причём, если первые 2 примера представляют собой безобидный мусор, то последнее — явная ошибка, которая приведёт к некорректной работе программы.

И ещё одной особенностью Admin 2.0 является, благодаря интеграции с Git, функционал получения списка изменений на основе сравнения 2-х веток.

Это позволяет выполнять развёртывание этих изменений в целевую БД. Затем изменения из БД можно выгрузить по тому же списку элементов, используя старый Администратор проектов, в mdb-файл, если их необходимо передать для установки в БД, куда разработчик не имеет прямого доступа. Однако более интересным вариантом является подготовка и развёртывание изменений в новом формате. Он представляет из себя zip-архив, внутри которого находятся текстовые файлы с кодом, а также некоторая метаинформация. Побочным эффектом является возможность просмотреть и даже изменить код в передаваемой поставке без установки в какую-то БД, что в случае с mdb-форматом было невозможно. Но самое основное – сохранение в этот новый формат из Git-репозитория и развёртывание в БД Admin 2.0 предусматривает делать и в безинтерфейсном режиме, что позволяет настроить автосборку и автоустановку, т.е. наконец говорить о CI/СD в применении к доработкам ЦФТ-Банк. Правда, данную тему я планирую подробно раскрыть уже в следующей статье.

Особенности перехода на новую платформу

Материальный вопрос

Первое, с чем пришлось столкнуться — получение лицензий на рабочие места. На каждое рабочее место разработчика требуется отдельная лицензия, которая привязана сразу и к железу ПК, и к учётной записи пользователя. Если у вас в компании тоже несколько изолированных сетей, где есть сервера с ЦФТ-Банк, и ведётся разработка на них, то на одного разработчика потребуется купить несколько лицензий Admin 2.0. Стоимость одной лицензии на момент написания статьи составляет 125 у.е./мес., или около 8 тыс. руб. по внутреннему курсу. За первоначальную покупку на данный момент деньги не взимаются. Лицензии распространяются в виде файлов, а не смарт-ключей, что позволяет без проблем развернуть среду даже на виртуальной станции.

До покупки можно договориться о предоставлении тестовых лицензий. В нашем случае были получены 6 лицензий со сроком действия — 4 месяца на бесплатной основе. Условия обсуждаются с персональным менеджером индивидуально.

Настройка рабочих мест и БД

Серверную часть IDE можно устанавливать и в рабочее время, но правильней будет, если в момент установки не будут открыты на редактирование программные объекты ЦФТ, т.к. основное в обновлении — это новый механизм соответствующих блокировок.

Клиентская часть — это, по сути, Eclipse с расширениями CFT Platform IDE, устанавливается без прав администратора ПК. Только заранее должна быть установлена JRE не ниже 8-й версии. Доступ к обновлениям IDE на сайте ЦФТ теперь открытый, без авторизации. Можно настроить обновления непосредственно через сайт, либо из локальной сети. Например, из сетевой папки или с использованием менджера репозиториев вроде Nexus. Мы выбрали вариант сетевой папки как самый простой в настройке, не требующий доступа в Интернет со всех рабочих мест, надёжный, что важно при настройке тяжелых обновлений, и гибкий ввиду возможности выкладывать обновления по своему расписанию.

Выгрузка кода локального приложения

Для создания проекта, с которым будет работать Admin 2.0, нам нужно выгрузить из БД в папку с набором текстовых файлов описание объектов, являющихся нашими локальными доработками, а также, условно говоря, ссылки на объекты, от которых наши доработки зависят.

Отмечу, что при большом объёме локального приложения среда разработки начинает тормозить, поэтому в такой ситуации необходимо будет деление исходников на актив и архив. К счастью, в лимит мы вписались при немалом объёме локала. Однако стоит учесть объём оперативной памяти рабочих станций. Согласно документации требуется не менее 16Гб, хотя некоторое время части наших разработчиков удавалось работать и на 8Гб памяти, надо было лишь отрегулировать объём памяти java-приложения в файле eclipse.ini.

Что касается выгрузки — процедура несложная, т.к. все необходимые скрипты, такие как для подсчёта объёма приложения, для получения списка объектов и другие входят в комплект поставки.

Адаптация кода

Адаптация заключалась в дополнении того, что не собрал скрип, например, прогрузились не все ссылки на таблицы в чистом Oracle, некоторые ТБП со сложным подчинением — в единичных случаях не подгрузились типы ссылок или массивы. Также надо было слегка подчистить код (см. примеры выше). Но самое главное — подстроить код под новые особенности:

• все простые представления были автоматически преобразованы в pl/plus (т.к. работу с простыми представлениями Admin 2.0 не поддерживает). При этом нередко это происходило с ошибками, которые надо было устранять (например, т.к. вызов интерфейсных пакетов напрямую теперь не поддерживается пришлось переделать вызовы в стиле pl/sql (типа Z$MAIN_DOCUM…) на pl/plus (типа::[MAIN_DOCUM]…));
• в Admin 2.0 была исключена поддержка inline-вставок pl/sql кода — конструкции в фигурных скобках {}, и лишь недавно эту поддержку вернули;
• Admin 2.0 не поддерживает выражение between в sql запросах, которое использовалось у нас в нескольких представлениях (что странно, т.к. это стандартная конструкция, в том числе для чистого pl/sql);
• проявившиеся ошибки в «мёртвых» кусках кода. У нас было несколько процедур, где часть кода отсекалась посредством return, либо if false, или же макросом IF_DEF. Оптимизатор или макрокомпилятор отсекали код, который уже не анализировался на наличие ошибок. Некоторые такие куски стали невалидными, т.к. изменились вызываемые процедуры и используемые ТБП, просто компилятор их не видел. Admin 2.0 стал «обращать внимание» и на эти куски.

Результат

Серьёзных проблем при адаптации не было. Нам посчастливилось «познакомиться поближе» со своим кодом. В процессе мы выявили недочёты в IDE и даже в технологическом ядре (в компиляторе), которые сейчас ЦФТ уже исправил.

Большую помощь нам оказали специалисты ЦФТ, которые оперативно реагировали на возникшие проблемы, а в случае замедления процесса внедрения с нашей стороны всячески нас стимулировали и поддерживали интерес. После всех этих подготовительных действий мы запросто настроили интеграцию Eclipse с Git и выгрузили в него код текущей версии.
Нам потребовалось создать регламент ведения разработок, т.к. разработчикам ЦФТ-Банк пришлось привыкать работать совершенно в ином стиле: правильно маркировать коммиты, работать в нужной версии и пр. Сама методика работы стала соответствовать общим стандартам разработки в IT-компании.

Несмотря на первоначальное снижение скорости разработки, Admin 2.0 был сразу встречен в нашем коллективе с большим энтузиазмом. За 1-2 месяца активной работы все привыкли к новой среде, а эффективность возросла.

Сегодня Admin 2.0 до сих пор находится на стадии активных доработок, но это гораздо менее сырой продукт, чем 2 года назад. Например, только недавно появилась поддержка работы с группами доступа, пока работающая с ошибками. Также развёртывание в безинтерфейсном режиме может завершаться с ошибками при наличии в коде макросов. Большинство недочетов, которые мы фиксируем, ЦФТ устраняет в пределах месяца. За эти 2 года мы использовали отличную возможность повлиять на развитие Admin 2.0. Сегодня компании, которые задумали подобный переход, смогут пройти этот путь ощутимо быстрее.