Выборка данных через AOS vs SQL Server

[lev]

Цитата:

Сообщение от mazzy

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

полностью согласен! ведь народ который использует эту программу, пользуется механизмами, которые написаны в самой аксапте, на Х++. А не внешними программами, которые написанны (+ ко всему) на других языках.
что собственно mazzy уже не в первом посте пытается донести!

[mazzy]

Цитата:

Сообщение от sukhanchik

Хотя за этот многочисленный распил таблиц на более мелкие - тоже б руки оторвал.

С этим хоть понятно.
Они начинают сталкиваться с ограничением 8Кб в странице SQL-сервера, с ограничением на размер индексов и с ограничением на размер буфера в самой аксапте. (Если включены все опции)
Поэтому "распил" хоть как-то объяснить можно.

В 2009 процесс пошел дальше. Готовься

[fed]

Цитата:

Сообщение от mazzy

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


но чего ни в коем случае не должны делать разработчики - придумывать совсем другой механизм доступа к данным!

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ? Что мы проверим - генерацию recid, способность подставлять dataAreaId в записи, работу RLS ? Стоит ли гемор с работой через .net bc, столь скромных результатов ?
Все равно те данные которые мы читаем и пишем имеют мало отношения к реальности и мало чего позволяют оттестировать. Это же юнит-тест, просто ловушка для глупых ляпов. Тупо табличку записали, потом тупо прочитали...
Комплексного тестирования юнит-тесты не заменяют, и смысла из юнит-теста пытаться сделать универсальный тест и для ядра и для .net bc и для злосчастной логистики я не вижу...
Просто по хорошему после юнит-тестов время от времени должен проходить комплексный тест (уже не автоматический), а живыми людми делаемый. И боюсь как раз с этим-то в разработке аксапты и нехорошо....

[fed]

Цитата:

Сообщение от lev

полностью согласен! ведь народ который использует эту программу, пользуется механизмами, которые написаны в самой аксапте, на Х++. А не внешними программами, которые написанны (+ ко всему) на других языках.
что собственно mazzy уже не в первом посте пытается донести!

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов
Забудтье про клиентов и партнеров - это юнит-тесты. Такого на реальных внедрениях не бывает...

[mazzy]

Цитата:

Сообщение от fed

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ?

Ты перечитай какие параметры должны учитываться в этом "тупом перенесении данных" и "тупом вынимании"
Выборка данных через AOS vs SQL Server

либо придется генерить кучу наборов данных (во что лично я не верю).
либо использовать таки механизм Аксапты с разные настройками самой Аксапты (хотя бы в вариантах лицензий BE и AM) с одним и тем же набором данных.

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

Выбор "тупого варианта" автоматически означает, что не будет протестированы аспекты, связанные с кэшированием. а также куча других аспектов.

Конечно хоть какое-то тестирование лучше, чем никакого.
Но я сильно опасаюсь, что выбрав "тупой вариант" разработчики остановятся и будут рапортовать "ошибок нет". А на самом деле ошибки просто останутся невыявленными.

[Ivanhoe]

Цитата:

Сообщение от mazzy

Локальный - на Навике (по слухам).
В полном соответствии со своими же рекомендациями по выбору систем.

Вроде бы, был пресс-релиз, что локальный кадровый учет и расчет ЗП на Dynamics AX сделан?

[mazzy]

Цитата:

Сообщение от fed

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов
Забудтье про клиентов и партнеров - это юнит-тесты. Такого на реальных внедрениях не бывает...

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

у нас обычно есть настроенная компания-шаблон, в которой по результатам тестирования настройки меняются.

мы много раз копируем эту компанию и выполняем заранее записанную последовательность действий (разносим документы, выполняем периодические операции). После чего проверяем заранее определенные ожидаемые параметры и результаты. Меняем настройки в шаблонной и снова копируем.

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

Если бы встроенный в Аксапту модуль unitTest умел бы работать именно так, то я был бы щастлив.

[mazzy]

Цитата:

Сообщение от Ivanhoe

Вроде бы, был пресс-релиз, что локальный кадровый учет и расчет ЗП на Dynamics AX сделан?

Хм... почти так. На Dynamics.
Вот только я не помню двух буковок "AX"

В общем, конечно в этом вопросе, возможно, я не прав.
Сразу так и написал - "по слухам".

[lev]

Цитата:

Сообщение от fed

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов

Ну например розничная торговля:
Есть сеть магазинов, например 50, есть РЦ. В каждом магазине заказывается товар, возьмем например Масло подсолнечное. Соответственно у каждого магазина примерно известно кол-во потребляемого масла, и по потребностям магазина делается закупка на РЦ. При физ разноске закупки на РЦ автоматом формируются Заказы на Розничного клиента с разными складами (каждый склад, свой магазин).
Так как потребность у магазина постоянно примерно одинаковая (не считая сезонные всплески\падения по отдельным позициям), Вот и получается: "много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов" как то так...

P.S. ещё добавлю. А если магазинов не 50, а 1000 и эти магазины разбиты по менеджерам по 100-штук например. То получаем что 10 пользователей одновременно для 1000 магазинов(клиентов) вставляют записи в таблички salesTable\salesLine

[George Nordic]

Цитата:

Сообщение от sukhanchik

А ничто не мешает их использовать в собственной работе. Например, для сдачи собственной же отчетности в нашу (РФ) налоговую .
Пусть у локального офиса будет своя компания, а у штаб-квартиры - своя - посмотрим как там трансляция работает .Другое дело - что у МСа АХ не единственная система (GP, SL, NAV еще есть).

Корпоративной системой финансового учета в Microsoft является SAP. Это ни для кого не секрет. Как и то, что CRM - от Oracle (которому пытаются натянуть интерфейс от MS CRM, а впоследствии и полностью на него заменить)

Цитата:

Сообщение от mazzy

Хм... почти так. На Dynamics.
Вот только я не помню двух буковок "AX"

А вот зря - расчеты с персоналом как раз в Dynamics AX. Внедряли коллеги из АНД:

Цитата:

Проект внедрения решения на базе Microsoft Dynamics AX был реализован специалистами департамента консалтинга и технической поддержки корпоративных заказчиков Microsoft в России при поддержке компании «АНД Проджект» – партнера Microsoft по направлению Microsoft Dynamics. В рамках проекта были развернуты модули кадрового учета и расчета заработной платы Microsoft Dynamics AX, внедрена функциональность формирования и ведения штатного расписания, ведения персонифицированного учета в соответствии с требованиями российского законодательства, учета распоряжений по персоналу, хранения конфиденциальной информации о сотрудниках, расчета заработной платы и налогов с доходов сотрудников.

http://www.andproject.ru/news/162.html

С Уважением,
Георгий

[Evgeniy2020]

а в чем проблема?

если AOT объекты, совместно со всеми настройками,
ключами, RLS, и т.д. переведут в ms sql server

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

это в текущей версии много чего находится в Аксапте,
а если АОТ объекты (application objects)
со всеми конф. ключами, RLS перегонят в MS SQL Server

то я думаю можно сделать движок напрямую который будет считывать
правильно сущности с учетом прав, филдов, rls

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

считать пару строк не проблема. а 10 млн строк ))

тогда это будет немного похоже на 1С подход,
при котором

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

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

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

а вообще можно было бы сделать обертку и движок на MS SQL
чтобы он веб интерфейс создавал прямо у себя, и клиент получал порцию уже готовую для отображения,

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

а еще можно сделать язык смешанный
c# + T-SQL
такой, что всю бизнес логику можно было бы хранить прямо на сервере MS SQL
тогда клиентов можно сделать весьма тонкими,
а трафик вообще не гонять между AOS - MS SQL
все будет крутится в MS SQL

бизнес логика которая прямо будет в базе хранится,
зачем тогда далеко считывать все, досаточно будет 128 GB ОЗУ
на MS SQL Server там все и крутится и хранится,
и скорость будет зашибительная
почти никакого трафика,

а уже отображения результатов на клиенте,
то есть чуть ли не html поток или xml
тогда клиентом к такой erp
может быть IE, Excel, Biztalk, или некий родной клиент аксапты,

скорости обработки будут высокими,
все метаданные, правила, ключи, rls, application objects будут в MS SQL
будет супер производительность

только при таком подходе сама Аксапта пропадет,
ее переварит MS SQL
получится MS C# SQL Advanced Business Server
то есть MS SQL сервер с оболочкой для разработки и бизнес логикой которая рядом с данными

тогда AX rip

при таком подходе можно будет управлять erp системой с ipad
просо мега сервер 16 процессоров + 128 GB памяти
внутри него и данные и бизнес логика и ключи и rls и olap

а с ipad можно делать что угодно и быстро, и красиво получать любую картинку

Вот если бы меня пригласили архитектором в Редмонд
там бы я напроектировал правильную ERP систему ))

MS SQL + Business logic
Database services
Reporting services
OLAP services
Business logic services (ERP объекты CRM объекты, application logic, conf.keys, seq keys, rls, C# + T-SQL, репозиторий)
Source safe services
Presentation Services (это потоки данных под различных клиентов ie,excel,biztalk,ipad)

я за ))

[George Nordic]

Цитата:

Сообщение от Evgeniy2020

а в чем проблема?
если AOT объекты, совместно со всеми настройками,
ключами, RLS, и т.д. переведут в ms sql server
то компоновать правильные запросы там будет не проблема под конкретного пользователя.
это в текущей версии много чего находится в Аксапте,
а если АОТ объекты (application objects)
со всеми конф. ключами, RLS перегонят в MS SQL Server
то я думаю можно сделать движок напрямую который будет считывать
правильно сущности с учетом прав, филдов, rls

бизнес логика которая прямо будет в базе хранится,
зачем тогда далеко считывать все, досаточно будет 128 GB ОЗУ
на MS SQL Server там все и крутится и хранится,
и скорость будет зашибительная
почти никакого трафика,

скорости обработки будут высокими,
все метаданные, правила, ключи, rls, application objects будут в MS SQL
при таком подходе можно будет управлять erp системой с ipad
просо мега сервер 16 процессоров + 128 GB памяти
внутри него и данные и бизнес логика и ключи и rls и olap

Вот если бы меня пригласили архитектором в Редмонд
там бы я напроектировал правильную ERP систему ))

Спаси нас, Господи!

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

Но! Мой Вам совет: Вы уже отстали от жтзни. Нодо все переносить в облако!! И предоставлять он деманд. Да, блин, СОА тоже неплохо аоткнуть - вдруг кто-нить вспомнит!

С Уважением,
Георгий

[kashperuk]

Цитата:

Сообщение от sukhanchik

А еще новый офис и Windows распространяется среди сотрудников МС, которых де-факто вынуждают тестировать эти продукты. А вот АХ к сожалению так не протестируешь.

А если МС хотя бы изнутри протестировал - он бы много багов нашел, о которых и не подозревал

К слову - в Майкрософт работает несколько проектов, которые устанавливают АХ для внутреннего использования. Не уверен, публичная ли информация - конкретные подразделения, ее использующие, - поэтому больше ничего не скажу.

[kashperuk]

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

На мой взгляд (я не претендую на эксперта в данной области), ближе всех к истине fed.
Из кода Аксапту никто не использует. Ее используют либо пользователи (через интерфейс пользователя), либо сторонние системы/приложения (через BC.NET, AIF, COM, т.д.)
А соответственно, нет разницы, на каком языке и платформе написан код тестов (хочу заметить, что речь идет о более сложных функциональных тестах, а не о юнит-тестах). И уж тем более не нужно смешивать в одну кучу тестирование разных аспектов системы, как то производительность выборки данных, редактор Х++ кода, функций ядра и функциональности логистических модулей.

А про то, что тестируют и разрабатывают приложение люди без знания АХ - я считаю, что это проблема. Но, к сожалению, практически всех кандидатов с опытом АХ и Х++, о которых я знаю, не взяли на работу за недостаточные technical skills. То бишь, простите, программисты АХ недостаточно квалифицированы для того, чтобы писать качественный код.

И, напоследок, небольше уточнение моего первого поста:
Выбор был между Linq to BC.NET to AOS и Linq to SQL. То есть речь НЕ идет о Х++ юнит-тестах.

[fed]

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

[mazzy]

Цитата:

Сообщение от fed

Мы с тобой о разных вещах говорим. Как тестирование организовыватся:
1. Запускается некий скрипт на C#, который пишет в БД тестовые данные.
2. Запускается другой скрипт на C#, который вызывает один или несколько классов X++ (через .net bc), которые эти данные обрабатывает.
3. Запускается третий скрипт на C#, который сравнивает получевшиеся по результатам работы классов на X++ в аксаптовской базе данные с эталонными.
4. Запускается четвертый скрипт, который подчишает результируюшие и тестовые данные. (Шаг не обязательный).

Дык вот для шагов 3,4 и (вероятно) 1 - .net bc и непрямой SQL не нужен совсем, если Ваньку начальство заставляет .net bc использовать для чтения базы на шагах 3 и 4 - это верх изврата.

Цитата:

Сообщение от kashperuk

На мой взгляд (я не претендую на эксперта в данной области), ближе всех к истине fed.

вот интересно, как тестируется алгоритм резервирования при вставке той же строки заказа. аксапта по-разному вставляет строки в зависимости от параметров.

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

но я с трудом представляю как тестируется авторезервирование указанным способом при вставке строки в заказ. Ведь там куча мест, которые несколько раз апдейтят запись и сильно зависят от orig().

также с трудом представляю как можно тестировать не из самой аксапты функцию создания строк, которая сильно завязана на внутриаксаптовские временные таблицы (может быть, конечно, в ax6 временные таблицы находятся на уровне SQL). И вообще все алгоритмы, в которых маркируются строки (через map, временные таблицы или еще как).
axaptapedia: Tutorial Form MultiSelectCheckBox

Цитата:

Сообщение от fed

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

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

[Logger]

Цитата:

Сообщение от kashperuk

А про то, что тестируют и разрабатывают приложение люди без знания АХ - я считаю, что это проблема. Но, к сожалению, практически всех кандидатов с опытом АХ и Х++, о которых я знаю, не взяли на работу за недостаточные technical skills. То бишь, простите, программисты АХ недостаточно квалифицированы для того, чтобы писать качественный код.

Неужели все настолько плохо ?
Если не секрет, на чем люди срезались ? Очень интересно, чего же, как правило, не хватает среднему X++ программисту.

Кстати, в некоторых местах встречал код (как правило это относилось к взаимодействию с БД), который явно был написан не X++ программистом, т.е. никакой бест практис не соблюдался. Жутковато выглядело. Походу разработчики ядра взяли и после си наваяли что-то на X++

[Lemming]

Цитата:

Сообщение от Logger

Если не секрет, на чем люди срезались ? Очень интересно, чего же, как правило, не хватает среднему X++ программисту.

Присоединяюсь к вопросу. Понятно что NDA и все такое, но если как-то можно своими словами сформулировать более четкие требования. Что-то вроде: уметь реализовать на бумаге красно-черное дерево на чистом С или там сортировку пузырьком Возможно что-то более фундаментальное: расход памяти при использовании той или иной структуры, понимание каких-либо алгоритмов, параллельность, может что-то еще? В общем, гадать не хочется, так что если кто из приближенных к теме поделится, было бы здорово!

[Vadik]

Цитата:

Сообщение от kashperuk

То бишь, простите, программисты АХ недостаточно квалифицированы для того, чтобы писать качественный код

А если посмотреть на код, который в SSRS отчетах используется, это как - качественный код? По мне, так нечитабельное кровавое месиво Хотя готов допустить, что глаз немного "замылился" - сказывается привычка к аксаптовскому оформлению

[MikeR]

Цитата:

Сообщение от mazzy

Не зна-а-а-аю... За DirParty* ... Руки кодерам/постановщикам оторвать...

Положу свои пять копеек в это обсуждение.

Если бы сделали нормальную денормализацию, то все было бы ничего.
В принципе надо об этом донести и может быть со следующим ролапом или сп это дело могут поправить.