Интеграция с asp.net

[olbrus]

Стоит задача разработать web приложение для взаимодействия с Navision, в качестве платформы будет использоваться asp.net, но не хотелось бы строить обмен и синхронизацию через XML шлюз и создавать 2ую БД под web интерфейс, существует ли какая-то возможность работы непосредственно с бизнес сущностями navision (клиент, товар, документ) по операциям просмотр/добавление/удаление, чтобы на asp стороне вести работу уже только с уровнем бизнес-логики? Или посоветуйте альтернативные варианты взаимодействия

[Sancho]

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

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

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

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

[olbrus]

Цитата:

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

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

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

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

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

спасибо за совет, оплатить спеца я готов, смогу я потом взаимодействовать с аппликейшн сервером так, чтобы не создавать 2ую БД у себя на клиентской части и по какому протоколу?

[Romul]

Писал "B2B портал" для пары клиентов, вертящихся на 2009 R2: продажи, остатки, цены продаж, описание товаров, товарные категории и группы, скидки и пр...
Вся логика, разумеется, в наве. Суть в том, что куча магазинов (франчайзинг) заходила на веб-сайт, авторизовывалась (у каждого магазина свой логин и пароль) и заказывала товары, им необходимые. Поднял таблицы в духе Web Sales Header, Web Sales Line. Когда магазин заказывал товары, создавался заказ и хранился в подобных буферных таблицах. Соответственно, локинга стандартных таблиц не было совершенно. Работа хэд офиса не зависела от работы клиентов. Никакой логики на филдах этих временных таблиц не было: голые поля.
Вся логика проходила через стандартные темповые таблицы, прежде чем писаться в эти буфера. Разумеется, в случае ошибки/неверной валидации - перехватывал ошибку и аккуратно выдавал юзеру на экран, чтобы он мог исправить ситуации (выбрать другой товар, выбрать другое кол-во, если недостаточно на складе и т.д.). В конце подбора товаров (скажем, 5 строк с разными товарами), юзер жмыкал кнопку SUBMIT и заказ шел в Web Sales Header, Web Sales Line. Менеджер хэд офиса, курирующий работу магазинов и отвечающий за взаимодействие с ними (что отгрузить, кому, когда) просматривал эти заказы и вносил изменения/контактировал с клиентом и т.д. Если все было ОК - переводил заказ в Навижине из Вебовых таблиц продажи, в 36 и 37 (Sales Header/Sales Line). Ну и дальше куча других фич... Разруливал разные темплейты (в зависимости от категории товара, вида доставки и - контейнер большой/малый/максимальный обхъем контейнера и т.д.).

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

В принципе, все реализуемо.