|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сломалось GetProductItemChangesList  XML
Индекс форума » Компонент МЕРКУРИЙ
Автор Сообщение
ANIT

[Avatar]

Зарегистрирован: 09/09/2016 11:26:18
Сообщений: 196
От: Катерина Бакшеева
Оффлайн

Проверила ваш запрос на боевой. Та же фигня, пустой результат.
------------------------
"Тяжела и неказиста жизнь простого программиста."
my.vetrf-forum


Зарегистрирован: 06/09/2017 17:07:57
Сообщений: 313
Оффлайн

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 нужно свой логин пароль?

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


Отлично. WSDL этот. Работаю на продуктивном.
Только GetProductItemByGuid не сломалось. А не работало никогда. Я уж несколько раз пробовал.

Получается вынужден писать под 1.х а потом когда 2.0 выпилят наконец то, то придется почти все переделывать.
Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

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

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


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

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

[Avatar]

Зарегистрирован: 09/09/2016 11:26:18
Сообщений: 196
От: Катерина Бакшеева
Оффлайн

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


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


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

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


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

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

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

[Avatar]

Зарегистрирован: 09/09/2016 11:26:18
Сообщений: 196
От: Катерина Бакшеева
Оффлайн

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

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


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

[Avatar]

Зарегистрирован: 09/09/2016 11:26:18
Сообщений: 196
От: Катерина Бакшеева
Оффлайн

мы немного отошли от темы товарищи. А кто-нибудь может мне кинуть ГУИД ProdactItem из рабочего шлюза. Проверить на сколько в рабочем отрабатывает getProductByGuid
------------------------
"Тяжела и неказиста жизнь простого программиста."
Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

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

Тут я у себя выборку сделаю, там - Меркурий сделает то же самое через интернет. У меня SQL сервер за стенкой гудит, пишется все это на Delphi. Буду запускать - мяукну.
ANIT

[Avatar]

Зарегистрирован: 09/09/2016 11:26:18
Сообщений: 196
От: Катерина Бакшеева
Оффлайн

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


Зарегистрирован: 04/04/2017 13:29:33
Сообщений: 81
Оффлайн

Не работает на продуктиве ничего



Sergey-Chelny

[Avatar]

Зарегистрирован: 07/09/2017 17:33:44
Сообщений: 101
Оффлайн

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


свинина охлажденная:
guid: 8d8a6b56-560b-4287-9b54-7faa855d1de6
uuid: 9ad67d3f-e1fd-4b9a-803c-ea68ad787834
Кто хочет, тот ищет возможности, кто не хочет — ищет причины.
v.isaev


Зарегистрирован: 04/04/2017 13:29:33
Сообщений: 81
Оффлайн

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


Это сообщение было редактировано 1 раз. Последнее обновление произошло в 01/12/2017 11:09:33

 
Индекс форума » Компонент МЕРКУРИЙ
Перейти:   

Powered by JForum 2.1.8 © JForum Team