Welcome to MSDN Blogs Sign in | Join | Help

В предыдущей статье шла речь о работе утилиты тестирования производительности (BM) для Microsoft Dynamics AX, код стандартных примеров для которой был создан с помощью Microsoft Dynamics AX Object Wrapper (далее - AX Wrapper).   

 

AX Wrapper позволяет использовать уже существующие объекты Microsoft Dynamics AX и построить их вызов и обработку из Visual Studio.  AX Wrapper можно найти в стандартной поставке BM, в каталоге ProgrammingModel. Его использование довольно подробно рассмотрено в документации по BM.

При использовании мастера настройки AX Wrapper подразумевается, что поле 'Object Server' будет содержать строку, соответствующую значению строки доступа к AOS в конфигурационном файле, например 'bm@mow-mbs-2:2713'.

image

После прохождения мастера в проект Visual Studio будут добавлены интерфейсы ('wrappers') на C# для выбранных объектов из AOT (классы, перечислимые типы или таблицы). Интерфейсы позволяют получить доступ к объектам и обрабатывать исключения со стороны Visual Studio.

Надо помнить, что интерфейсы обращаются к объектам по имени, например к полям.

image

Внутри же Dynamics AX обращения и ссылки работают по идентификаторам объектов (Id). При переименовании объекта в AX придется искать и править код и в Visual Studio.

 

Данная статья подготовлена с помощью Windows Live Writer.

Тестирование производительности в DAX 3.0 в основном заключалось в использовании внутреннего модуля Benchmark (BM). У него были достоинства, были и недостатки.

В качестве серьезных недостатков могу привести невозможность использования реальных данных для тестирования и процесс записи данных тестирования/логов в собственную базу данных, что на больших тестах приводит к резкому росту отдельных таблиц. Процесс работы с ключами по ссылкам подразумевал сгенерированные данные, причем генерация должна была проводиться самим BM.

Расширение данного модуля требовало некоторых усилий, поскольку идеологически он был неким 'чужеродным' элементом в структуре модулей. С другой стороны, разобравшись с BM, можно было достаточно хорошо понять как работает Microsoft Dynamics AX 3.0 с точки зрения дизайна отдельных модулей.

 

В версии 4 изменилась схема имитаций действий пользователей, теперь запуск объектов Microsoft Dynamics AX выполняется из внешней среды с помощью средств Visual Studio (агент и котроллер) и Microsoft Dynamics AX Business Connector (COM и .NET).  Этим достигается определенный уровень универсализма, когда с помощью утилиты и Business Connector можно тестировать как объекты Microsoft Dynamics AX, так и сценарии работы с AIF (например, с BizTalk) или производительность веб-интерфейсов (Корпоративного Портала, например). 

Впрочем, идея почти та же, - запускаем некий агент на компьютерах-клиентах (серверах приложений) и контроллер на одном из компьютеров для управления ими, а также последующего сбора статистики.

Агенты через Business Connector (COM или .NET, в зависимости от настройки контекста) запускают объекты Microsoft Dynamics AX согласно сценарию.

 

Естественно, запустить выполнение формы или другого интерактивного объекта сложно, приходится эмулировать (повторять) поведение формы в других элементах Microsoft Dynamics AX, либо в коде Visual Studio.

Вообще-то, в BM версии DAX 3.0 в так называемом режиме 'Display independent' тоже запускались специальные классы, в которых эмулировалось поведение форм. Суффикс 'Batch' использовался для классов не интерактивного запуска, 'Display' - для запуска классов с формами и диалогами.

Строго говоря, вынос активных действий с интерактивных элементов (формы и диалоги) наметился в DAX 2.5 и получил развитие и для стандартной версии. Примерами могут служить классы поддержки форм журналов, например JournalFormTable и связанные с ним. Также начался вынос методов с форм на источники данных и таблицы.

 

Итак, новая утилита версии 4.0. 

Поскольку в стандартной поставке есть примеры для процесса разноски заказов на продажу (Sales Orders, SO), попробуем его настроить и запустить. Причем запустить 'малой кровью', не сильно вдаваясь в детали и по-минимуму изменяя настройки и код. 

Установил Visual Studio Team Suite (VSTS) как описано в документации.

Для работы понадобится еще Team Test Load Agent Controller и Team Test Load Agent, которые поставляются отдельно.

image

 

Запустил предоставляемый файл и распаковал все в C:\Benchmark.

Скопировал из каталога SalesAndDistribution файлы VSTestHost.exe.config в %Program Files%\Microsoft Visual Studio 8\Common7\IDE и QTAgent.exe.config в %Program Files%\Microsoft Visual Studio 2005 Team Test Load Agent\LoadTest.

Открыл каталог \bin и настроил все запускаемые файлы cmd на пути и сервера, которые есть у меня.

 

Открыл проект Benchmark.sln и пошел по шагам, описанным в 'Microsoft Dynamics AX Benchmark Toolkit Installation.doc':

  • Нажал  Build\Build the Solution (release).
  • Модифицировал setenv.cmd.
  • Отредактировал файлы настроек в \SalesAndDistribution

image 

  • Несмотря на то, что все запускается на одном и том же компьютере, настроил агента и контоллер, как удаленные.
  • Открыл Visual Studio 2005 Command Prompt.
  • Запустил deploy.cmd. 

image

  • Запустил runtest.cmd.

image

Ага, ругается, надо существующие данные в шаблоны экспортировать, как минимум список клиентов не совпадает :)

Создал группы определения для экспорта/импорта типа "Excel" и экспортировал реальные данные компании в документы каталога Datasource.

Попробую запустить тест. Копирую SalesAndDistribution.loadtest в Microsoft.Dynamics.Benchmark.TestProject, хотя ... можно было просто пути в cmd подправить.

Ок, поправил, пробую опять... 

За активностью можно следить как со стороны AX:

image

так и со стороны Visual Studio:

image

Ух, что-то выполнилось!

 image

Пойду смотреть логи.

В каталоге Results (в моем случае - C:\Results) можно найти текстовый файл LoadTest.log, описывающий что же собственно запускалось:

image

В каталоге Bin\Results (в моем случае - C:\Benchmark\Bin\Results) можно найти файл с расширением trx, который содержит значения счетчиков, настроенных для теста. Открыть его можно и в Visual Studio:

image

Хм, машинка слаба, загрузка процессоров слишком большая. Надо искать другой сервер? :)

 

Резюме:

  • Внимательно анализируйте установки и пути для копирования и запуска скриптов;
  • Если используете стандартные скрипты - установите все в каталог Benchmark;
  • Помните, что для запуска тестирования необходимо дополнительно установить Visual Studio Team Test Load Agent;
  • Генерация случайного выбора из справочников требует подготовленных данных - значений ключей ("E"+ числовое значение, преобразованное в строку);
  • Для работы можно использовать VSTS 2008 c Load Agent, если нет пробной версии VSTS 2005.

 

Теперь немного о самом модуле BM в DAX 4.

Часто слышу: "Как его использовать, он же бета?".  Данный модуль бета был оставлен для того, чтобы собрать как можно больше отзывов; бета стабильна и используется партнерами. Документация есть, хотя немного путанная. Судя по всему, BM в ближайшее время останется бетой.

Собственно, в DAX 3.0 BM был тоже своего рода вечной бетой, но вполне работоспособной. Более того, тестирование производительности не относится к модулям бизнес-процессов, сценарии (и, как правило, код) необходимо все равно изменять для модификаций или локализации.

Если Вы не собираетесь использовать BM даже в отдаленном будущем, имеет смысл прочитать его документацию, чтобы узнать побольше о Microsoft Dynamics AX Object Wrapper (о нем -  в следующей статье). Это может сильно облегчить переход к программированию в двух средах: AX и Visual Studio, поскольку интеграция становится все теснее... 

 

Данная статья подготовлена с помощью Windows Live Writer.

Вопросы с лицензированием портала продожаются сколько бы не писал (смотри  статью "О лицензиях COM и порталов").

Попробую описать подробнее.

 

С технической точки зрения, возможно использование Корпоративного Портал (Enterprise Portal Framework) без веб - пользователей (Web users), однако с точки зрения лицензии веб - пользователи необходимы для соответствия лицензионному соглашению. 

 

Для существующих клиентов использующих лицензирование по модулям (Module Based Licensing):

  • Требуется лицензия на Корпоративный Портал;
  • Требуется лицензия на 25 конкурентных веб - пользователей (Web users) как минимум; 
  • Требуется лицензия на один бизнес-коннектор (Business Connector, он же - клиент COM), связанный с Корпоративным Порталом;
  • Требуется лицензия на дополнительных клиентов COM, в зависимости от количества уникальных профилей / ролей (профили, имеющие различные настройки доступа к системе с точки зрения прав, в том числе и к данным). Например, если 100 веб-пользователей нуждаются в доступе к одним и тем же данным с одними правами, требуется только один Business Connector, если каждый из 100 веб-пользователей требует уникального доступа к данным, тогда необходимо 100 Business Connectors.

 

Существующие или новые клиенты, использующие бизнес - лицензирование (Business Ready Licensing):

  • Требуется одна лицензия Microsoft Dynamics Client for Microsoft Office (DCO) для каждого именованного пользователя AX, работающего через Web;
  • DCO включает в себя Корпоративный Портал (Enterprise Portal Framework), одного веб пользователя (Web user) + один бизнес-коннектор (Business Connector) для каждого именованного пользователя AX;
  • DCO доступен только для клиентов, имеющих расширенную лицензию  (Advanced Management)  и не доступен в случае базовой (Business Essentials).

 

Данная статья подготовлена с помощью Windows Live Writer.

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

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

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

 

В версии 2009 эти проблемы решили введением нового типа данных DateTime. Были разработы новые функции (фактически - интерфейс) взаимодействия с этим типом данных, которые в частности позволяют добавлять и удалять смещения относительно DateTime.

При использовании DataTime локальное время машины не используется, текущие типы даты (Date) и времени (Time) останутся как есть с ‘локальной’ семантикой.

В данном решении реализована поддержка семантики UTC для X++, доступа к данным и базе данных.

Общее правило для типов данных Date и Time:

  • Не используйте, если необходима поддержка временных зон
  • При переносе данных будут обновлены до UTC автоматически относительно текущей зоны

Соотвественно, при обновлении произойдет конвертация данных:

  • CreateDate и CreateTime - в CreateDateTime
  • ModifiedDate и ModifiedTime - в ModifiedDateTime

 

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

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

 

Данная статья подготовлена с помощью Windows Live Writer.

Видео с CES 2008, ссылка http://www.istartedsomething.com/20080107/bill-gates-last-day-microsoft-video/ 

Yeah, «magic of software» :)

0 Comments
Filed under:

DAX 2009 позволяет осуществлять доступ к авторизированным данным всех компаний из форм, запросов и кода X++. Поддерживаются все типы источников данных, включая табличные коллекции и представления. Правда не поддерживаются базовые структуры типа RecordInsertList и RecordSortedList.

С точки зрения изменений в коде введены новые ключевые слова в X++ и параметры структур запросов.

Новое ключевое слово для работы с компаниями в X++:

select crosscompany custTable // выборка по всем компаниям
       join custTrans
       where custTable.AccountNum == custTrans.AccountNum;

Есть возможность фильтрации в запросе с помощью контейнеров:

CustTable custTable;
Container companies;
;
companies = ["DMO", "DAT"];  // контейнер

while select crosscompany: companies  * from custTable // фильтрация
{

   ...
}

Произошли изменения работе с запросами, добавлен параметр работы с несколькими компаниями, AllowCrossCompany (Yes, No) в AOT и структуре запросов, использовать его можно, например, так:

Query     qr = new Query();

qr.allowCrossCompany(‘True’); // 'false' является умолчательным

Получить текущее значение фильтра по компаниям, изменить и очистить его можно следующим образом:

Query     qr = new Query();
container cons;
;
cons = qr.getCompanyRange();     
// компании в обработке

qr.addCompanyRange(‘DAT’);         // добавление компании в фильтр

qr.clearCompanyRange();              // очистка списка

 

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

image

 

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

   CustTable ct;
    ttsbegin;
    while select forupdate crosscompany ct
    {
        changecompany(ct.company())
        {
            ct.CreditMax += 10;
            ct.update();
        }
    }
    ttscommit;

В коде, указанном выше, используется метод company() для идентификации текущей компании. Естественно можно было бы использовать и поле DataAreaId в качестве идентификатора, подставив ct.DataAreaId в функцию changecompany. Разница же в том, что в случае табличной коллекции, company()  вернет правильный идентификатор реальной компании, а DataAreaID будет содержать значение/идентификатор виртуальной компании или реальной компании в зависимости от типа источника данных.

 

Данная статья подготовлена с помощью Windows Live Writer.

Вообще-то, изменения между версиями можно характеризовать так:

  • 3.0 -> 4.0 Платформенные (технологические) изменения, развитие функциональности
  • 4.0 -> 5.0 (2009) Функциональные изменения, развитие платформенных решений

В данной статье посмотрим некоторые отличия во взаимодействии с базами данных.

 

Появилась поддержка сложных структур запросов, т.е. возможность создавать объединения не только типа родитель - наследник, но и более сложные, правда такие объединения можно делать только в структурах запросов.

Реализована поддержка union, правда не в коде X++, а только для структур запросов, например:

  query = new Query();
   query.queryType(QueryType::Union); // другим значением QueryType является "Join"

Появилась поддержка Inner join и outer join в UPDATE_RECORDSET, а также возможность возврата количества обработанных записей для UPDATE_RECORDSET и DELETE_FROM, например:

update_recordset batchJob setting
      Status = BatchStatus::Canceled,
      EndDateTime = thisDate,
      Finishing = 1
  where batchJob.Status == BatchStatus::Cancelling
  notexists join batch
  where (
          (batch.Status == BatchStatus::Ready
              || batch.Status == BatchStatus::Executing
              || batch.Status == BatchStatus::Hold
              || batch.Status == BatchStatus::Cancelling)
          && batch.BatchJobId == batchJob.RecId
          );

  rowsUpdated = (batchJob.RowCount() > 0); // использование rowCount()

 

Реализована обработка исключений при дублировании уникального ключа, например: 

   Table t;

   try
   {
       while select forupdate t
       {
           test.Field1 = ‘xyz’;
           t.update();
       }
   }

   catch ( Exception::DuplicateKeyException, t )
   {
       infolog(‘Запись уже существует‘ + t.Field1 );
   }

 

С точки зрения обмена данными между клиентом, сервером приложений и базы данных изменения коснулись также RunBase (уменьшение трафика при инициализации и упаковке), NumberSequences и дисплей-методов. Улучшение работы с дисплей-методами подразумевает их расчет в пакетном режиме на сервере и сохранении результата на клиенте, это выгодно отличается от текущей реализации с последовательным расчетом и передачей с сервера на клиента каждого метода.  

 

Данная статья подготовлена с помощью Windows Live Writer.

В наступившем году нас ждет встреча с Microsoft Dynamics 2009. Версия 5.0 будет переименована для соответствия общей политике наименования продуктов. При этом 2009 не означает перенос выпуска версии на 2009 год, просто версия системы выйдет во второй половине 2008 года.

Данной статьей хотелось бы начать цикл статей о том, что интересного будет в Microsoft Dynamics 2009. Данная версия Microsoft Dynamics AX будет фактически второй, выпущенной полностью компанией Microsoft, и будет развивать тенденции и платформенные особенности версии 4.0.

 

Для начала, сильно изменился интерфейс системы. Появилась домашняя страница сотрудника, создано более 30 ролей сотрудников, появились так называемые 'ленты' (ribbons), выгрузка практически любой информации в Excel и многое другое.

 

Что было в версии 4.0?

image

Что стало в версии 2009?

image

 image

 

Появились новые возможности фильтрации и визуализации:

image

image

 

В целом, интерфейс стал очень похож на интерфейс Microsoft Office 2007, в частности Outlook.

 

Данная статья подготовлена с помощью Windows Live Writer.

Начиная с версии 4.0 для Microsoft Dynamics AX существует внешняя утилита трассировки кода и запросов. Скачать ее можно с PartnerSource.

Утилита предназначена для замены Профайлера кода и Трассировки запросов SQL, сохранившихся с предыдущих версиий в Microsoft Dynamics AX 4.0.

 

Для чего потребовалась внешняя утилита, ведь Профайлер и Трассировка запросов по-прежнему могут использоваться? Дело в том, что внутренние утилиты никак нельзя было назвать "легкими", они генерировали достаточно большой объем данных и складывали его в ту же базу данных, которая использовалась и экземпляром Microsoft Dynamics AX 4.0. В данной статье не рассматриваются внутренние утилиты Профайлера кода и Трассировки запросов SQL.

 

В отличие от внутренних утилит, Trace parser нагружает анализируемую систему максимум на 4%. Trace parser позволяет анализировать файлы логов размерностью до 10Гб, а также сводить в одном месте данные по трассировке запросов RPC, запросов к данным на стороне SQL Server и исполнению кода X++.

Утилита существует в бета-версии, поскольку пока нет планов ее официальной поддержки через обычный канал службы поддержки для Microsoft Dynamics AX 4.0 (версий утилиты до 5.0).

 

Установка проста, нужно указать папку куда складывать данные логов и базу данных для создания представлений. При необходимости анализа ситуации "на лету", можно установить и интеграцию с клиентом Microsoft Dynamics AX. В последнем случае, запустится клиент Microsoft Dynamics AX для импорта требуемых объектов.

image

До установки проверьте наличие .NET Framework 3.0.

 

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

image

 

Теперь включаем трассировку и на клиенте:

image

 

Создаем журнал ГК и разносим его.

Файлы логов сервера и клиента копируем в папку Trace Parcer (в моем случае - C:\AX Trace\Logs\Unprocessed). Хотя это и необязательно, облегчает администрирование.

Импортируем логи:

image

 

Теперь в Trace Analyzer можно открыть лог и начать его анализ. Например, найдем вызовы методов класса LedgerJournalCheckPost, выберем метод.

image

Затем можно нажать кнопку "Jump to Callstack", чтобы посмотреть код.

image

Утилита анализа довольная проста и понятна, особенно тем, кто ранее имел дело с внутренними утилитами Профайлера кода и Трассировки запросов SQL. Имеются развитые средства поиска, описанные в документации.

 

Что в документации не описанно или недостаточно детализированно, так это описание вызовов RPC:

Метод Описание
[Client\Server]EvalFunc Оценка функции на другом уровне (для клиента – на серверном уровне)
[Client\Server]FreeClass Освобождение объекта на другом уровне
ServerNext Операции доступа к данным или манипуляций с данными со стороны клиента
ServerWriteBegin Вызов TTSBegin на клиенте
ServerWriteEnd Вызов TTSCommit\TTSAbort на клиенте
[Client\Server]DestructCursor Очистка буфера записи на другом уровне
[Client\Server]UpdateDirtyCursor Обновление буфера записи на другом уровне с новой информацией
ServerRecordInsertList Вызов операции вставки записей с использованием RecordInsertList со стороны клиента
[Client\Server]SetClassLoopDependencies Увеличение счетчика ссылок к объекту на другом уровне
[Client\Server]TestClassLoopDependencies Запрос к другому уровню с целью проверки статуса объекта и его освобождению, если таковое возможно

 

Данная статья подготовлена с помощью Windows Live Writer.

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

 

Речь пойдет о лицензировании клиентского доступа для Microsoft SQL Server 2005 в случае его использования с Microsoft Dynamics AX.

Для SQL Server 2005 предлагается как модель лицензирования на процессор, так и модель лицензирования с использованием серверных и клиентских (Client Access License или CAL)  лицензий. Выбор той или иной модели лицензирования зависит от потребностей клиента.

 

Если по пользователям (рекомендуется для менее 75 пользователей на физический процессор), то количество CAL для SQL равно количеству конкурентных пользователей AX. Сессии, создаваемые тем же клиентом AX (стандартно – до 4-х) идут как одна. Если пользователь открыл несколько клиентов AX, например 2 - считается как 2 CAL. Детали тут: http://www.microsoft.com/sql/howtobuy/serverpluscal.mspx

Если же на сервере баз данных живет только AX, можно использовать SQL Server Runtime:

  • “SQL Server Runtime is a license that allows an independent software vendor (ISV) to embed the complete SQL Server code into its solution for use only by the ISV's application. The customer of the ISV is restricted from using this SQL Server product to run other applications or to develop new applications, databases, or tables.”
  • “If you want to license additional Users in Microsoft Dynamics you can do that at any point in time. Just remember you have to a SQL Server – Runtime license for every person who accesses the system. ”

 

Также если пользователей много и там не только AX – имеет смысл выбирать модель лицензирования по процессорам.

В случае IIS лучше также идти по процессорам.

 

Ответы - отсюда: http://www.microsoft.com/sql/howtobuy/faq.mspx

Документ – здесь http://www.microsoft.com/sql/howtobuy/sqlserverlicensing.mspx

Описание принципов лицензирования на русском языке -  http://www.microsoft.com/rus/licensing/products/server/sql_server2005.mspx

Появился мастер импорта Performance Point 2007 для Microsoft Dynamics AX. Утилиту можно найти по ссылке: http://www.microsoft.com/downloads/details.aspx?familyid=8847B2B5-BD73-49F6-A78E-2F1D1674429E&displaylang=en

 

Процесс выглядит примерно так:

clip_image001

 

Описание интеграции можно найти здесь (на английском): http://www.microsoft.com/dynamics/ax/product/sharepointintegration.mspx

Вроде простейшая операция, а при получении вопроса по теме невольно ищешь подвох :)

 

static void Job1(Args _args)

{

    #AOT

    Job j2 = TreeNode::findNode(#JobsPath + '\\Job2'); // 'Job2' - вызываемый скрипт

    ;

    j2.AOTrun();

}

static void Job2(Args _args)

{

;

    print 'Hello world from JOB2';

    pause;

}

Разбирая завалы, нашел старый экспортный файл с реализацией поиска по всем таблицам в строковых полях. Понятно, что он уже не актуален, при наличие средств глобального поиска, но когда-то был нужен :)

 

static void findStrInAllTables(Args _args)
{
    Dictionary  dictionary;
    DictTable   dictTable;
    DictField   dictField;

    Dialog      dlg;
    DialogGroup dlgg;
    DialogField dlgf;

    Common      common;

    int         i, cnt, ret, res;
    str         fieldValue, findStr;
    ;

    dlg    = new Dialog("Поиск по всем полям");
    dlgg   = dlg.addGroup("Критерий");
    dlgf   = dlg.addField(typeid(Name), "Строка поиска");

    dlgg.columns(2);

    if (! dlg.run())
        return;

    findStr = dlgf.value(); // Нашли что искать будем

    dictionary = new Dictionary();

    setPrefix("Поиск соответствия");

    for (i=1; i<=dictionary.tableCnt(); i++)
    {
        dictTable = new DictTable(dictionary.tableCnt2Id(i));
        common    = dictTable.makeRecord();
        res       = 0;

        // Для каждой записи
        while select common
        {
            // Перебор полей для таблицы
            for (cnt=1; cnt<=dictTable.fieldCnt(); cnt++)
            {
                // Получение идентификатора поля
                dictField = new DictField(dictTable.id(),
                                fieldId2Ext(dictTable.fieldCnt2Id(cnt),1));

                if (dictField.baseType() == Types::String)
                {
                    fieldValue = common.(dictField.id());
                    ret        = strscan(fieldValue, findStr, 1, strlen(fieldValue));

                    if (ret)
                    {
                        // Вывод названия поля и его значения
                        info(strfmt("%1 : %2 : %3", dictTable.name(),
                                                    dictField.name(),
                                                    fieldValue));
                        res++;
                    }
                }
            }
        }

        print "Обработана таблица " + dictTable.name() +
                (res ? ("               Соответствий " + int2str(res)) : "");

        //Для тестирования только 100 таблиц
        //if (i > 100)
        //    break;
    }
}

В следующем календарном году ожидается выход следующей версии Microsoft SQL Server - 2008. Собственно, она уже доступна в бета версии SQL Server 2008 Community Technology Preview (CTP).

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

Текущая версия DAX поддерживает Microsoft SQL Server 2008 для своей собственной базы данных, содержащей собственно данные компаний.

Однако, прочие возможности DAX, такие как Корпоративный портал, зависящие от их реализации на Windows Sharepoint Services (WSS) или Microsoft Office Sharepoint Server (MOSS) требуют отдельную базу данных, которую необходимо развертывать на Microsoft SQL Server 2005, поскольку пока нет (в бета версии) реализации WSS/MOSS на Microsoft SQL Server 2008.

Если все разворачивается на одном физическом сервере, придется ставить 2 экземпляра Microsoft SQL Server упомянутых версий.

Пока планы реализации полной поддержки Microsoft SQL Server 2008  со стороны DAX: DAX 4.0SP3 и DAX 5.0. Это не есть гарантия, но скорее всего так и будет.      

 

Данная статья подготовлена с помощью Windows Live Writer.

Зачастую возникают опасения по поводу интеграции DAX и BizTalk, особенно в части получения больших XML документов на стороне DAX.

Например, клиенты могут опасаться, что BizTalk - адаптер для DAX использует MSMQ, где существует ограничение по объему документа.

Или, например, клиенты могут переносить свой опыт использования интеграции с BizTalk с DAX 3 на DAX 4. В DAX 3 было ограничение примерно в 5Мб для размера документа.

 

BizTalk - адаптер  в DAX 4 не использует MSMQ, соответственно нет и причин для опасений в этом случае.

Сравнивать DAX 3 и DAX 4 не совсем корректно, поскольку адаптер BizTalk появился в DAX 4 и его не было ранее в DAX 3.

С точки зрения импорта документов, официального ограничения как такового нет, но в реальности разработчиками среды интеграции AIF тестировались документы только в 10Мб (что может составлять 5Мб в 16-бит кодировке XML) и менее.

Однако, с момента выхода версии DAX 4.0SP1 (где собственно и появился адаптер) прошло уже достаточное количество времени, но проблем с размерностью документов пока не выявлено.

 

Данная статья подготовлена с помощью Windows Live Writer.

More Posts Next page »
 
Page view tracker