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


Зарегистрирован: 10/11/2017 12:14:53
Сообщений: 176
Оффлайн

Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!

У них разные Consignor.Enterprise.guid !!!

getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.

И все это для одного и того же UUID-документа.

Я все понимаю, но @@@ть кто до такого додумался???
egais2018


Зарегистрирован: 08/06/2018 15:12:57
Сообщений: 282
Оффлайн

GusVal wrote:Я все понимаю

Как вам это удалось (в случае с Меркурием)?
Владимир Игнатов


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

GusVal wrote:Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!

У них разные Consignor.Enterprise.guid !!!

getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.

Ничего не понимаю. По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid? Или потом при запросе предприятия по GUID приходят разные статусы предприятия?
GusVal


Зарегистрирован: 10/11/2017 12:14:53
Сообщений: 176
Оффлайн

Владимир Игнатов wrote:
GusVal wrote:Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!

У них разные Consignor.Enterprise.guid !!!

getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.

Ничего не понимаю. По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid? Или потом при запросе предприятия по GUID приходят разные статусы предприятия?


По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid
GusVal


Зарегистрирован: 10/11/2017 12:14:53
Сообщений: 176
Оффлайн

egais2018 wrote:
GusVal wrote:Я все понимаю

Как вам это удалось (в случае с Меркурием)?

Самовнушение
Владимир Игнатов


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

GusVal wrote:
Владимир Игнатов wrote:
GusVal wrote:Запускаю getVetDocumentChangesListRequest, получаю там UUID-документа...
Беру GetVetDocumentByUuidOperation по этому документу и что вы думаете?!

У них разные Consignor.Enterprise.guid !!!

getVetDocumentChangesListRequest возвращает Enterprise.guid, у которого status=230.
GetVetDocumentByUuidOperation возвращает Enterprise.guid, у которого status=430.

Ничего не понимаю. По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid? Или потом при запросе предприятия по GUID приходят разные статусы предприятия?


По двум запросам getVetDocumentChangesListRequest и GetVetDocumentByUuidOperation возвращаются разные Enterprise.guid

Прекрасно! Просто превосходно! А можно тогда для получения окончательной ясности ответы от шлюза в виде исходного xml?
GusVal


Зарегистрирован: 10/11/2017 12:14:53
Сообщений: 176
Оффлайн

Владимир Игнатов wrote:
Прекрасно! Просто превосходно! А можно тогда для получения окончательной ясности ответы от шлюза в виде исходного xml?

Да запросто... В пятницу потратил пару часов...
Вот фрагмент getVetDocumentListRequest:
<vd:vetDocument>
<bs:uuid>287d1ca4-0f5e-4fa9-9097-6b24e07d36ec</bs:uuid>
<vd:issueDate>2018-08-03</vd:issueDate>
<vd:vetDForm>LIC2</vd:vetDForm>
<vd:vetDType>TRANSPORT</vd:vetDType>
<vd:vetDStatus>CONFIRMED</vd:vetDStatus>
<vd:lastUpdateDate>2018-08-03T09:14:56+03:00</vd:lastUpdateDate>
<vd:certifiedConsignment>
<vd:consignor>
<dt:businessEntity>
<bs:uuid>52223022-93c8-4014-b3b1-2113c9752105</bs:uuid>
<bs:guid>e01d5abc-7f57-44fb-a7e7-b6e8daf402a8</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:uuid>9eac2ffa-91b4-4601-b9a9-4fa46be828a0</bs:uuid>
<bs:guid>c463fc54-4fdc-43c0-9014-66994f414c0c</bs:guid>
</dt:enterprise>
</vd:consignor>

Потом беру GetVetDocumentByUuid с этим UUID документа и вижу
<vd:vetDocument>
<bs:uuid>287d1ca4-0f5e-4fa9-9097-6b24e07d36ec</bs:uuid>
<vd:issueDate>2018-08-03</vd:issueDate>
<vd:vetDForm>LIC2</vd:vetDForm>
<vd:vetDType>TRANSPORT</vd:vetDType>
<vd:vetDStatus>CONFIRMED</vd:vetDStatus>
<vd:lastUpdateDate>2018-08-03T09:14:56+03:00</vd:lastUpdateDate>
<vd:certifiedConsignment>
<vd:consignor>
<dt:businessEntity>
<bs:uuid>52223022-93c8-4014-b3b1-2113c9752105</bs:uuid>
<bs:guid>e01d5abc-7f57-44fb-a7e7-b6e8daf402a8</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:uuid>9c7afcfb-7f35-4e4d-b5c6-8f7ec02b10dc</bs:uuid>
<bs:guid>6150d3dd-ba54-36b8-676a-0b6a5c576622</bs:guid>
</dt:enterprise>

Сейчас еще проверил, что вернул processIncomingConsignment... Да-да... Как и "ожидалось"...

<merc:vetDocument>
<bs:uuid>287d1ca4-0f5e-4fa9-9097-6b24e07d36ec</bs:uuid>
<vd:issueDate>2018-08-03</vd:issueDate>
<vd:vetDForm>LIC2</vd:vetDForm>
<vd:vetDType>TRANSPORT</vd:vetDType>
<vd:vetDStatus>UTILIZED</vd:vetDStatus>
<vd:lastUpdateDate>2018-08-03T18:59:17+03:00</vd:lastUpdateDate>
<vd:certifiedConsignment>
<vd:consignor>
<dt:businessEntity>
<bs:uuid>52223022-93c8-4014-b3b1-2113c9752105</bs:uuid>
<bs:guid>e01d5abc-7f57-44fb-a7e7-b6e8daf402a8</bs:guid>
</dt:businessEntity>
<dt:enterprise>
<bs:uuid>9c7afcfb-7f35-4e4d-b5c6-8f7ec02b10dc</bs:uuid>
<bs:guid>6150d3dd-ba54-36b8-676a-0b6a5c576622</bs:guid>
</dt:enterprise>
</vd:consignor>

Вот такая вот история....
Если смотреть по партнерам, то там одного удалили путем слияния... Но почему тогда при гашении Меркурий это не учитывает?

Это сообщение было редактировано 3 раз. Последнее обновление произошло в 06/08/2018 12:07:57

Владимир Игнатов


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

GusVal wrote:
Владимир Игнатов wrote:
Прекрасно! Просто превосходно! А можно тогда для получения окончательной ясности ответы от шлюза в виде исходного xml?

Да запросто...
...
Вот такая вот история....
Если смотреть по партнерам, то там одного удалили путем слияния... Но почему тогда при гашении Меркурий это не учитывает?

"Удалили путем слияния" - не важно. Хоть путем аннигиляции. GUIDы поменяться не должны. UUID - может, конечно, а вот GUID. Кому я это рассказываю? Зачем? Разработчики давно уже в каких-то нездешних высях розовых покемонов ловят, как я вижу...
oleg-x


Зарегистрирован: 20/11/2017 11:24:40
Сообщений: 1996
Оффлайн

Владимир Игнатов wrote:
GusVal wrote:
Владимир Игнатов wrote:
Прекрасно! Просто превосходно! А можно тогда для получения окончательной ясности ответы от шлюза в виде исходного xml?

Да запросто...
...
Вот такая вот история....
Если смотреть по партнерам, то там одного удалили путем слияния... Но почему тогда при гашении Меркурий это не учитывает?

"Удалили путем слияния" - не важно. Хоть путем аннигиляции. GUIDы поменяться не должны. UUID - может, конечно, а вот GUID. Кому я это рассказываю? Зачем? Разработчики давно уже в каких-то нездешних высях розовых покемонов ловят, как я вижу...

Как раз, если удалили объединением, гуид и ууид поменяется. У каждой площадки был свой, объеденили, остался один. Это не поменяли инфу, а объеденили 2 элемента справочника.
Вот только мне казалось, что если указан GUID удаленных элементов, путем объединения, то система сама должна была понять, что имеется ввиду активный элемент. По крайне мере в справке где то такое читал.
https://vk.com/mercuriy_rf
GusVal


Зарегистрирован: 10/11/2017 12:14:53
Сообщений: 176
Оффлайн

Владимир Игнатов wrote: GUIDы поменяться не должны. UUID - может, конечно, а вот GUID.

Так на эту аксиому и был мой скромный расчет... Ан нет... Наловился я всяких "MERC14225 Предприятие-отправитель в сведениях о принимаемой партии должен совпадать с указанным в ветеринарно-сопроводительном документе." пока не раскусил этот заговор...

Проблема не в том, что объединили, а в том, что по одному и тому же UUID (состоянию в конкретный момент) документа разные методы возвращают разные GUID'ы... Вот в этом засада полная, так не делается. Скорее всего в одном месте костыль воткнули, а про другие забыли.
Konup


Зарегистрирован: 21/11/2017 09:37:55
Сообщений: 46
Оффлайн

oleg-x wrote:По крайне мере в справке где то такое читал.

Так у них справку одни "гении" писали, а шлюз Меркурия другие...

GusVal wrote:Проблема не в том, что объединили, а в том, что по одному и тому же UUID (состоянию в конкретный момент) документа разные методы возвращают разные GUID'ы

Пока писал интеграцию не раз сталкивался с тем, что при получении документов списком некоторые данные отличаются от данных при получении одного документа по uuid. Видимо одно правят, другое калечат...
Владимир Игнатов


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

GusVal wrote:Проблема не в том, что объединили, а в том, что по одному и тому же UUID (состоянию в конкретный момент) документа разные методы возвращают разные GUID'ы... Вот в этом засада полная, так не делается. Скорее всего в одном месте костыль воткнули, а про другие забыли.

И уж конечно, если есть один GUID, то все UUIDы должны меняться в рамках этого GUIDа. Там всякие next/prev. Тогда получается обычный двусвязный список. А так что? Как вот этот тип связей назвать? Был один список, у каждого элемента есть свой next/prev, был второй список. Потом "удалили путем слияния", в результате в какой-то момент в обоих списках самым новым стал 1 элемент, оба списка, если пройти по ним, своими next указывают на этот объединенный. А у него в prev - что???
Да и не в том счастье, безусловно. А в том, что 2 запроса про одну запись (в данном случае - ВСД) дают разную информацию. И вот это - недопустимо!
oleg-x


Зарегистрирован: 20/11/2017 11:24:40
Сообщений: 1996
Оффлайн

Владимир Игнатов wrote:Да и не в том счастье, безусловно. А в том, что 2 запроса про одну запись (в данном случае - ВСД) дают разную информацию. И вот это - недопустимо!

И тут есть подозрение что берутся из разных источников, что не должно быть. А судя по всему, построили они такого монстра, если что то менять в нем - это целый проект у них.
https://vk.com/mercuriy_rf
Mercury

[Avatar]

Зарегистрирован: 03/08/2018 22:08:55
Сообщений: 9
Оффлайн

oleg-x wrote:И тут есть подозрение что берутся из разных источников, что не должно быть. А судя по всему, построили они такого монстра, если что то менять в нем - это целый проект у них.

Да скорее всего так и есть, просто баг походу.
vlas_naroda


Зарегистрирован: 05/07/2018 13:51:52
Сообщений: 17
Оффлайн

> Да скорее всего так и есть, просто баг походу.

с их точки зрения это не баг а фича
Я не влас,не седовлас,не крючкотвор,не п...ас
 
Индекс форума » Компонент МЕРКУРИЙ
Перейти:   

Powered by JForum 2.1.8 © JForum Team