Файл: Утверждаю Куратор проекта.doc

9.справочник контрактов;

10.справочник операций. Должен быть создан функционал (скорее всего, функционал будет реализован в виде хранимых процедур в БД Microsoft Dynamics™ AX), осуществляющий перенос указанных справочников из Microsoft Dynamics™ AX в БД BIG DATA;

11.история автомобилей;

12.история контрактов;

13.история операций;

14.история удаленных контрактов. Данные некритичны для функционирования портала. Возможно обойтись без их переноса: всё-таки откат к прежнему порталу BIG DATA стоит рассматривать только как временную меру на период, пока не будут решены проблемы с порталом BIG DATA в Microsoft Dynamics™ AX, приведшие к необходимости отката. Или их можно перенести впоследствии. Для переноса понадобится создать необходимый функционал (хранимая процедура в БД Microsoft Dynamics™ AX).

14.1.Подготовка к откату

Функционал переноса данных для отката следует реализовать после завершения активной разработки и компонентного тестирования (структура данных в Microsoft Dynamics™ AX на данный момент будет точно определена) и желательно после подготовки и обкатки функционала по миграции данных из портала BIG DATA в Microsoft Dynamics™ AX, что предположительно должно уменьшить сложность работ над функцио­налом отката.

Для тестирования правильности отката необходимо будет развернуть в тестовой среде копию БД BIG DATA и копию файлов/страниц BIG DATA портала. Развёртывание будет производится силами АргусСофт, IT1 и сотрудников отдела ИС Клиента. С помощью реализованного функционала необходимо будет перенести данные из БД Microsoft Dynamics™ AX и провести тестирование, которое будет заключаться в проверке возможности работы с данными, полученными из Microsoft Dynamics™ AX, в портале BIG DATA.

Тестирование отката на старое приложение также определит время, необходимое для ввода в строй старого приложения.

14.2.Последовательность действий при откате

1. Отключить доступ пользователей к порталу Microsoft Dynamics™ AX.

2. Произвести копирование БД BIG DATA портала.

3. Произвести перенос данных (запустить DTS-пакеты, выполнить хранимые процедуры).

4. Настроить доступ пользователей к порталу BIG DATA.

Операции проводятся силами отдела ИС Клиента и представителями IT1.

---

---

15.План миграции данных

При миграции и развертывании приложений должна также выполняться миграция следующих данных:

• 
  данные из старого BIG DATA в новый портал на основе Axapta;
  
• 
  данные в ПП – из нового портала;
  
• 
  данные в OLAP – из нового портала.
  

15.1.Требования к миграции данных BIG DATA в Axapta

Документ BIG DATA Integration to Axapta устанавливает следующие требования к переносу данных из существующего портала BIG DATA. Требуется перенести все данные с начала 2004 года, находящиеся:

16.в справочнике автомобилей;

17.справочнике дилерских центров;

18.справочнике контрактов;

19.справочнике клиентов;

20.справочнике операций;

21.истории автомобилей;

22.истории контрактов;

• 
  истории обмена автомобилей;
  

23.истории удаленных контрактов.

23.1.План миграции данных BIG DATA в Axapta

23.1.1.Справочники к переносу

Планируется переносить следующие справочники:

• 
  справочник автомобилей;
  
• 
  справочник дилерских центров;
  
• 
  справочник клиентов.
  

В Microsoft Dynamics AX в указанных справочниках в любой момент времени находится актуальная информация. Переносить из BIG DATA в Microsoft Dynamics AX эту информацию не планируется. Но в Axapta вручную для дилеров надо будет указать страну и бренд (также при реализации нужно сделать эти поля обязательными к заполнению для дилеров).

Также планируется переносить:

24.справочник контрактов. В данный момент по действующей процедуре синхронизации между порталом BIG DATA и Axapta переносятся только виртуальные контракты, понадобится создать функционал по переносу также и резервов, виртуаль­ных резервов и контрактов;

• 
  историю обмена автомобилей. История переносится (обновляется) по действующей процедуре синхронизации между порталом BIG DATA и Axapta без каких-либо изменений;
  

25.справочник операций. Необходимо реализовать функционал по переносу операций в Axapta. На сегодняшний день раз в неделю (и в начале каждого месяца) проводится процедура закрытия периода, в рамках которой производится закрытие ранее выполненных операций, после чего любые операции закрытого периода откатить уже нельзя. Если перенос данных будет осуществлён непосредственно после закрытия периода, то актуальных операций не будет. Принятие такого допущения позволит уменьшить сложность функционала по переносу операций, поскольку не будет необходимости откатывать в Axapta операции, сделанные на портале BIG DATA. Исключение – операции создания контракта и создания виртуального контракта, отменять которые можно и в закрытом периоде;

---

26.историю автомобилей;

27.историю контрактов;

28.историю удаленных контрактов. Должен быть создан функционал по переносу. Понадобится создание в Axapta нового справочника для хранения данной информации.

28.1.Подход к миграции данных

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

Перед проведением нагрузочного тестирования в тестовую среду будут перенесены данные из БД BIG DATA.

На данном этапе, помимо подготовки рабочего объёма данных для нагрузочного тестирования, мы получим общее время, требуемое для миграции данных, что понадобится для определения регламента переноса данных на рабочую версию.

Процедура миграции данных состоит из следующих шагов:

• 
  подготовить пакеты полной и частичной синхронизации из Axapta;
  
• 
  остановить работы в рабочей среде, зафиксировав таким образом данные на определенный момент времени;
  
• 
  выполнить стандартную существующую процедуру синхронизации данных. При этом в Axapta попадают не те же самые данные, которые перейдут в нее при использовании механизма миграции;
  
• 
  выполнить резервное копирование обеих БД;
  
• 
  запустить рабочие приложения;
  
• 
  восстановить из резервных копий BIG DATA и Axapta;
  
• 
  к Axapta применить дополнительно процедуру миграции приложения;
  
• 
  выполнить процедуру миграции данных BIG DATA в Axapta.
  

Упрощенно порядок миграции данных представлен на картинке.

29.Контроль миграции данных

29.1.Контроль миграции BIG DATA в Axapta

Основная цель процедуры: убедиться, что миграция BIG DATA в Axapta работает корректно.

Вторичная цель: снизить вероятность того, что при переносе данных из БД на портал были допущены ошибки в алгоритмах. А также снизить вероятность того, что данные для визуализации были взяты не из тех источников. Этот риск возможен потому, что БД обеих систем денормализованы.

29.1.1.Первичный контроль

Усилиями основного подрядчика (IT1) создается функциональный дизайн, который фиксирует:

---

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

Документ согласуется с АргусСофт. На основе этих спецификаций оба подрядчика разрабатывают процедуры выгрузки показателей контроля в файл специфицированного формата.

После выполнения миграции данных из BIG DATA в Axapta процедуры выгрузки запускаются в обеих системах. Результаты предоставляются эксперту проекта.

Эксперт проекта выделяет из набора данных агрегированные показатели контроля (их не так много). По агрегированным показателям он выполняет ручной контроль путем сравнения этих данных в двух файлах. Форматы файла идентичны.

Детальные показатели контроля с помощью специальной утилиты Oracle и системного администратора сравниваются автоматически посредством вычитания. Эксперт получает результат сравнения и определяет корректность данных.

29.1.2.Вторичный контроль

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

Будут сравниваться:

1. 
   выгрузка из BIG DATA с выгрузкой из Axapta;
   
2. 
   выгрузка из BIG DATA с выгрузкой из БД BIG DATA;
   
3. 
   выгрузка из Axapta с выгрузкой из БД Axapta.
   

29.1.3.Схема процесса

29.2.Контроль миграции источника данных плазменных панелей

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

Процедура контроля должна проводиться после выполнения миграции данных BIG DATA в Axapta и процедуры контроля ее корректности.

Процедура состоит из следующих шагов:

• 
  в тестовой среде¹ необходимо поднять два тестовых приложения ПП и две тестовые БД ПП;
  
• 
  в одну тестовую систему синхронизировать данные из BIG DATA. При этом будет использоваться существующий механизм;
  
• 
  в другую тестовую систему синхронизировать данные из Axapta. При этом будет использоваться новый механизм. Корректную работу этого механизма и надлежит проверить;
  
• 
  данные сравниваются визуально через Internet Explorer экспертом проекта. Ввиду небольшого объема данных автоматизировать сравнение нет смысла.
  

---