Vladimir2017 wrote:

my.vetrf-forum wrote:У меня не работает GetProductItemByGuid в 2.0

Добро пожаловать в наш клуб

Вопросов куча - какой WSDL брать за самый финальный?

Самый финальный для продукции: http://api.vetrf.ru/schema/platform/services/2.0-last/ProductService_v2.0_production.wsdl

В 1.х все работает. Может для 2.0 нужно свой логин пароль?

Если работаете в продуктивном контуре то свой пароль не нужен.

Vladimir2017 wrote:

ANIT wrote:

Владимир Игнатов wrote:
Да. Пригодицца! На самом деле, во-первых, моя база сильно быстрее отрабатывает, чем шлюз, а во-вторых, "архив" нужен для генерации документов прошлых периодов. Иногда иметь его - полезно.

А вы вообще учли, что помимо всех российских предприятий, там еще целый список всех мировых производителей чья подконтрольная продукция проходит через нашу границу? А еще всякие ИПшники, физ.лица, розничные магазины всей страны и т.д. Вы потом актуализировать весь этот зоопарк как собрались? Что у вас там за СУБД чтоб это все хранить.

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

Владимир Игнатов wrote:
Да, именно так. Иногда актуализируя, пару раз в день (для предприятий). Вряд ли сегодня построенный завод мне сегодня же что-то отгрузит. Даже сегодня зарегистрированный.
Да и хранить-то там... Наших несколько сотен тысяч, иностранных меньше. Меркурий где-то хранит? Ну вот.

ANIT wrote:

Владимир Игнатов wrote:
Да, именно так. Иногда актуализируя, пару раз в день (для предприятий). Вряд ли сегодня построенный завод мне сегодня же что-то отгрузит. Даже сегодня зарегистрированный.
Да и хранить-то там... Наших несколько сотен тысяч, иностранных меньше. Меркурий где-то хранит? Ну вот.

это не факт что юридически завод, это пункт перегрузки может быть и это уже новый элемент BusinessEntity. адрес получателя (ФИЗ ЛИЦА) туда же. Это не только производители, это все участники оборота. Несколько миллионов записей, на чем вы их крутить собрались, не на 1С надеюсь файловой )))? Неужели есть реально смысл такие объемы ворочать в выборках при обработке входящих записей, вместо подхвата на лету и периодического пополнения данных? Это миллионы элементов которые будут висеть мертвым грузом.

Владимир Игнатов wrote:
Миллионы элементов - да, на лету - нет. Глядя на "скорость" тестового сервера могу только повторить за Крыловым: "рожденный ползать - летать не может". Можно иногда урезать базу, выкидывая не активные записи, древнее какого-то срока.

Периодическое пополнение мне не понятно. Как? Спросил у Меркурия "по текущей потребности", получил сейчас актуальные данные. Дальше что? Хранить их? И если снова потребуются - что?
1. Брать из базы? А если за это время изменились?
2. Переспрашивать заново? Тогда в чем периодическое пополнение?
3. Иногда переспрашивать всех, кто уже накоплен как "часто используемые". И использовать данные этой актуализации. Да, возможно. При увеличении базы своих контрагентов может стать менее выгодно (по времени), чем получать изменения. Более того, все, кто к SQL-серверу за чем-нибудь обращались, знают, что 500 запросов по 1 строке (вариант переопроса для актуализации своих накопленных) будут работать куда медленнее, чем 1 запрос на 500 строк (вариант получения изменений с предыдущего такого же запроса).

ANIT wrote:
Сомнительная затея. Вопрос на сколько вы в своей оптимизации учли что вам каждый раз выборки придется строить по всем этим миллионам, чтобы сформировать 1ВСД или подтянуть нужную ссылку производителя. Но опять же вопрос на чем вы работаете. Прямые у вас запросы к скулю или это запросы из 1С и ей подобных. Хозяин барин. Как на продакшене эту схемку будите запускать, маякните хоть, а то даже интересно стало.

ANIT wrote:UP
Ребят, кто-нибудь скиньте ГУИД Наименования продукции (ProdactItem) из рабочего шлюза. Проверить на сколько в рабочем отрабатывает getProductByGuid

Sergey-Chelny wrote:
guid: 8d8a6b56-560b-4287-9b54-7faa855d1de6
uuid: 9ad67d3f-e1fd-4b9a-803c-ea68ad787834